Cómo se enrutan los clientes en HBase al RegionServer correcto
Echemos un vistazo más de cerca a esta estructura. Cada línea registra información sobre una Región.
La primera es RowKey, que consta de tres partes: TableName, StartKey y TimeStamp. El contenido almacenado en RowKey también se denomina nombre de la región. Como mencionamos en el artículo anterior, el nombre de la carpeta donde se almacena la Región es el valor hash de RegionName, porque RegionName puede contener algunos caracteres ilegales. Ahora deberías saber por qué RegionName puede contener caracteres no válidos, porque StartKey permite cualquier valor. Las tres partes de RowKey están conectadas por comas para formar el RowKey completo, donde TimeStamp está representado por una cadena de dígitos decimales. Aquí hay un ejemplo de RowKey:
Table1,RK10000,12345678
Luego está la familia principal en la tabla: info, que contiene tres columnas: regioninfo, server y serverstartcode. . regioninfo es la información detallada de la región, incluida StartKey, EndKey e información de cada familia.
Por lo tanto, cuando una región se divide, fusiona o reasigna, es necesario modificar el contenido de la tabla.
Hasta ahora, hemos comprendido los conocimientos previos necesarios y ahora comenzaremos oficialmente todo el proceso de encontrar el RegionServer en el lado del cliente. Voy a usar un ejemplo hipotético para aprender este proceso, así que primero construyo una tabla -ROOT- hipotética y una tabla .META.
Primero veamos la tabla .META.table, suponiendo que solo hay dos tablas de usuario en HBase: la tabla 1 es muy grande y está dividida en muchas áreas, por lo que hay muchas filas en .META.table para registrar estas áreas. La Tabla 2 es muy pequeña, dividida en sólo dos áreas. La tabla 2 es muy pequeña y está dividida solo en dos áreas, por lo que solo hay dos filas en .META.table para registrarlas. El contenido de la tabla es el siguiente:
.META.
Ahora, supongamos que queremos insertar la RowKey de RK10000 de la Tabla 2. Luego debemos seguir los siguientes pasos:
1. Consultar .META.table para conocer el rango que contiene estos datos.
2. Obtener la dirección del RegionServer que gestiona la Región.
3. Conéctese al RegionServer y busque los datos.
Bien, comencemos con el paso uno. El problema es que .META también es una tabla normal. Primero debemos saber qué RegionServer administra la tabla .META. Hay una manera de colocar rápidamente la dirección del RegionServer que administra la tabla .META en la parte superior de ZooKeeper, para que todos sepan quién administra la tabla .META.
Parece que el problema está solucionado, pero en este ejemplo nos hemos encontrado con un nuevo problema. Como la Tabla1 es demasiado grande, tiene demasiadas regiones, .META. Para almacenar la información de estas Regiones, se necesita mucho espacio y es necesario dividirlas en varias Regiones. Esto significa que puede haber más de un RegionServer administrando .META. ¿Qué hacer? ¿Almacenar las direcciones de todos los RegionServers que administran .META en ZooKeeper y dejar que el cliente lo atraviese por sí solo?
El enfoque de HBase es utilizar otra tabla para registrar la información de .META.Región, al igual que .META.Región registra la información de Región de la tabla de usuario. Esta tabla es la tabla -ROOT-. Esto también explica por qué -ROOT- y .META tienen la misma estructura de tabla, ya que funcionan exactamente de la misma manera.