Problemas de HBase
Cuando se creó la tabla HBase por primera vez, solo había una Región administrada por un Servidor de Región de manera predeterminada. Cuando la cantidad de datos alcanzó un cierto valor, se activó una división, que dividiría continuamente más Regiones, administradas por diferentes Servidores de Región, cada Región Administre una clave de fila continua, representada por la clave de fila inicial y la clave de fila final, por lo que habrá dos problemas
- No puede aprovechar al máximo las ventajas del procesamiento concurrente distribuido, debe esperar a que Región se divida en múltiples automáticamente, este proceso puede llevar mucho tiempo
- Dado que cada región gestiona una clave de fila continua, si la lectura y escritura de datos no son lo suficientemente aleatorias, por ejemplo, hay una identificación de auto-incremento, como un gran número de operaciones concentradas en una determinada clave de fila, esto puede causar presión en la misma región
Estrategia de división regional
Definido en el archivo hbase-site.xml
<name>hbase.regionserver.region.split.policy</name>
<value>org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy</value>
<description>
A split policy determines when a region should be split. The various other split policies that
are available currently are ConstantSizeRegionSplitPolicy, DisabledRegionSplitPolicy,
DelimitedKeyPrefixRegionSplitPolicy, KeyPrefixRegionSplitPolicy etc.
</description>
La estrategia predeterminada es IncreasingToUpperBoundRegionSplitPolicy. En HBase 1.2, esta estrategia por defecto dice que cuando el tamaño de Región alcanza el cubo del número de Regiones, multiplique por hbase.hregion.memstore.flush.size (128 MB por defecto), luego multiplíquelo por 2, o llegue a hbase .hregion.max.filesize (predeterminado 10 GB), divide la región
第一次分裂的大小：1^3 * 128MB * 2 = 256MB
第二次分裂的大小：2^3 * 128MB * 2 = 2048MB
第三次分裂的大小：3^3 * 128MB * 2 = 6912MB
第四次分裂的大小：4^3 * 128MB * 2 = 16384MB，超过了 10GB，因此只取 10GB
后面的分裂大小都是 10GB
Se puede ver que si hay más nodos disponibles, puede llevar mucho tiempo utilizarlos por completo.
Prepartición
El primer método de prepartición
hbase org.apache.hadoop.hbase.util.RegionSplitter tablename HexStringSplit -c 10 -f f1:f2:f3
El comando anterior significa crear una tabla llamada tablename. Esta tabla está preasignada con 10 regiones y tiene tres CF, a saber, f1, f2 y f3. El algoritmo de prepartición es HexStringSplit o UniformSplit también se puede seleccionar, donde HexStringSplit es adecuado para la fila El prefijo de la clave es una cadena hexadecimal. UniformSplit es adecuado para que el prefijo de clave de fila sea completamente aleatorio. Después de la partición previa, incluso si la clave de fila es continua, HBase la dividirá en diferentes regiones a través del algoritmo para lograr una distribución uniforme y evitar Punto de acceso
El segundo método de prepartición
hbase shell > create 'tablename', 'f1', SPLITS=> ['10', '20', '30', '40']
Cuando puede conocer la distribución de las teclas de fila de antemano, puede especificar el punto de división de cada región particionada previamente. En la tabla creada por el comando anterior, hay 5 regiones
Region 1 : row key 的前两位是 min~10
Region 2 : row key 的前两位是 10~20
Region 3 : row key 的前两位是 20~30
Region 4 : row key 的前两位是 30~40
Region 5 : row key 的前两位是 40~max
注意这里不单指数字字符，比如 1a 就会落在 Region 2
Puede hacer una división forzada en una tabla existente
hbase shell > split 'table', 'split point'
También puedes diseñar tu propio método de división
Sal de fénix
CREATE TABLE IF NOT EXISTS Product (
id VARCHAR not null,
time VARCHAR not null,
price FLOAT,
sale INTEGER,
inventory INTEGER,
CONSTRAINT pk PRIMARY KEY (id, time)
) COMPRESSION = 'GZ', SALT_BUCKETS = 6
En esencia, después de seleccionar la clave de fila de la tabla HBase, tome el resto de SALT_BUCKETS e inserte el resultado (0 ~ 5 en el ejemplo anterior) como el primer bit de la clave de fila, y divida los datos de acuerdo con este valor. En diferentes regiones, debido a que se almacena como un byte, el valor máximo que SALT_BUCKETS puede tomar es 256. Las filas con el mismo byte de sal se dividirán en el mismo servidor de región, por lo que generalmente el número de servidores de región se toma como SALT_BUCKETS
debido a la adición de datos de sal Hay un bit más al frente, por lo que, de manera predeterminada, los datos tomados de servidores de diferentes regiones no se pueden ordenar de acuerdo con la clave de fila original. Si necesita garantizar la clasificación, debe cambiar una configuración
phoenix.query.force.rowkeyorder = true