Fuente: https://zhuanlan.zhihu.com/p/45652076
Autor: Wen Positively Lake (trabajó en NetEase Hangzhou Research Institute, en el desarrollo del núcleo de la base de datos)
MyRocks es una base de datos MySQL optimizada para el espacio y el rendimiento de escritura, que proporciona una opción confiable para la selección de su base de datos empresarial. Este artículo presenta principalmente qué es MyRocks, incluidas sus características, centrándose en las ventajas de MyRocks en comparación con InnoDB y un análisis detallado de varios escenarios a los que se aplica MyRocks.
RocksDB es implementado por FaceBook basado en el LevelDB de código abierto de Google, usando el árbol LSM (Log-Structure Merge) para almacenar datos. Los ingenieros de desarrollo de Facebook han desarrollado mucho en RocksDB para que cumpla con los requisitos del marco del motor de almacenamiento enchufable de MySQL. Está adaptado a MySQL y se llama MyRocks. MyRocks admite la mayoría de las funciones de MySQL, como lectura y escritura de datos basada en SQL, mecanismo de bloqueo, MVCC, transacciones y replicación maestro-esclavo. En términos de hábitos de uso, no hay mucha diferencia entre usar MyRocks o MySQL / InnoDB.
Después de más de 4 años de desarrollo, MyRocks ha madurado. Las versiones de rama MySQL de código abierto Percona y MariaDB han migrado MyRocks a sus propias ramas MySQL. InnoSQL es la rama MySQL de NetEase y actualmente es compatible con MyRocks. La versión específica es InnoSQL 5.7.20 -v4, basado en el código MyRocks de código abierto, hemos realizado mejoras de optimización funcional, corrección de errores y soporte para copias de seguridad físicas en línea locales y remotas. Presentemos brevemente las características de MyRocks, para que todos tengan una comprensión básica de él. Dado que MyRocks solo reemplaza InnoDB con RocksDB, la lógica de la capa del servidor MySQL no ha cambiado mucho, incluido el plan de ejecución y análisis de SQL, y el mecanismo de replicación multiproceso basado en Binlog. El foco de nuestra discusión es principalmente la capa del motor de almacenamiento, que se encuentra en RocksDB.
Este artículo incluye principalmente tres partes: Primero, RocksDB se introduce a través del proceso de lectura y escritura para presentar su marco general, backend de almacenamiento y características funcionales; luego se analiza en múltiples dimensiones para analizar las diferencias de InnoDB y los beneficios de estas diferencias; finalmente, el análisis ¿En qué escenarios comerciales se pueden utilizar estas ventajas de RocksDB? El artículo es más largo, por lo que puede elegir la parte que le interesa.
Proceso de lectura y escritura de RocksDB
Proceso de escritura
La figura anterior muestra un diagrama esquemático de la solicitud de escritura de RocksDB. La modificación de una transacción se escribe en el WriteBatch del subproceso de transacción antes del envío (en el ejemplo anterior, la transacción solo realiza una operación Put, por lo que WriteBatch solo tiene esta Put). Cuando se envía, se escribe en la memoria MemTable de RocksDB. MemTable es esencialmente una SkipList, y los registros en caché están en orden. Al igual que InnoDB, los datos modificados por la transacción (WriteBatch) también se escribirán en el registro de escritura anticipada (WAL) antes del envío. Después de enviar la transacción, solo debe asegurarse de que el WAL se haya conservado y que los datos de MemTable no se escriban en los datos del disco. Expediente. Cuando el tamaño de MemTable alcanza el umbral (por ejemplo, 32 MB), RocksDB generará una nueva MemTable y la MemTable original pasará a ser de solo lectura (inmutable) y ya no recibirá nuevas operaciones de escritura. MemTable inmutable se volcará en un archivo sst por el hilo Flush de fondo. En el disco, RocksDB guarda datos a través de archivos sst, y cada archivo de registro guarda registros de WAL. En el disco, el archivo sst tiene capas. Cada capa tiene uno o más archivos sst. El tamaño del archivo es básicamente fijo. Cuanto más grande es la capa, más archivos hay en la capa, lo que significa que mayor es el tamaño total permitido para la capa, de la siguiente manera Como se muestra en la figura.
En general, los archivos volcados de la memoria se colocan en el Nivel 0, y los intervalos registrados de cada archivo sst en la capa Nivel 0 pueden superponerse. Por ejemplo, sst1 guarda 1.4.6.9 y sst2 guarda 5.6.10.20. Debido a que la tecnología de árbol LSM se utiliza para almacenar datos, un registro tendrá varias versiones. Por ejemplo, tanto sst1 como sst2 tienen el registro 6, pero la versión en sst2 está actualizada. De manera similar, existirán diferentes versiones del mismo registro entre diferentes niveles. A diferencia de Level0, los archivos sst de Level1 y niveles superiores no tendrán los mismos registros entre los archivos sst del mismo nivel.
Mecanismo de compactación
Dado que hay varias versiones de registro diferentes, es necesario que haya un mecanismo para la fusión de versiones, y este mecanismo es la compactación.
La imagen de arriba es una compactación de nivel 0, el proceso de compactar uno o más archivos de nivel 0 con archivos de nivel 1. Ya sea volcando el MemTable de la memoria al archivo sst o la compactación entre los archivos sst, es una lectura y escritura secuenciales desde el punto de vista de IO. Esto es ventajoso tanto para SSD como para HDD. El rendimiento secuencial de HDD es mucho mayor que aleatorio. Las características de rendimiento, para SSD, pueden evitar el efecto de amplificación de escritura de medios Flash causado por escritura aleatoria.
Proceso de lectura
Después de hablar sobre el proceso de escritura de RocksDB, veamos los componentes relacionados con la lectura. Como sigue:
La lectura en la base de datos se puede dividir en lectura actual y lectura instantánea. La llamada lectura actual es leer los datos de la última versión del registro, y la lectura instantánea es leer los datos de la versión especificada. Aquí solo discutimos las lecturas actuales, y las lecturas instantáneas se pueden analizar de manera similar. Debido a la estructura de almacenamiento del árbol LSM, la operación de lectura de RocksDB es bastante diferente de InnoDB. Esto se debe a que puede haber varias versiones grabadas de LSM (y a diferencia de InnoDB que tiene punteros conectados a las versiones anteriores y posteriores), y no puede pasar (significado estricto) Arriba) búsqueda binaria. Por lo tanto, Bloom Filter se introduce en RocksDB para optimizar la ruta de lectura. En RocksDB, Bloom Filter puede elegir tres métodos diferentes, que son basados en bloques de datos, basados en particiones y basados en archivos sst, Bloom El filtro se puede utilizar para determinar que la clave que se buscará no debe estar en un bloque / partición / sst. RocksDB se basa en un bloque de datos de forma predeterminada, que tiene la menor granularidad.
A continuación, analizaremos brevemente el proceso de lectura de RocksDB en función de las dos cifras anteriores. Una solicitud Get (key = bbb) se busca primero en la MemTable actual a través del Filtro Bloom. Si no se activa, se dirige a la MemTable de solo lectura. Si no se activa, significa que el key-vaule está en el archivo sst del disco o no existe. Por lo tanto, es necesario buscar la información de metadatos de cada archivo sst para encontrar todos los archivos sst cuyo intervalo de clave contenga el valor de clave solicitado. Y según el nivel de consulta de pequeño a grande. Para cada archivo sst, busque más a través de Bloom Filter, si lo golpea, lea el bloque de datos en el archivo sst en BlockCache, recorra la búsqueda dentro del bloque a través de la dicotomía y finalmente devuelva la clave correspondiente o NotFound, como se muestra en la siguiente figura.
Familia de columnas RocksDB
En RocksDB, una familia de columnas es un árbol LSM lógicamente independiente.Cada familia de columnas tiene su propia MemTable independiente, y todas las familias de columnas comparten un registro WAL. La compactación del archivo sst se realiza con la granularidad de la familia de columnas.
De forma predeterminada, una instancia de MyRocks incluye 2 familias de columnas, a saber, _sistema_ para almacenar metadatos del sistema y, por defecto, para almacenar datos de tabla creados por todos los usuarios. Por supuesto, cuando el usuario define la tabla, puede declarar el nombre de la familia de columnas utilizada por el índice agregando un comentario después del índice. El siguiente ejemplo colocará la clave principal y el índice único de rdbtable en las familias de columnas independientes cf_pk y cf_uid .
CREATE TABLE "rdbtable" (
"id" bigint(11) NOT NULL COMMENT '主键',
"userId" bigint(20) NOT NULL DEFAULT '0' COMMENT '用户ID',
PRIMARY KEY ("id") COMMENT 'cf_pk',
UNIQUE KEY "uid" ("userId") COMMENT 'cf_uid',
) ENGINE=ROCKSDB DEFAULT CHARSET=utf8
Características principales de MyRocks
Control de concurrencia
MyRocks implementa el control de concurrencia de transacciones basado en el bloqueo de filas y la información de bloqueo se almacena en la memoria. MyRocks admite bloqueos de fila compartidos y exclusivos. MyRocks utiliza la biblioteca RocksDB para la gestión de bloqueos al realizar actualizaciones en una transacción. Puede establecer unique_check = 0 para proteger los bloqueos de fila y las comprobaciones de claves únicas, lo que mejorará el rendimiento al importar datos en lotes, pero debe prestar atención a si las claves de datos están duplicadas al usarlas. Por lo tanto, la comprobación de unicidad de las instancias generales de alta disponibilidad se desactiva desde la biblioteca para Acelere la velocidad de reproducción de Binlog. En la actualidad, MyRocks no ha implementado bloqueos de espacios y existe un problema de lectura fantasma, que es el mismo que el nivel de aislamiento RR estándar, pero más débil que el RR de InnoDB.
Nivel de aislamiento de transacciones
MyRocks actualmente admite dos niveles de aislamiento de transacciones: lectura confirmada (RC) y lecturas repetibles (RR). MyRocks utiliza instantáneas para lograr estos dos niveles de aislamiento. En las lecturas repetibles, las instantáneas se mantienen en toda la transacción y los extractos de la transacción verán datos consistentes. En el nivel de aislamiento de lectura confirmada, la instantánea se mantendrá en cada declaración, por lo que la declaración SQL puede ver la modificación de la base de datos antes de que se ejecute la declaración. Como ocurre con la mayoría de las implementaciones de bases de datos, la instantánea se obtiene cuando la transacción ejecuta el primer SQL bajo el nivel de aislamiento RR en lugar de cuando comienza la transacción (inicio / inicio).
Al igual que InnoDB, MyRocks admite la lectura de instantáneas basada en MVCC, y la lectura de instantáneas no requiere bloqueo. MVCC se implementa a través de instantáneas de RocksDB, similar a la vista de lectura de InnoDB.
Copia de seguridad y restaurar
Al igual que InnoDB, MyRocks admite copias de seguridad físicas y lógicas en línea. La copia de seguridad lógica se realiza a través de herramientas de copia de seguridad de MySQL existentes, como mysqldump o mydumper. La copia de seguridad física se realiza de forma remota a través de la herramienta myrocks_hotbackup implementada por MyRocks, o la herramienta mariabackup proporcionada por mariadb se utiliza para la copia de seguridad local.
Ventajas comparativas con InnoDB
Aquellos que están familiarizados con MySQL saben que InnoDB es actualmente el motor de almacenamiento dominante en MySQL. Tiene la mayoría de las características que debería tener un motor de almacenamiento de base de datos relacional, como un mecanismo de transacción potente y completo. El funcionario de MySQL ha hecho de InnoDB una parte integral de MySQL. Las tablas del sistema MySQL recién agregadas utilizan InnoDB en lugar de MyISAM. . Entonces, ¿por qué Facebook no usó InnoDB y comenzó a desarrollar MyRocks basado en RocksDB? Obviamente, RocksDB debe tener sus propias ventajas. A continuación se compararán y analizarán desde múltiples dimensiones.
Espacio de almacenamiento más pequeño
Echemos un vistazo a los problemas que tiene InnoDB en la utilización del espacio de almacenamiento. Sabemos que InnoDB se basa en árboles B + y no puede evitar las operaciones SMO en los nodos del árbol. El siguiente es un diagrama esquemático de la división de nodos hoja.
Después de insertar user_id = 31, el nodo hoja Block1 activa la condición de división del nodo y se divide en 2 bloques desde el medio. Cada bloque ocupa aproximadamente la mitad del espacio original del Bloque1. Obviamente, la tasa de llenado de cada bloque es inferior al 50%, lo que significa En este momento hay la mitad de los fragmentos internos.
Para escenas insertadas secuencialmente, la tasa de llenado de los bloques es mayor. Pero para escenas aleatorias, la tasa de utilización del espacio de cada bloque cae drásticamente. Reflejado en su conjunto, el espacio de almacenamiento que ocupa una mesa es mucho mayor que el espacio necesario para los datos reales.
Sin embargo, RocksDB basado en el árbol LSM no tiene este problema. Cada vez que se insertan, actualizan y eliminan datos, se agregan a un nuevo archivo sst. Solo debe estar en orden dentro del archivo y no es necesario buscarlos. Insertar o actualizar una determinada posición de migración del orden global del árbol B +, lo que resuelve el problema de la tasa de llenado del nodo del árbol B + y mejora la tasa de utilización del espacio.
Además, el archivo sst de RocksDB es jerárquico, y la proporción de tamaño total de las capas superior e inferior es de hasta 10. En el caso de un gran volumen de datos, lo peor es solo alrededor del 10% de la ampliación del espacio, lo cual es una gran mejora en comparación con InnoDB.
Además, como se muestra en la figura anterior, RocksDB usa codificación de prefijo para las columnas de registro al almacenar. Se adopta un enfoque similar para cada fila de metadatos. Esto reduce aún más el espacio de almacenamiento requerido.
Método de compresión más eficiente
En el artículo anterior, presentamos el mecanismo de compresión basado en registros de InnoDB. La implementación aproximada es comprimir algunos campos de cada registro en una página de 16KB (Página) y luego almacenar todos los registros comprimidos de acuerdo con el tamaño de página especificado. . Por ejemplo, si key_block_size se establece en 8, es decir, se almacena como 8 KB después de la compresión. Si el tamaño de la página es 5 KB después de la compresión, se desperdician 3 KB de espacio de almacenamiento. InnoDB introdujo la compresión de página transparente en MySQL 5.7, pero los problemas anteriores aún existen.
RocksDB no se basa en páginas durante la compresión de registros y no necesita alinearse de acuerdo con key_block_size. Solo necesita alinearse de acuerdo con el tamaño del bloque del sistema de archivos (generalmente 4 KB) después de que se comprime cada archivo sst, y la sobrecarga de alineación de cada archivo sst de varios MB no excede 4 KB, mucho menos que la sobrecarga de alineación de la compresión InnoDB.
Comparación completa, MyRocks puede ahorrar más de la mitad del espacio de almacenamiento en comparación con InnoDB.
Optimización del reciclaje de versiones antiguas
En escenarios donde los registros se actualizan con frecuencia, si hay una lectura de instantánea consistente a largo plazo, InnoDB hará que el espacio para deshacer aumente drásticamente porque la versión anterior del registro no se puede purgar. Pero RocksDB puede aliviar el problema de forma eficaz. El siguiente es un ejemplo para ilustrar.
Suponga que se realiza una copia de seguridad lógica consistente en MySQL, y la transacción se inicia pero el registro cuya clave principal es 1 y el valor es 0 se realiza 1 millón de operaciones de incremento antes de que se realice la operación de selección en la tabla t. Según el principio, esta copia de seguridad debe leer el registro original con un valor de 0.
Para InnoDB, debido a que el ID de la transacción de respaldo es menor que el ID de la transacción que se incrementa en 1 millón de veces, el millón de registros de la versión anterior (es decir, deshacer) no se eliminarán, lo que significa que cuando se realiza una copia de seguridad del registro, 100 El retroceso de la versión 10,000, cada vez que la página de deshacer se lee aleatoriamente en función del puntero de deshacer en el registro, lo cual es muy ineficiente.
RocksDB está optimizado para la versión anterior del problema de purga de registros de InnoDB. Suponiendo que el número de secuencia del registro original es 2, esta versión es la versión visible de la transacción de respaldo. Para una versión más grande, descargue MemTable como un archivo sst en RocksDB, o Al compactar el archivo sst, se elimina la versión intermedia y solo se retiene la versión visible de la transacción activa actual y la última versión del registro. Esto no solo satisface los requisitos de MVCC, sino que también mejora la eficiencia de lectura de instantáneas, al tiempo que reduce el espacio de almacenamiento requerido.
Aumento de escritura más pequeño
En InnoDB, una operación de actualización de registros debe escribir la versión actual del registro en el registro de deshacer para la reversión de transacciones y MVCC (también debe escribir el rehacer deshacer antes de escribir la página de deshacer), y luego escribir un rehacer registrado después de la actualización Se utiliza para la recuperación de fallos, y luego la operación de actualización se puede escribir en la página de datos correspondiente (puede desencadenar la división del nodo del árbol B +). Para evitar el daño de la página de datos causado por el fallo durante el flasheo, es necesario escribir otra copia en Doublewrite Caché de disco.
Se puede ver que es necesario escribir muchas cosas en una actualización, especialmente si se trata de un escenario de actualización aleatorio, al escribir páginas de datos y Doublewrite, la proporción de amplificación de escritura es el tamaño de la página / tamaño de registro, lo cual es muy sorprendente.
La amplificación de escritura de RocksDB está relacionada con el nivel total de su archivo sst. La peor amplificación de escritura es aproximadamente (n-2) * 10, donde n es el número total de capas. Obviamente, será mucho mejor que InnoDB.
La reducción en la amplificación de escritura significa que las capacidades limitadas de almacenamiento y escritura se pueden usar de manera más eficiente.Se puede decir que RocksDB puede escribir más registros cuando se alcanza el cuello de botella en el rendimiento de E / S de almacenamiento.
Por otro lado, cada vez que se insertan, actualizan y eliminan datos de RocksDB, se escriben además en lugar de actualizarlos en su lugar. De esta manera, el backend de almacenamiento se escribe de forma secuencial, no aleatoria. Para un SSD basado en NAND Flash, sin considerar la optimización de la amplificación de escritura dentro del SSD, el mismo SSD se puede usar durante más tiempo en RocksDB que en InnoDB.
Rendimiento de escritura más rápido
Como se mencionó anteriormente, InnoDB actualiza los registros en su lugar, lo que significa que en escenarios DML aleatorios, cada operación de registro se escribe al azar (incluso si el índice secundario se elimina y luego se escribe en el nuevo registro, también es aleatorio ),Como se muestra abajo.
A diferencia de RocksDB, la escritura aleatoria se convierte en escritura secuencial, y la compactación de subprocesos múltiples que registra la fusión de las versiones antigua y nueva en segundo plano también es una operación de escritura secuencial por lotes. Para escenarios de inserción de lotes, RocksDB también puede desactivar la verificación de unicidad de registros para acelerar aún más la velocidad de importación de datos.
En el disco duro, esta optimización puede aprovechar el rendimiento de lectura y escritura secuencial de los discos mecánicos que son muy superiores a la lectura y escritura aleatoria. Incluso en SSD, dicha optimización es útil para el rendimiento de la base de datos.
Retraso maestro-esclavo más pequeño
En comparación con InnoDB, RocksDB también proporciona más opciones de optimización DML de la biblioteca.
Dado que las transacciones que se pueden reproducir en paralelo en la base de datos esclava están definitivamente libres de conflictos, es decir, no existe una relación de espera de bloqueo entre transacciones, RocksDB introdujo un parámetro de optimización rpl_skip_tx_api para ajustar el bloqueo en el registro para asegurar el aislamiento de la transacción. La operación acelera la velocidad de reproducción de la transacción.
De manera similar, para las características de la transacción de la base de datos, puede omitir la verificación de restricción de clave única de la operación de inserción de registros, y para las operaciones de actualización y eliminación, puede omitir la operación de búsqueda de registros, porque mientras no haya un error de implementación, el registro de la operación debe cumplirse. Vinculado a la transacción.
Otras características que InnoDB no tiene
MyRocks ha implementado un índice de orden inverso en MySQL 5.6 / 5.7, basado en la implementación de la familia de columnas de orden inverso. Obviamente, los índices de orden inverso no pueden usar la familia de columnas predeterminada. Basado en la función LSM, MyRocks también implementa el índice TTL a un costo muy bajo, similar a HBase. En comparación con la implementación TTL de los registros transversales de MongoDB para la eliminación de lotes, la función TTL en el almacenamiento LSM no requiere pérdida de rendimiento de mantenimiento adicional, excepto por la necesidad de guardar la marca de tiempo, y se puede fusionar y procesar directamente durante la compactación.
Escenarios aplicables de MyRocks
Según la descripción anterior, los escenarios comerciales aplicables a MyRocks se pueden resumir, que incluyen:
Negocio de Big Data
En comparación con InnoDB, RocksDB ocupa menos espacio de almacenamiento y tiene una mayor eficiencia de compresión, lo que es muy adecuado para empresas de gran volumen de datos. La siguiente imagen muestra la comparación de ocupación de espacio de RocksDB e InnoDB revelada por Facebook.
La siguiente imagen muestra los datos comprimidos de RocksDB, InnoDB y TokuDB en Internet
Combinando la figura anterior, se puede encontrar que el espacio de almacenamiento requerido por RocksDB es mucho más pequeño que InnoDB, e incluso mejor que TokuDB, que es conocido por su alta relación de compresión.
También se verificó en la prueba comercial interna de NetEase que la instancia de DDB de una empresa popular tenía que realizar operaciones frecuentes de expansión de tablas debido al rápido crecimiento del volumen de datos. El uso de MyRocks para reemplazar InnoDB descubrió que la tabla única InnoDB de 165 GB con compresión habilitada (key_block_size = 8) solo tiene 51 GB bajo la compresión MyRocks . Esta instancia de DDB tiene un total de 8 instancias de MySQL de alta disponibilidad y cada DBN contiene 10 tablas de InnoDB. Estadísticas Después de reemplazar MyRocks, el espacio de almacenamiento requerido para la instancia se redujo de 26 TB a menos de 9 TB. Esto ahorra dos tercios (aproximadamente 17 TB) de la sobrecarga de almacenamiento y también prolonga el período de tiempo que DBA necesita para expandirse por tabla. Suponiendo que DBA necesita expandirse una vez cada trimestre, ahora solo necesita expandirse una vez cada tres trimestres Eso es.
Negocio de escritura intensiva
MyRocks utiliza un método adicional para registrar operaciones DML, convirtiendo escrituras aleatorias en escrituras secuenciales, lo cual es muy adecuado para escenarios de negocios donde hay inserciones por lotes y actualizaciones frecuentes. La siguiente figura muestra el cuadro de comparación de rendimiento en el escenario de inserción de lotes publicado por Alibaba Cloud. En comparación con AliSQL basado en InnoDB, MyRocks ha logrado casi el doble de mejora de rendimiento.
En cierto escenario empresarial de actualización intensiva dentro de NetEase, también logró un mejor rendimiento.Además del rendimiento de escritura que no es más débil que el sistema de almacenamiento KV, también ocupa una cierta ventaja en el rendimiento de lectura. La comparación es la siguiente:
La imagen de arriba es el resultado de una prueba de 10 minutos en condiciones de lectura y escritura mixtas de solo lectura, 1: 1 y 2: 1. Se puede encontrar que MyRocks tiene un buen desempeño tanto en rendimiento como en latencia.
La figura anterior muestra el rendimiento de escritura y la latencia en un escenario mixto de lectura-escritura y solo escritura 1: 1. Se puede encontrar que MyRocks también funciona bien en el caso de 20 escrituras simultáneas.
Esquema de persistencia de caché
Debido a que MyRocks tiene un uso eficiente del espacio, en comparación con InnoDB, el mismo tamaño de memoria puede almacenar más datos en caché; en comparación con las alternativas de Redis como pika, tiene un mecanismo de recuperación de fallas maduro y una arquitectura de replicación maestro-esclavo; además, su menor El retraso de replicación facilita la expansión de la capacidad de lectura. Por lo tanto, MyRocks también es una alternativa de caché de Redis más adecuada.
Reemplazar TokuDB
En comparación con TokuDB, RocksDB / LevelDB no tiene un rendimiento de escritura y una relación de compresión inferiores, y tiene un mejor rendimiento de lectura; como motor de almacenamiento, lo utilizan los sistemas de bases de datos convencionales como MySQL, MongoDB, Kudu y TiDB, y tiene una mejor comunidad de código abierto. Soporte, localización de problemas más rápida y posibilidad de BugFix, código fuente más legible. Cuando TokuDB se vuelve cada vez menos prometedor, MyRocks se puede usar para reemplazar la instancia actual de TokuDB en línea.
Biblioteca esclava de bajo costo y baja latencia
El mejor rendimiento de escritura de MyRocks, junto con la optimización de parámetros específicos de la biblioteca, puede lograr una latencia de replicación más baja que InnoDB. Junto con la ventaja de un espacio de almacenamiento más pequeño, es adecuado para crear bibliotecas esclavas para fines especiales, como bibliotecas esclavas retrasadas para evitar la eliminación accidental de datos en línea y bibliotecas esclavas para análisis y estadísticas de big data.
para resumir
En general, en comparación con InnoDB, MyRocks ocupa menos espacio de almacenamiento, lo que puede reducir los costos de almacenamiento y mejorar la eficiencia del almacenamiento en caché del hotspot; tiene una relación de amplificación de escritura más pequeña, lo que puede usar el ancho de banda de E / S de almacenamiento de manera más eficiente; cambia escrituras aleatorias en escrituras secuenciales , Mejore el rendimiento de escritura y prolongue la vida útil del SSD; Optimice los parámetros para reducir el retraso de replicación maestro-esclavo. Por lo tanto, es muy adecuado para escenarios comerciales como un gran volumen de datos y una escritura intensiva. Además, como la misma solución de optimización de espacio y escritura de MySQL, MyRocks tiene una mejor ecología comunitaria y es adecuada para reemplazar instancias de TokuDB. La utilización eficiente de la caché de MyRocks, la recuperación de fallas madura y el mecanismo de replicación maestro-esclavo también lo hacen disponible como una solución de persistencia de Redis.
Materiales de referencia:
1. Análisis de implementación de RocksDB http://ks.netease.com/blog?id=10818
2 、 wiki de RocksDB https://github.com/facebook/rocksdb/wiki
3. Documentos relacionados con RocksDB y PPT publicados por Facebook, Percona y Alibaba
El texto completo ha terminado.
Disfrute de Linux y MySQL :)
El curso "MySQL Core Optimization" se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la capacitación de MySQL.