Base de datos nativa en la nube: estructura de archivo SST de la base de datos distribuida de Inspur Yunxi

El árbol LSM garantiza que la base de datos se escriba en orden (memtable-skiplist), lo que mejora el rendimiento de escritura, pero debido a su propia estructura jerárquica, sacrifica el rendimiento de lectura (como una clave almacenada en un nivel bajo, de arriba a abajo). Hay que buscar en cada capa, lo cual es muy caro). Por lo tanto, hay muchas optimizaciones para mejorar el rendimiento de la lectura: filtro de floración (interpreta de manera eficiente si una clave no existe), filtro de índice (búsqueda binaria, en el caso de bajo consumo de memoria) para indexar datos clave-valor. Estas bases de datos deben almacenarse en archivos SST para una gestión ordenada de los datos kv.

 

Descripción general del formato de archivo SST

1) Pie de página: 48 bytes fijos, que indican la información de compensación de IndexBlock y MetaIndexBlock en el archivo, es la metainformación de la metainformación, se encuentra al final del archivo sstable

2) IndexBlock: ocupa un espacio de bloque y registra los metadatos relacionados con el DataBlock

3) MetaIndexBlock: ocupa un espacio de bloque, cada bloque de metainformación, incluido el filtro, las propiedades (información de atributos de toda la tabla), el diccionario de compresión, la lápida de eliminación de rango

4) MetaBlock: puede ocupar múltiples espacios de bloque y almacenar los datos binarios del filtro Bloom y otros datos de metadatos

5) DataBlock: puede ocupar varios espacios de bloques y almacenar los datos reales, es decir, el contenido de los pares clave-valor

 

Estructura del pie de página

 

El pie de página tiene un tamaño fijo de 48 bytes y se encuentra al final del archivo SSTable, el desplazamiento y el tamaño de MetaBlockIndex y DataBlockIndex forman el tipo BlockHandlel, que se utiliza para abordar la ubicación de los bloques de MetaBlockIndex y DataBlcokIndex. el desplazamiento está codificado por longitud variable variable para ahorrar espacio. El desplazamiento y el tamaño ocupan al menos 1 byte y como máximo 9 bytes, por lo que el desplazamiento y el tamaño de MetaBlockIndex y DataBlockIndex ocupan como máximo 4 * 9 = 36 bytes, que se llenan hasta 40 bytes. (8 caracteres) por relleno. alineación de la sección); por ejemplo, DataBlockIndex.offset = 64, DataBlockIndex.size = 216, lo que indica que DataBlockIndex se encuentra en el byte 64 al byte 280 del archivo SSTable.

 

estructura de bloque

La estructura de datos de 5 partes, excepto el pie de página, otras estructuras físicas están en forma de bloque. Cada bloque corresponde a un bloque de almacenamiento del disco físico, por lo que el tamaño del bloque es coherente con el tamaño del bloque de almacenamiento en disco. Esta es también la razón por la que el pie de página se coloca al final del archivo.Los 48 bytes del pie de página en sí no pueden ocupar un bloque de almacenamiento en disco. Cuando el bloque se almacena en el disco duro, agregará 5 bytes de contenido adicional después de los datos reales: tipo de compresión, crc.

 

Estructura del bloque de datos

El almacenamiento de DataBlcok Key adopta el mecanismo de compresión de prefijos. La compresión de prefijos significa que el mismo prefijo de la clave se almacena solo una vez para ahorrar espacio. Pero para SSTable, no realiza la compresión de prefijos en todas las claves de todo el bloque a la vez, sino que configura muchos segmentos, y las claves en el mismo segmento realizan la compresión de prefijos una vez, y el punto de inicio de cada segmento es un punto de reinicio . . El mecanismo de compresión de prefijos hace que cada registro recuerde las longitudes compartidas y no compartidas de su clave correspondiente. La llamada longitud compartida de la clave se refiere a la longitud del prefijo común entre la clave del registro actual y la clave del registro anterior, y la longitud no compartida se refiere a la longitud de las diferentes partes después de eliminar la misma parte. De esta forma, el registro actual solo necesita almacenar el valor de las diferentes partes de la clave.

La primera parte (Entrada) se utiliza para almacenar datos de clave-valor. Dado que todos los pares clave-valor en sstable se almacenan en orden estricto, para ahorrar espacio de almacenamiento, el valor clave completo no se almacenará para cada par de pares clave-valor, pero no se compartirá con la parte anterior de la clave, para evitar el almacenamiento. de contenido clave duplicado. Cada pocos pares clave-valor, se restaurará una clave completa para el registro. Este proceso se repite (el intervalo predeterminado es 16) y cada punto en el que se restaura la clave completa se denomina punto de reinicio.

El propósito del punto de reinicio es acelerar el proceso de búsqueda al leer contenido estable. Dado que cada punto de reinicio almacena un valor clave completo, al buscar datos en sstable, primero puede usar los datos del punto de reinicio para comparar el valor clave, a fin de ubicar rápidamente el área donde se encuentran los datos objetivo; cuando el objetivo se determinan los datos Cuando esté en el área, compare los valores clave de todos los elementos de datos en el intervalo a su vez y realice una búsqueda detallada; esta idea es algo similar a la idea de usar datos de alto nivel para localizar y buscar rápidamente datos de bajo nivel en la lista de omisión, reduciendo la complejidad de la búsqueda.

 

Estructura de almacenamiento de datos KV

  • longitud de clave compartida: la misma longitud de bytes de prefijo de clave que el punto de reinicio.
  • longitud de clave no compartida: después de la clave actual menos la misma longitud de prefijo del punto de reinicio, la longitud de bytes restante
  • longitud del valor: la longitud en bytes del valor
  • contenido de clave no compartido: el contenido de clave de la parte que es diferente de la clave en el punto de reinicio.
  • valor: almacenar el valor real

 

Estructura de bloque de índice 

El bloque de índice contiene varios registros, cada registro representa la información de índice de un bloque de datos, que se utiliza para ubicar rápidamente el bloque de datos que contiene una clave específica; el bloque de índice es primero un bloque, por lo que contiene tres partes KeyValue, Type (fijo 1 byte), código de verificación CRC (4 bytes fijos); el tipo identifica si esta parte de los datos adopta un algoritmo de compresión, CRC es el código de verificación de KeyValue + Type.

Un índice incluye lo siguiente:

  • clave, el valor es mayor o igual que la clave más grande de su bloque de índice y menor que la clave más pequeña del siguiente bloque;
  • El desplazamiento de la dirección inicial del bloque de datos en sstable;
  • El tamaño del bloque de datos;

Al igual que DataBlock, IndexBlock adopta la compresión de prefijos, pero el intervalo es 2 (el valor predeterminado de DataBlock es 16).

 

¿Por qué la clave no es la clave más grande del DataBlock cuyo índice se toma?
 

El propósito principal es ahorrar espacio; asumiendo que la clave más grande del bloque indexado es "reconocimiento", y la clave más pequeña del siguiente bloque es "manzana", si la clave de DataBlockIndex adopta la clave más grande de su bloque de índice, el la longitud ocupada es len("reconocimiento"); en el último método, el valor clave puede ser "anuncio" ("reconocimiento" < "anuncio" < "manzana"), la longitud es solo 2 y el efecto de recuperación es el mismo .

 

¿Por qué el desplazamiento y el tamaño de BlockHandle están en bytes en lugar de bloques?
 

Debido a que el tamaño de bloque en SSTable no es fijo, aunque el parámetro block_size se puede especificar en la opción, cuando los datos se almacenan en SSTable, no se alinean estrictamente de acuerdo con block_size, por lo que el desplazamiento y el tamaño se refieren al número. de bytes de compensación y el número de bytes de longitud. Existen dos motivos principales para esto:  

(1) Se pueden almacenar claves de cualquier longitud y valores de cualquier longitud, y el mismo valor de clave no se puede almacenar en bloques. En casos extremos, como nuestro valor único es muy grande, que ha excedido block_size, entonces para este tipo de En este caso, SSTable no se puede almacenar. Por lo general, el tamaño real del bloque es un poco más grande que block_size;

(2) Desde otro punto de vista, si los datos se almacenan estrictamente de acuerdo con la alineación block_size, debe haber muchos bloques alineados con 0, lo que desperdicia espacio de almacenamiento.

{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/5148943/blog/5413570
Recomendado
Clasificación