SALIDA: desacoplamiento de réplicas para almacenamiento distribuido de valores-clave Qiang

Resumen

Los almacenes de clave-valor (KV) distribuidos modernos emplean la replicación para la tolerancia a fallas mediante la distribución de copias de pares de KV en los nodos. Sin embargo, los almacenes KV distribuidos existentes normalmente administran todas las réplicas en la misma estructura de índice, lo que genera costos de E/S sustanciales más allá de la redundancia de replicación.
Proponemos un concepto llamado desacoplamiento de réplicas, que desacopla la administración de almacenamiento de las réplicas primarias y redundantes de las réplicas, lo que no solo alivia el costo de E/S en la indexación, sino que también proporciona un rendimiento escalable.
En particular, diseñamos un registro novedoso de dos capas que permite el orden ajustable de réplicas redundantes para un rendimiento equilibrado de lectura/escritura.
Implementamos un prototipo de tienda KV distribuida DEPART en Cassandra.

Los experimentos muestran que DEPART supera a Cassandra en todos los aspectos de rendimiento en varios niveles de coherencia y configuración de parámetros. Específicamente, bajo la configuración de consistencia eventual, los rendimientos de escritura, lectura, escaneo y actualización de DEPART son tan altos como 1.43x, 2.43x, 2.68x y 1.44x, respectivamente.

一、Introducción

Las tiendas de valor-clave (KV) son componentes fundamentales de la infraestructura de almacenamiento para las aplicaciones modernas de uso intensivo de datos, como la búsqueda web [14, 31], las redes sociales [57], el almacenamiento de fotos [10] y el almacenamiento en la nube [25, 37] . Para admitir el uso a gran escala, los almacenes KV generalmente se implementan de forma distribuida, almacenando objetos de datos (en forma de pares KV) en múltiples nodos. Los ejemplos de tiendas KV distribuidas incluyen BigTable [14], HBase [3], Dynamo [25], HyperDex [28], Cassandra [37], TiKV [50] y Riak [54].
En cualquier implementación a gran escala, las fallas se vuelven comunes, por lo que es fundamental proporcionar tolerancia a las fallas para una tienda KV distribuida. La replicación sigue siendo un mecanismo de tolerancia a fallas de uso común en las tiendas KV distribuidas modernas (incluidos los ejemplos enumerados anteriormente [3, 14, 25, 28, 37, 50, 54]). Específicamente, para cada par de KV escrito por un usuario, la replicación realiza múltiples copias exactas (llamadas réplicas) y distribuye las copias entre diferentes nodos para tolerar cualquier falla de nodo.
Una sutileza es que internamente cada nodo almacena todas las réplicas en la misma estructura de índice; a este enfoque lo llamamos indexación unificada. Por ejemplo, examinamos las bases de código de varias tiendas KV distribuidas de código abierto, incluidas HBase [3], HyperDex [28], Cassandra [37], TiKV [50] y ScyllaDB [60], todas las cuales emplean el índice unificado.

Un índice unificado es fácil de implementar para la administración de réplicas, pero también puede reducir significativamente el rendimiento de escritura y lectura.
Índice unificado significa que todos los datos están en el mismo árbol LSM

Primero, el árbol LSM realiza operaciones de compactación frecuentes, reescribiendo los pares KV actualmente almacenados para mantener su orden en cada nivel. Almacenar todas las réplicas en el mismo árbol LSM exacerba la amplificación de escritura más allá de la redundancia de replicación. Por ejemplo, con la replicación deshabilitada, la amplificación de escritura en Cassandra y TiKV fue de 6,5x y 13,8x, respectivamente; sin embargo, con la replicación triple, la amplificación de escritura en Cassandra y TiKV alcanzó 25,7x y 50,9x, respectivamente, lo que resultó en una amplificación de escritura de más del triple de veces (Sección 3.1). Además, dado que la lectura de un par KV requiere buscar en múltiples niveles en el árbol LSM, un índice unificado amplía el espacio de búsqueda y exacerba la amplificación de lectura. Por ejemplo, bajo replicación triple, Cassandra logró una amplificación de lectura de 34,6 veces (Sección 3.1).

Nuestra idea es que si usamos diferentes estructuras de índice para administrar el almacenamiento de diferentes tipos de réplicas, en lugar de poner todas las réplicas en la misma estructura de índice, no solo podemos aliviar la amplificación de lectura/escritura al reducir el tamaño de la estructura de índice para Cada tipo de réplica también permite una gestión de almacenamiento flexible para adaptarse a diferentes compromisos de diseño. Presentamos un caso al proponer el desacoplamiento de réplicas, es decir, desacoplar la administración de almacenamiento de las réplicas de cada par de KV en función de la réplica principal (es decir, la copia principal del par de KV) y la réplica redundante (es decir, la copia restante de el KV) para desacoplar la réplica principal apartada). Usamos LSM-tree para administrar solo la copia principal, para preservar las características de diseño de LSM-tree, pero de una manera más liviana; al mismo tiempo, usamos una estructura de índice más simple pero ajustable para copias redundantes, para equilibrar de acuerdo con requisitos de rendimiento Rendimiento de lectura y escritura.

En este documento, diseñamos el desacoplamiento de réplicas en DEPART, un novedoso almacén de KV distribuido que desacopla la administración de almacenamiento de réplicas primarias y redundantes para la tolerancia a fallas. DEPART está construido sobre Cassandra [37]. Permite una diferenciación ligera de copias primarias y redundantes de réplicas en rutas de E/S críticas, al tiempo que mantiene la organización de datos existente de Cassandra y las funciones de consistencia configurables. Al administrar réplicas primarias en LSM-tree, DEPART propone un registro novedoso de dos capas para administrar réplicas redundantes con un orden ajustable para lograr un rendimiento equilibrado de lectura y escritura. La idea es publicar escrituras por lotes de réplicas redundantes en un registro global de solo agregar para lograr un alto rendimiento de escritura. Además, divide el registro global en varios registros locales. En particular, el orden de los pares de KV en cada registro local se puede ajustar mediante un único parámetro para equilibrar el rendimiento de lectura y escritura de las réplicas redundantes; por ejemplo,
dado un alto nivel de consistencia de lectura (o escritura) (es decir, el número de lecturas). (o escribir) réplicas; consulte §2.3), el registro de dos niveles se puede ajustar a favor de un alto rendimiento de lectura (o escritura). Un registro de dos niveles también mejora el rendimiento de la conmutación por error al organizar los pares de KV por diferentes rangos de claves y restringir las operaciones de recuperación para acceder solo a los pares de KV del rango relevante.

* Contribuir:

Primero:
haga preguntas y use Cassandra y Tikv existentes para ilustrar los problemas existentes en el sistema KV distribuido actual. Amplia amplificación de escritura, amplificación de lectura
Analizamos dos almacenes KV distribuidos de última generación, Cassandra y TiKV, y revelamos limitaciones de rendimiento debido a la indexación uniforme de las réplicas.
Segundo:
Entonces comienza el diseño, una de las dos copias será reestructurada. La paralelización permite una recuperación rápida de los errores.
• Diseñamos DEPART, que implementa el desacoplamiento de réplicas y tiene varias características de diseño clave: (i) distinción liviana de réplicas primarias y redundantes, (ii) registro de dos niveles con orden ajustable para el diseño de réplicas redundantes y (iii) recuperación rápida de fallas a través de paralelización
• Estamos implementando DEPART en Cassandra v3.11.4 [2]. Los experimentos muestran que DEPART supera a Cassandra en varios entornos. Por ejemplo, para el caso de una coherencia eventual, DEPART logra ganancias de rendimiento de 1,43x, 2,43x, 2,68x y 1,44x sobre Cassandra en términos de escrituras, lecturas, escaneos y actualizaciones, respectivamente. DEPART también mantiene sus ganancias de rendimiento de lectura y escritura bajo varias configuraciones de niveles de consistencia.

2. Fondo

Tomamos Cassandra [37] (como línea de base para nuestro diseño DEPART) como ejemplo para describir los antecedentes del almacenamiento KV distribuido, incluida su arquitectura de almacenamiento, el flujo de trabajo de E/S y la gestión de coherencia.

2.1 Arquitectura de almacenamiento

**Organización de datos. **El almacenamiento de KV distribuido divide los pares de KV en los clústeres de nodos. En Cassandra, los pares de KV se dividen en función de un hashing consistente [33], que también es adoptado por otras tiendas KV distribuidas de producción [25, 41, 54, 60]. El hashing coherente asocia las posiciones de todos los nodos con un anillo hash y asigna de manera determinista cada par de KV a un nodo. Específicamente, consideramos un almacén KV distribuido con n nodos físicos, cada uno de los cuales está asociado con v nodos virtuales. Divide el anillo hash en rangos n × v, cada uno de los cuales cubre un nodo virtual. Por ejemplo, como se muestra en la Figura 1, hay n = 5 nodos físicos (es decir, N0 a N4) y cada nodo físico tiene v = 2 nodos virtuales. Un anillo hash contiene 2 × 5 = 10 rangos, como (0-10), (11-20), ..., (91-100). Cada rango está asociado con el nodo virtual más cercano en el sentido de las agujas del reloj y el nodo físico correspondiente en el anillo hash; por ejemplo, los rangos (0-10) y (51-60) están asignados a N0. Para cada par de KV, el hashing consistente genera un hash de la clave en algún lugar del anillo hash (por ejemplo, usando MurmurHash [6] en Cassandra). Los pares KV luego se almacenan en los nodos físicos correspondientes asociados con el rango.
问题：是每个node写一个lsm-tree？
La replicación se usa a menudo en los almacenes de KV distribuidos modernos [3, 14, 25, 28, 37, 50] para lograr la tolerancia a fallas al distribuir copias de cada par de KV en diferentes nodos para proteger contra fallas de nodos. En Cassandra, las réplicas se almacenan en una secuencia de nodos en el sentido de las agujas del reloj en el anillo hash, indicado como Ni,N(i+1) mod n, N(i+2) mod n, ..., donde 0 ≤ i ≤ n- 1 y Ni (es decir, el primer nodo en la secuencia de nodos) son los nodos a los que el par KV se basa en un hash consistente. Nos referimos a la réplica almacenada en Ni como la réplica principal, y las réplicas restantes almacenadas en nodos físicos consecutivos en el sentido de las agujas del reloj en el anillo hash como réplicas redundantes.

Almacenamiento interno con árbol LSM. Cada nodo gestiona internamente pares de KV con algún tipo de estructura de índice. En particular, LSM-tree [48] es una de las estructuras de índice más utilizadas en las tiendas KV distribuidas, incluidas Cassandra et al [3, 20, 28, 41, 50, 60]. El almacén de KV del árbol LSM organiza los pares de KV en un árbol de varios niveles y mantiene los pares de KV ordenados por clave en cada nivel para permitir una lectura, escritura y escaneo eficientes. Como se muestra en la Figura 1, el almacenamiento de KV en árbol LSM mantiene una estructura de índice basada en árbol, de varios niveles (denotados como L0, L1, ...) y la capacidad sigue aumentando. Cada nivel almacena pares de KV en unidades de archivos llamado SSTables. Primero agrega los pares KV escritos a un registro de escritura anticipada (WAL) en el disco y luego los inserta en una MemTable en memoria. Cuando la MemTable está llena, el almacén KV del árbol LSM convierte la MemTable en una MemTable inmutable, es decir, se vacía al nivel L0 más bajo como una SSTable. Cuando el nivel inferior alcanza el límite de capacidad, el almacén de KV del árbol LSM fusiona los pares de KV de nivel inferior con el siguiente nivel superior a través de la compresión. Para mantener ordenados los pares KV en cada nivel, la operación de compactación primero lee los pares KV de ambos niveles, fusiona los pares KV ordenados y luego vuelve a escribir los pares KV ordenados. Por lo tanto, la compactación incurre en E/S adicionales durante las escrituras, lo que resulta en una amplificación de escritura. Además, dado que los pares KV no están ordenados entre capas, la lectura de un par KV debe buscar hacia arriba desde la capa más baja L0, lo que da como resultado una amplificación de lectura. Se ha demostrado que tanto la amplificación de escritura como la de lectura causan una degradación significativa del rendimiento en el almacenamiento KV de árbol LSM [12, 43, 51].

2.2 Flujos de trabajo de E/S

Escribe un flujo de trabajo. Escribir un par KV en Cassandra funciona de la siguiente manera. El cliente primero selecciona aleatoriamente y se conecta a uno de los nodos, llamado coordinador, y le envía el par KV. El coordinador determina qué nodos almacenan copias primarias y redundantes en función de un hash coherente. Luego reenvía el par KV al nodo.
Lea sobre el flujo de trabajo. Leer un par KV en Cassandra es similar a escribir un par KV y funciona de la siguiente manera. Los clientes primero seleccionan y contactan a un coordinador. Emite una solicitud de lectura al coordinador, y el coordinador encuentra un nodo que almacena una copia del par KV (tanto primario como redundante). Para el balanceo de carga, el coordinador prefiere leer pares KV de nodos con baja latencia, determinada por el módulo de snitching dinámico [5]. Luego devuelve el par KV al cliente.

2.3 Gestión de coherencia

Gestión de consistencia
Cassandra admite diferentes modos de consistencia, como consistencia fuerte y consistencia eventual. Se configuran ajustando el factor de replicación (indicado por k) y el nivel de coherencia de lectura (RCL) y el nivel de coherencia de escritura (WCL). El factor de replicación k se define como el número total de réplicas para la tolerancia a fallas. RCL y WCL se definen como el número mínimo de réplicas (ya sean primarias o redundantes) leídas y escritas por el coordinador para reconocer operaciones de lectura y escritura correctas, respectivamente. Tanto RCL como WCL se establecen en números enteros del 1 al k. Si WCL+RCL>k, se proporciona consistencia sólida; si WCL+RCL ≤ k, se proporciona consistencia eventual. Tanto WCL como RCL están configurados en 1 en Cassandra de forma predeterminada.
k设置多少？？？

desacoplamiento de 3 copias

Para motivar el desacoplamiento de réplicas, describimos las limitaciones de los índices unificados que administran todas las réplicas en la administración del almacenamiento interno (Sección 3.1). También describimos el diseño de desacoplamiento de la réplica ingenua que se utilizó para motivar nuestro diseño DEPART (Sección 3.2).

3.1 Índice unificado y sus limitaciones

Recordando §1, las tiendas KV distribuidas existentes (por ejemplo, [3, 28, 37, 50]) emplean principalmente un índice unificado, donde todas las réplicas (incluidas todas las réplicas primarias y redundantes) especificadas para cada nodo están en el mismo administrado bajo la estructura del índice Mostramos que el índice unificado es la causa principal de la amplificación significativamente exacerbada de escritura y lectura del árbol LSM, en lugar de las escrituras adicionales de la replicación.
如何证明的？

Limitación #1: aumenta la amplificación de escritura. Con un índice unificado, cada nodo trata todas las réplicas como pares KV regulares y las almacena indiscriminadamente en el mismo árbol LSM (Figura 1). Para mostrar cómo exacerba la amplificación de escritura, evaluamos la amplificación de escritura de dos tiendas KV distribuidas de código abierto Cassandra (v3.11.4) [2] y TiKV (versión 4.0) [50]. Específicamente, implementamos Cassandra y TiKV en un clúster de 5 nodos con configuraciones predeterminadas (consulte la Sección 5 para obtener más detalles). Configuramos una máquina cliente para emitir pares de 300M KV, cada uno con un tamaño de 1 KiB, al clúster que inicialmente tenía almacenamiento libre. Consideramos ninguna replicación (k = 1), doble replicación (k = 2) y triple replicación (k = 3). La figura 2(a) muestra que la ausencia de replicación da como resultado una amplificación de escritura de 6,5x para Cassandra debido a la sobrecarga de compresión en la que incurre el árbol LSM. Sin embargo, con la replicación triple, la amplificación de escritura aumentó a 25,7 veces, aproximadamente 4 veces la amplificación de escritura sin duplicación. También observamos una tendencia similar para TiKV, donde la amplificación de escritura aumentó de 13,8x a 50,9x (es decir, un aumento de 3,7x).
不会因为相同而被更新掉吗？复制的key和key本身有什么不同吗？复制的流程是如何走的

Además, el aumento en la amplificación de escritura es más pronunciado con una tendencia superlineal a medida que aumenta el tamaño de la tienda KV. La razón es que un tamaño de almacenamiento KV más grande aumenta la cantidad de capas en el árbol LSM, lo que da como resultado una mayor sobrecarga de compresión y una mayor amplificación de escritura. Configuramos una máquina cliente para emitir escrituras de pares de KV de 100M, 300M y 600M, cada uno de tamaño 1 KiB, al clúster inicialmente vacío.

控制了每个kv对的大小保持不变，来做对比。改变总的数据量

Aquí nos centramos en Cassandra. La Figura 2(b) muestra la amplificación de escritura de Cassandra para diferentes tamaños de tiendas KV. El aumento en la amplificación de escritura con replicación triple en relación con la ausencia de replicación también aumenta para almacenes de datos más grandes. Por ejemplo, la replicación triple tiene una amplificación de escritura de 3,4x a 100 millones de pares KV en comparación con la ausencia de replicación, que se convierte en 4,5x a 600 millones de pares KV. Esta tendencia superlineal también significa que los tamaños de tienda KV más grandes limitan la escalabilidad de los índices unificados.

Limitación n.º 2: aumenta la ampliación de la lectura. Los índices uniformes también exacerban severamente la amplificación de lectura. La razón principal es que todas las réplicas se almacenan en el mismo árbol LSM, lo que amplía el espacio de búsqueda de pares KV. Evaluamos la amplificación de lectura para Cassandra y TiKV con la configuración anterior, mientras que la máquina cliente emitió 30 millones de lecturas a un par existente de 300 millones de KV, cada una con un tamaño almacenado de 1 KiB. La Figura 3(a) muestra que para Cassandra, la amplificación de lectura aumentó de 7,8 veces sin repeticiones a 34,6 veces para repeticiones triples (es decir, un aumento de 4,4 veces). Observamos una tendencia similar para TiKV.

Además, investigamos el efecto del tamaño de la tienda KV en la amplificación de lectura. Aquí nos centramos en Cassandra. Primero emitimos 100 millones, 300 millones y 600 millones de escrituras de pares de KV de 1 KiB en el clúster vacío inicial y luego emitimos 30 millones de lecturas en los pares de KV existentes. La Figura 3(b) muestra un aumento superlineal en la amplificación de lectura a medida que aumenta el tamaño de la tienda KV de Cassandra.

En resumen, cuando se abre la copia, la sobrecarga de lectura y escritura se vuelve mayor, y los datos se prueban para probarlo. Esto es fácil de entender, es decir, la cantidad total de datos ha aumentado y, por supuesto, este problema ¿ocurrira? ? ? ?
写放大是如何测试的？那个数据是写放大？

3.2motivación

Nuestro análisis en §3.1 muestra que un índice unificado exacerba la amplificación de escritura y lectura debido al alto costo de administrar todas las réplicas en un solo árbol LSM. Esto nos motiva a explorar el potencial del desacoplamiento de réplicas, que desacopla réplicas primarias y redundantes de réplicas y las administra en estructuras de índice separadas. Primero consideramos dos enfoques simples para el desacoplamiento de la replicación y luego motivamos nuestro diseño.

Enfoque ingenuo. Una forma sencilla de desacoplar réplicas es implementar dos árboles LSM, uno para la réplica principal y otro para todas las réplicas redundantes. Sin embargo, el árbol LSM de copias redundantes todavía tiene un gran tamaño (especialmente para un factor de replicación grande) y no se accede a todas las copias redundantes en cada operación de E/S. Por ejemplo, para recuperarse de una falla de un solo nodo bajo triple replicación, en promedio solo se accede a la mitad de las copias redundantes. Por lo tanto, hay E/S adicionales para buscar en todo el árbol LSM un subconjunto de copias redundantes.
问题是剩下的两个冗余副本直接放在一个LSM-Tree里面，依然会存在搜索过多的问题。

Otra forma sencilla de desacoplar réplicas es administrar k árboles LSM (k es el factor de replicación) para k réplicas derivadas de cada par de KV. Por ejemplo, para Cassandra con replicación triple, el nodo Ni recibe copias redundantes cuyas copias primarias correspondientes se almacenan en los nodos N(i-1) mod n y N(i-2) mod n (donde 0 ≤ i ≤ n- 1 y n son el número de nodos físicos). Luego usamos tres árboles LSM en el nodo Ni, uno de los cuales almacena la copia principal y los otros dos almacenan copias redundantes de los nodos N(i-1) mod n y N(i-2) mod n respectivamente.
每一个副本一个LSM-Tree，本身不符合纠删编码的条带话管理策略，当然这个也是可以调整的，就是如何减少总的数据量小的情况下，确保检索。

Sin embargo, el mantenimiento de varios árboles LSM puede generar una sobrecarga de memoria y de E/S significativa. Dado que cada árbol LSM tiene su propia MemTable y la MemTable inmutable, la sobrecarga de memoria para el factor de replicación k se magnifica k veces. Específicamente, si el tamaño de MemTable es mMiB y el tamaño del clúster es n, el costo de memoria de Cassandra es m×nMiB porque cada nodo mantiene un árbol LSM. Sin embargo, cuando se usan k LSM-trees en cada nodo, el costo de la memoria se convierte en k×m×n MiB, que es k veces mayor que en Cassandra. Tenga en cuenta que si reducimos el tamaño de MemTable por árbol LSM para limitar la sobrecarga de memoria, se reducirá la eficiencia de vaciar MemTable en el disco y, por lo tanto, se reducirá el rendimiento de escritura del usuario [7, 8].
内存开销的增加！！！
Además, cada árbol LSM incurre en su propia sobrecarga de compresión para mantener un orden completo en cada nivel. Por lo tanto, la compactación sigue siendo costosa y la compactación de varios árboles LSM en el mismo nodo compite por el ancho de banda del disco, lo que perjudica el rendimiento general de E/S. Nuestra evaluación (Exp#1 en la Sección 5.2) muestra que incluso si las réplicas son administradas por diferentes árboles LSM, desacoplar réplicas de múltiples árboles LSM solo brinda ganancias de rendimiento limitadas.
compaction的时候IO的竞争，导致性能的提升有限

nuestra manera. Recuerde que un árbol LSM siempre mantiene un orden completo en cada nivel. El uso de un solo árbol LSM para todas las réplicas en un índice unificado, o el uso de varios árboles LSM para el desacoplamiento de réplicas, puede ser beneficioso para el rendimiento de lectura, pero ambos generan una sobrecarga de compresión bastante alta, lo que ralentiza el rendimiento de escritura. En particular, los diferentes niveles de consistencia implican diferentes requisitos de rendimiento de lectura y escritura para las réplicas, por lo que los niveles altos de consistencia de lectura (o escritura) requieren un alto rendimiento de lectura (o escritura) para las réplicas. Esto nos motiva a diseñar una nueva solución de administración de almacenamiento que admita el pedido ajustable desacoplado de réplicas para equilibrar el rendimiento de lectura y escritura.

所以就是把读写分开用不同的索引方式进行解决问题。

4 DISEÑO DE SALIDA

Proponemos DEPART, una tienda KV distribuida construida sobre Cassandra, que logra el desacoplamiento de réplicas al separar la administración de almacenamiento de réplicas primarias y redundantes. Presentamos su arquitectura (§4.1) e ilustramos sus técnicas de diseño (§4.2-§4.5)

4.1 Arquitectura general

DEPART desacopla la administración de almacenamiento para réplicas primarias y redundantes para un alto rendimiento. Administra la copia principal en el árbol LSM y también administra las copias redundantes en un registro novedoso de dos niveles cuyo orden se puede ajustar de acuerdo con los requisitos de rendimiento. Mantener solo la copia principal en el árbol LSM conserva las características de diseño de lectura, escritura y escaneo del árbol LSM, pero de una manera más liviana, ya que el tamaño del árbol LSM ahora es significativamente más pequeño sin copias redundantes. Además, el orden ajustable del registro de dos niveles permite un rendimiento equilibrado de lectura y escritura en diferentes configuraciones de nivel de consistencia.

La figura 4 muestra la arquitectura de DEPART. Tenga en cuenta que DEPART solo modifica los módulos de almacenamiento interno de cada nodo de Cassandra, pero conserva la gestión entre nodos en Cassandra (p. ej., hashing coherente para la organización de datos y la gestión de coherencia). En resumen, DEPART aborda varios desafíos de diseño a través de una variedad de técnicas.

• Diferenciación de replicación ligera. DEPART separa las copias primarias y redundantes en los módulos de almacenamiento de cada nodo para una gestión independiente. Su diferenciación de réplicas es liviana y se basa en cálculos hash simples e incurre en una sobrecarga limitada en las rutas de E/S críticas (Sección 4.2).

• Diseño de troncos de dos pisos. DEPART administra copias redundantes a través de dos capas de registros para lograr una escritura rápida y una recuperación eficiente. Primero agrega copias redundantes al registro global como escrituras masivas secuenciales. Luego divide el registro global en varios registros locales en segundo plano (Sección 4.3).

• Clasificación ajustable. DEPART también proporciona un esquema de clasificación ajustable para el diseño de registro de dos niveles, que puede ajustar el grado de clasificación de las copias redundantes a través de un solo parámetro, a fin de equilibrar el rendimiento de lectura y escritura del acceso a las copias redundantes (Sección 4.4).

• Recuperación en paralelo. DEPART adopta un esquema de recuperación paralelo, que lee y escribe la copia principal y la copia redundante en paralelo durante el proceso de recuperación, logrando así un alto rendimiento de recuperación (§4.5).

4.2 Diferenciación de réplicas

DEPART distingue los pares de KV escritos en los módulos de almacenamiento de cada nodo como primarios o redundantes. La Figura 5 muestra el flujo de trabajo de diferenciación de réplicas. Recuerde que el coordinador reenvía k copias del par KV a una secuencia de k nodos en el sentido de las agujas del reloj en el anillo hash, donde la clave para el par KV se cifra en el primer nodo de la secuencia de nodos (Sección 2. ). Cuando un nodo, digamos N, recibe una de las réplicas del par KV del coordinador, realiza el mismo cálculo hash (es decir, MurmurHash en Cassandra [6]) en la clave de la réplica y determina que la clave del nodo está codificada. listado. Si el nodo resultante es idéntico a N, entonces N es el primer nodo en la secuencia de nodos, llamamos a la copia copia primaria; de lo contrario, llamamos a la copia copia redundante.

Cada nodo mantiene un registro de escritura anticipada (WAL) y una MemTable para el árbol LSM (para réplicas principales) y un registro de dos niveles (para réplicas redundantes). Después de que el nodo distingue si el par KV es la copia principal o la copia redundante, escribe el par KV en el WAL y MemTable correspondientes y confirma al coordinador. Cuando la MemTable está llena y se vuelve inmutable, el nodo vacía la MemTable inmutable al árbol LSM o al registro de dos niveles. La lógica para la diferenciación de réplicas es liviana porque requiere un cálculo hash adicional en cada nodo de almacenamiento en la ruta de E/S crítica (un total de k cálculos adicionales para el factor de replicación k). Nuestros experimentos muestran que el tiempo de diferenciación es inferior al 0,4% del tiempo total de escritura (Exp#5 en la Sección 5.2).
这里的额外的计算是什么？为啥hash，hash后为啥就少了？

4.3 Diseño de registro de dos niveles

Cada nodo mantiene un registro de dos niveles, que está diseñado para administrar copias redundantes y tiene las siguientes características de diseño. En primer lugar, admite escrituras rápidas para réplicas redundantes, incluso si la cantidad de réplicas redundantes es mucho mayor que la de las réplicas principales y aumenta con el factor de replicación. En segundo lugar, admite la ordenación ajustable para acomodar diferentes niveles de consistencia (Sección 4.4). En tercer lugar, admite la recuperación paralela eficiente de cualquier nodo fallido al permitir que las copias redundantes se lean rápidamente en paralelo.

La figura 6 muestra la arquitectura del registro de dos niveles en cada nodo. Después de recibir las réplicas, el nodo primero escribe la secuencia de réplicas redundantes en los lotes de registro global. Un subproceso en segundo plano recupera continuamente copias redundantes del registro global y las divide en varios registros locales. A continuación, detallamos los diseños de registro global y registro local.

Solo se agregan registros globales. Para escrituras rápidas, cada nodo escribe todas las copias redundantes de pares KV (vaciados de MemTables inmutables) en un registro global de solo anexar. Todas las copias redundantes se agrupan en segmentos y se escriben como lotes secuenciales adjuntos al encabezado del registro global. Tenga en cuenta que el registro global simplemente almacena todas las copias redundantes sin mantener ninguna estructura de índice adicional. Por lo tanto, logra un alto rendimiento de escritura con copias redundantes.

Mantener todas las copias redundantes en el registro global logra un alto rendimiento de escritura, pero presenta dos problemas. En primer lugar, restaure el rendimiento degradado. Para copias redundantes en el registro global, las copias primarias correspondientes pueden ubicarse en diferentes nodos. Cuando falla un nodo, solo se requiere una copia redundante parcial en el registro global (es decir, una copia redundante cuya copia principal correspondiente reside en el nodo fallido) para la recuperación. Por lo tanto, la recuperación solo dará como resultado un acceso parcial al registro global, lo que generará una gran cantidad de operaciones de E/S aleatorias. En segundo lugar, aumentan los costos de recolección de basura. Dado que los nuevos pares KV se agregan al encabezado del registro, los pares KV no válidos (o obsoletos) no se pueden sobrescribir, por lo que ocupan mucho espacio. Esto puede resultar en una sobrecarga de almacenamiento significativa, especialmente en cargas de trabajo de actualización intensiva. La recolección de elementos no utilizados puede reducir los costos de almacenamiento mediante la recuperación continua de espacio libre para pares de KV no válidos desde la parte final del registro, pero inevitablemente introduce una gran cantidad de E/S adicionales para leer segmentos desde la parte final del registro y volver a escribir pares de KV válidos en la parte superior. del registro

Dividir en registros locales. Para lograr una recuperación rápida, DEPART mantiene un subproceso en segundo plano que divide continuamente el registro global en varios registros locales, y cada registro local solo mantiene una copia redundante de su copia principal correspondiente almacenada en el mismo nodo. Esto permite la recuperación de cualquier nodo fallido para acceder solo a los registros locales asociados con el nodo fallido. Tenga en cuenta que cada nodo solo necesita mantener k-1 registros locales (recuerde que k es el factor de replicación), porque el hashing consistente distribuye réplicas en una secuencia de nodos en el sentido de las agujas del reloj en el anillo hash, y cada nodo almacena solo una copia redundante de como máximo k-1 nodos.

La operación de división funciona de la siguiente manera. Primero recupera un número configurable de segmentos, denominados colectivamente divisiones, de la cola del registro global. Luego reorganiza la división de réplicas redundantes en varias subdivisiones, cada subdivisión contiene solo réplicas redundantes, con sus réplicas principales correspondientes en el mismo nodo. Finalmente, vuelve a escribir cada subdivisión en un registro local separado de forma de solo agregar y publica las escrituras en diferentes registros locales en paralelo.

Durante la división, DEPART también descarta cualquier par KV no válido en el segmento seleccionado. Por lo tanto, no desencadena explícitamente la recolección de elementos no utilizados; en su lugar, implementa la recolección de elementos no utilizados durante la operación de división para ahorrar operaciones de E/S adicionales.

Para cada copia redundante, cada nodo necesita determinar el nodo donde se encuentra su copia primaria correspondiente. Se puede hacer localmente dentro de los nodos en función de la diferenciación de réplicas (Sección 4.2).
拆分操作和GC同步进行减少IO

Agrupación basada en rangos en registros locales. Aunque dividir el registro global en varios registros locales puede aliviar la sobrecarga de recuperación y recolección de basura, el beneficio aún es limitado porque el rango de anillos hash almacenados en cada nodo no es necesariamente contiguo (por ejemplo, en la Figura 1, el nodo N0 almacena el rango [0 ,10] y [51,60]). Restaurar un par de KV para un rango arbitrario solo requiere acceso a la copia redundante de ese rango, lo que aún genera acceso parcial al registro local y emite E/S aleatorias.

Mejoramos cada registro local mediante la gestión de pares KV con agrupación basada en rango. La figura 7 muestra la idea de agrupación basada en rangos. Cada registro local se divide a su vez en múltiples grupos de rangos, y cada grupo de rangos corresponde a un rango en el anillo hash. Tenga en cuenta que los diferentes grupos de rango en cada registro local no se superponen en las claves, por lo que se pueden administrar de forma independiente. Por ejemplo, para el nodo N2 en la Figura 7, el registro local LOG0 almacena copias redundantes y su copia principal correspondiente reside en el nodo N0. Dado que el nodo N0 tiene dos rangos, [0,10] y [51,60], LOG0 ahora contiene dos grupos de rangos, cada uno con copias redundantes de [0,10] y [51,60]. La agrupación basada en rango se puede lograr comparando la clave (o su hash) con los límites de cada rango en el anillo hash basado en un hash consistente (Sección 2.1). Todavía garantiza que las escrituras en cada grupo de rango en el registro local se realicen en lotes de solo agregar. El número de grupos de ámbito en el registro local y el número de ámbitos en Cassandra se pueden configurar con el parámetro num tokens [2]. La agrupación basada en rango mejora el rendimiento de la recuperación al acceder solo a los pares KV en el grupo de rango correspondiente en lugar de a todos los pares KV en todo el registro local.

En la agrupación basada en rango, cuando los pares de KV en el registro global se escriben en el registro local en la operación de división, DEPART clasifica aún más todos los pares de KV para cada rango y luego almacena los pares de KV en el registro local para el rango. grupo; nos referimos a la clasificación de pares de rangos KV en una operación dividida como una ejecución de clasificación. Por lo tanto, cada grupo de rango puede almacenar varias ejecuciones de ordenación y diferentes ejecuciones de ordenación en el mismo grupo de rango pueden tener claves superpuestas. La clasificación ajustable es posible mediante la clasificación de grupos de ámbito de gestión de ejecución (Sección 4.4).

Leer de un registro de dos niveles. Para leer un par KV de un registro de dos niveles, DEPART primero verifica los segmentos en el registro global uno por uno, comenzando con el más nuevo. Tenga en cuenta que la estructura interna de cada segmento es similar a las SSTables en el árbol LSM, por lo que DEPART primero lee los metadatos del segmento y lee el par KV correspondiente según el desplazamiento en los metadatos. Si no se encuentra ningún par de KV en el registro global, DEPART busca el grupo de rango correspondiente y localiza la clave comparándola con las claves de límite del grupo de rango. Dado que cada grupo de rango contiene varias ejecuciones de clasificación y los pares de KV en las ejecuciones de clasificación están completamente ordenados, DEPART busca desde las ejecuciones de ordenación más nuevas hasta las más antiguas y utiliza la búsqueda binaria para encontrar las claves en las ejecuciones de ordenación.

4.4 Clasificación ajustable

Recuerde que cada grupo de rango en el registro local puede contener varias ejecuciones de clasificación y que los pares de KV de las ejecuciones de clasificación dentro de un grupo de rango no están completamente ordenados. Si un grupo de rango contiene demasiadas ejecuciones de ordenación, el rendimiento de lectura de las réplicas redundantes se degradará, especialmente para los niveles altos de consistencia de lectura (Sección 2.3) donde las operaciones de lectura acceden a las réplicas primarias y redundantes. Por lo tanto, ampliamos el registro de dos niveles con un esquema de orden ajustable, donde los usuarios pueden configurar un solo parámetro para ajustar el grado de orden de cada grupo de rango para cumplir con diferentes requisitos de consistencia.

DEPART ajusta el grado de clasificación para varias ejecuciones de clasificación utilizando un umbral S configurable por el usuario, un número entero positivo que controla el número máximo de ejecuciones de clasificación permitidas en cada grupo de rango. La Figura 8 muestra el concepto de un esquema de clasificación ajustable. Para cada nueva ejecución de clasificación resultante de una operación dividida, DEPART comprueba primero si el número de ejecuciones de clasificación existentes en el grupo de rango alcanza un umbral. De lo contrario, agrega la nueva ejecución de clasificación de la operación dividida directamente al grupo de rango; de lo contrario, fusiona la nueva ejecución de clasificación con la ejecución existente en una única ejecución de clasificación. La operación de ordenación por combinación es similar a la operación compacta en un árbol LSM y consta de tres pasos: (i) lee todas las ejecuciones de ordenación existentes del grupo de rango; (ii) fusiona todos los pares KV en la nueva ejecución de ordenación con la existente Todos los pares KV en una ejecución de clasificación se fusionan, y si hay varios pares KV con la misma clave en diferentes ejecuciones de clasificación, solo se conservan los pares KV en la última ejecución de clasificación y se descartan los más antiguos; (iii) para el rango de reescritura grupos Consideramos dos casos especiales con diferentes valores de S.

• Caso 1: S = 1. En este caso, cada grupo de rango siempre clasifica la ejecución ordenada entrante con la ejecución ordenada almacenada actualmente, por lo que se ordenan todos los pares KV. Por lo tanto, cada registro local se parece a un árbol LSM de un solo nivel.
• Caso 2: S tiende a infinito. En este caso, DEPART siempre agrega la nueva ejecución de ordenación a un grupo de rango sin hacer ninguna ordenación por fusión con ninguna ejecución de ordenación existente.

Para establecer un valor apropiado de S, observamos que S determina el equilibrio entre el rendimiento de lectura y escritura. Small S mejora el rendimiento de lectura al mantener una pequeña cantidad de ejecuciones de clasificación en un grupo de rango. También mantiene la eficiencia del almacenamiento al descartar pares de KV no válidos en operaciones de ordenación por combinación. Sin embargo, incurre en una gran sobrecarga de clasificación por combinación, lo que reduce el rendimiento de escritura. Por lo tanto, para admitir configuraciones de sistema con altos niveles de consistencia de lectura bajo cargas de trabajo dominadas por la lectura, debemos establecer un orden alto con una S pequeña para favorecer las lecturas; de lo contrario, debemos disminuir el grado de orden aumentando el valor de S para beneficiar la escritura. También evaluamos el impacto de diferentes valores de S a través de experimentos y recomendamos una configuración predeterminada de S=20, que puede equilibrar de manera efectiva el rendimiento de lectura y escritura en diferentes configuraciones de consistencia (ver Exp#8 en §5.2).

4.5 Recuperación en paralelo

Para una recuperación rápida de cualquier nodo fallido, DEPART propone un esquema de recuperación en paralelo que aprovecha el desacoplamiento de la administración de almacenamiento para réplicas primarias y redundantes. Comenzamos revisando el proceso de recuperación en la implementación actual de Cassandra. Cassandra actualmente no tiene un nodo centralizado para monitorear la pérdida de datos y coordinar la recuperación de datos. En cambio, mantiene un árbol de Merkle [4, 47] en cada nodo para detectar inconsistencias de datos entre varias réplicas. Tenga en cuenta que otras tiendas KV distribuidas consistentes basadas en hash también usan árboles Merkle, como Dynamo [25] y Riak [54].

Un árbol Merkle es un árbol hash binario en el que cada nodo hoja almacena los hash de una serie de pares de KV, y cada nodo no hoja almacena los hash de sus hijos. Si se pierde un par KV, la réplica del par KV se vuelve inconsistente, según lo detecta el árbol de Merkle en el nodo donde se almacena la réplica, por lo que Cassandra activa el proceso de recuperación. Específicamente, el proceso de recuperación se divide en tres pasos: (i) construir un árbol Merkle para cada rango de par KV en cada nodo; (ii) comparar árboles Merkle para el mismo rango de par KV en diferentes nodos para identificar cualquier rango de par KV inconsistente ( lo que significa pérdida de datos); (iii) reconstruir cualquier rango inconsistente recuperando los rangos de pares KV de los nodos que no fallan y enviando los rangos de pares KV a los nodos recuperados.

DEPART pone en paralelo el proceso de lectura y escritura para recuperar múltiples rangos de pares KV para una recuperación rápida. Su proceso de recuperación paralelo se basa en el flujo de trabajo de recuperación en Cassandra, como se muestra en la Figura 9. Supongamos que restauramos los datos perdidos del nodo fallido en el nodo N0. Primero, cada nodo en DEPART recupera pares KV del árbol LSM y el registro de dos capas, y construye su propio árbol Merkle (tenga en cuenta que el árbol Merkle en N0 está inicialmente vacío) (paso 1). N0 compara los árboles de Merkle e identifica los pares de KV que faltan (paso 2). Para recuperar pares de KV perdidos, cada nodo superviviente (p. ej., el nodo N1 en la Figura 9) emite lecturas paralelas a las réplicas principal y redundante mediante dos subprocesos y, de manera similar, los nuevos nodos (es decir, N0) leen de otros nodos supervivientes. Recupere pares de KV y emitir escrituras paralelas utilizando dos subprocesos para réplicas primarias y redundantes. Este subprocesamiento múltiple es posible porque las copias principal y redundante se almacenan en diferentes estructuras de índice.

5 reseñas

DEPART se basa en el código base de Cassandra v3.11.4 [2] mediante el desacoplamiento de réplicas en el módulo de almacenamiento de cada nodo. Nuestro propio prototipo DEPART contiene 6.9K LoC, mientras que la modificación a Cassandra contiene 1.9K LoC. Tenga en cuenta que Cassandra v3.11.4 contiene aproximadamente 206.2K LoC. Para demostrar los beneficios del diseño de registro de dos niveles en DEPART, también implementamos un enfoque simple de desacoplamiento de réplicas que simplemente almacena réplicas en múltiples árboles LSM, a los que nos referimos como mLSM (Sección 3.2).

Realizamos experimentos de banco de pruebas para demostrar la eficiencia de DEPART. Comparamos nuestro prototipo DEPART con Cassandra (v3.11.4), que realiza un índice unificado en todas las réplicas, mLSM. Abordamos los siguientes temas.

----¿Cómo se compara el rendimiento general de DEPART con el de Cassandra y mLSM en diferentes configuraciones, como el rendimiento de micro-benchmark en diferentes tipos de operaciones KV, el rendimiento en diferentes configuraciones de consistencia y diferentes factores de replicación, y el rendimiento en cargas de trabajo centrales de YCSB? [21 , 22]? (Experimentos 1-4)
— ¿Cuáles son los problemas de rendimiento con DEPART y Cassandra? (Experimento 5)

-----¿Cómo se comporta DEPART en caso de falla de un nodo? (Experimentos 6-7)
-----¿Cómo varía el rendimiento de DEPART con la configuración de parámetros, incluido el grado de clasificación S, el tamaño de almacenamiento y la cantidad de nodos de almacenamiento? (Experimentos 8-10)

5.1 Configuración

Banco de pruebas. Realizamos todos los experimentos en un clúster local de varias máquinas, cada una con dos CPU Intel® Xeon® E5-2650 v4 de 12 núcleos a 2,20 GHz, 32 GiB de RAM y una SSD SATA Samsung 860 EVO de 500 GiB. Todas las máquinas se han interconectado a través de Conmutadores Ethernet de 10 Gb/s. Cada máquina ejecuta CentOS 7.6.1810 con Linux kernel 3.10.0 de 64 bits y sistema de archivos Ext4. Usamos una máquina para simular múltiples clientes a través de un grupo de subprocesos, y el resto de las máquinas sirven como nodos de almacenamiento.
carga de trabajo Generamos cargas de trabajo utilizando la herramienta general de evaluación comparativa del sistema en la nube YCSB [21, 22]. De manera predeterminada, nos enfocamos en pares de KV de 1 KiB con claves de 24 bytes y generamos solicitudes basadas en la distribución Zipf con la constante Zipfian predeterminada de 0.99. Implementamos YCSB en una máquina cliente y establecimos la cantidad de subprocesos del cliente en 50, y cada subproceso del cliente emitió una carga de trabajo desde YCSB.

Configuración predeterminada. Configuramos cinco nodos de almacenamiento en el clúster con tres replicaciones para implementar Cassandra y DEPART. Antes de cada experimento, el clúster tiene almacenamiento vacío. Por defecto establecemos (WCL=1, RCL=1) (es decir, el valor predeterminado en Cassandra), que corresponde a la coherencia final. También investigamos el efecto de diferentes niveles de consistencia (Experimentos 1 y 2). Tanto Cassandra como DEPART usan el módulo de delatado dinámico predeterminado [5] para seleccionar el nodo más rápido para servir lecturas con el fin de equilibrar la carga de lecturas entre diferentes réplicas. Para el parámetro num tokens [2] que determina el número de grupos de rango, usamos el valor predeterminado de 256 en Cassandra.

Para DEPART, configuramos el tamaño de MemTable para que sea el mismo que el de Cassandra (160 MiB de manera predeterminada) y configuramos el tamaño del segmento en el registro global para que sea el mismo que el tamaño de MemTable. Dado que DEPART mantiene una MemTable adicional para el registro de dos niveles, aumentamos el tamaño de caché de filas de Cassandra en 160 MiB para una comparación justa. Para un registro de dos niveles, establecemos el tamaño de los datos por operación dividida en 20 segmentos (alrededor de 3 GiB) y establecemos S en 20 para lograr un rendimiento equilibrado de lectura y escritura. Mantenemos otras configuraciones de parámetros en Cassandra sin cambios. Graficamos los resultados promedio de cinco ejecuciones, con barras de error que muestran la desviación estándar.

5.2 Resultados

Experimento 1 (rendimiento en operación KV). Primero comparamos el rendimiento de Cassandra, mLSM y DEPART en diferentes operaciones de KV, incluida la escritura (es decir, escribir un nuevo par de KV), lectura (es decir, leer un par de KV existente), escanear (es decir, leer un par de KV existente). pares de KV consecutivos) y actualizaciones (es decir, actualizar pares de KV existentes). Configuramos las máquinas del cliente para escribir primero aleatoriamente pares de 200M KV. Luego emite las siguientes solicitudes en orden: (i) 20 millones de lecturas, (ii) 2 millones de escaneos (cada escaneo consiste en una búsqueda () para ubicar la primera clave, luego itera con 100 next ()), y (iii) ) Actualización de 200M. También consideramos dos configuraciones de nivel de consistencia: (i) (WCL=3, RCL=1) (es decir, consistencia fuerte) y (ii) (WCL=1, RCL=1) (es decir, consistencia eventual).

La Figura 10 muestra los resultados de rendimiento y latencia. En primer lugar, DEPART mejora el rendimiento general de Cassandra en todos los casos. Para (WCL=3, RCL=1), DEPART aumenta el rendimiento de escritura, lectura, escaneo y actualización a 1,42×, 2,29×, 2,22× y 1,45× respectivamente; aumenta la latencia de escritura promedio, la latencia de lectura promedio, 99 % la latencia de escritura y la latencia de lectura del 99 % se redujeron en un 29 %, 58 %, 39 % y 41 %, respectivamente. Para (WCL=1, RCL=1), DEPART aumenta el rendimiento de escritura, lectura, escaneo y actualización a 1,43×, 2,43×, 2,68× y 1,44× respectivamente; La latencia, el 99 % de latencia de escritura y el 99 % de latencia de lectura fueron reducido en un 30%, 59%, 41% y 48%, respectivamente. Los resultados de latencia para el análisis y la actualización son similares y omitimos los resultados aquí. Hay dos razones principales para la mejora del rendimiento de DEPART. En primer lugar, para las lecturas, DEPART solo busca en el árbol LSM o en un grupo de rango específico en el registro L2 dentro de un nodo, lo que reduce en gran medida el espacio de búsqueda. En segundo lugar, para las escrituras, DEPART descarga la sobrecarga de compactación en el árbol LSM, que ahora solo conserva la copia principal. Un registro de dos niveles también tiene una sobrecarga de ordenación combinada limitada al tener un valor alto de grado de ordenación S.

En segundo lugar, mLSM mejora significativamente el rendimiento de lectura, pero solo mejora marginalmente el rendimiento de escritura. Específicamente, en comparación con Cassandra, aumenta el rendimiento de escritura, lectura, escaneo y actualización en 1,18-1,20x, 2,11-2,20x, 1,85-2,0x y 1,15-1,20x, respectivamente. También redujo la latencia de escritura promedio, la latencia de lectura promedio, la latencia de escritura del 99 % y la latencia de lectura del 99 % en un 15-17 %, 53-56 %, 16-18 % y 34-41 %, respectivamente. El motivo es que mLSM aún desencadena operaciones de compactación frecuentes, que compiten por el ancho de banda del disco y degradan el rendimiento de escritura. Por ejemplo, el tamaño total comprimido de Cassandra y mLSM es de 3,46 TiB y 2,72 TiB, respectivamente, y el tamaño total comprimido y de ordenación combinada de DEPART es de 1,65 TiB (es decir, en comparación con Cassandra, mLSM solo reduce el tamaño total comprimido en un 21 %). , pero DEPART lo reduce reducido en un 52%).

A continuación, comparamos los costos de almacenamiento y memoria de Cassandra, mLSM y DEPART. Después de la fase de actualización, el tamaño del almacenamiento de KV fue de 613,5 GiB para Cassandra, 611,3 GiB para mLSM y 654,8 GiB para DEPART. DEPART incurre en una sobrecarga de almacenamiento adicional del 6,7 % en comparación con Cassandra porque, en nuestra configuración predeterminada, a cada grupo de rango se le permiten hasta S = 20 ejecuciones de clasificación y contiene pares de KV no válidos antes de la clasificación combinada. Para medir la sobrecarga de memoria, notamos que el tamaño de la MemTable variaba con el tiempo (hasta el límite de 160 MiB) ya que los pares de KV se insertaban continuamente en la MemTable y se descargaban en el disco cuando la MemTable estaba llena. Por lo tanto, medimos el uso de memoria total de MemTables cada cinco segundos y obtenemos un resultado promedio. El uso total de memoria de mLSM es de 335,7 MiB, que es 3,7 veces mayor que el de Cassandra (90,4 MiB), porque cada árbol LSM mantiene una MemTable. Sin embargo, DEPART solo cuesta 183,9 MiB, 2,0 veces más que Cassandra, porque DEPART solo mantiene una MemTable adicional para el registro de dos niveles. Tenga en cuenta que el uso de memoria total de mLSM aumenta con el factor de replicación, mientras que el uso de memoria total de DEPART no se ve afectado.

Finalmente, comparamos la amplificación de lectura/escritura (es decir, la relación entre el volumen de lectura/escritura del sistema y el volumen de lectura/escritura del usuario) de Cassandra, mLSM y DEPART. La figura 11 muestra los resultados. En comparación con Cassandra, mLSM reduce la amplificación de lectura y escritura en un 40 % y un 24 %, respectivamente, mientras que DEPART reduce la amplificación de lectura y escritura en un 53 % y un 52 %, respectivamente. Tenga en cuenta que la ganancia de rendimiento de DEPART es similar en ambos niveles de consistencia, por lo que nos enfocamos en (WCL=1, RCL=1) en los siguientes experimentos (excepto Exp#2 y 8).

Experimento 2 (rendimiento bajo diferentes configuraciones de consistencia). Evaluamos el desempeño bajo diferentes configuraciones de consistencia. En particular, para una mayor consistencia, consideramos configuraciones adicionales de WCL y RCL bajo replicación triple que satisfacen la condición WCL+RCL>3, incluidas (WCL=2, RCL=2) y (WCL=1, RCL=3) .

La figura 12 muestra los resultados. DEPART mejora continuamente el rendimiento de escrituras, lecturas, escaneos y actualizaciones en Cassandra bajo diferentes configuraciones de consistencia. Específicamente, para (WCL=2, RCL=2), DEPART mejora el rendimiento de escritura, lectura, escaneo y actualización a 1,43×, 1,70×, 1,38× y 1,44×, respectivamente. Para (WCL=1, RCL=3), DE-PART aumenta el rendimiento de escritura, lectura, escaneo y actualización a 1,44×, 1,72×, 1,62×, 1,45×, respectivamente. DE-PART también mejora constantemente el rendimiento de escritura y actualización en comparación con mLSM. Tenga en cuenta que la ganancia de rendimiento de escritura de DEPART sobre Cassandra sigue siendo casi la misma en diferentes configuraciones de coherencia, ya que las estructuras de índice de Cassandra y DEPART permanecen sin cambios en la replicación triple.

Sin embargo, la ganancia de rendimiento de lectura de DEPART sobre Cassandra se vuelve más pequeña, y para RCL ≥ 2, el rendimiento de lectura de DEPART es peor que mLSM. En este caso, cada solicitud de lectura debe acceder con éxito al menos a dos réplicas, por lo que se deben buscar réplicas redundantes en el registro L2. Dado que las copias redundantes en el registro de dos niveles no se ordenan por completo, el rendimiento es más lento que leer la copia principal en el árbol LSM. Aún así, DEPART logra lecturas más rápidas que Cassandra porque busca menos datos que Cassandra. Además, mLSM mantiene las copias redundantes completamente ordenadas en cada nivel, por lo que logra un mayor rendimiento de lectura que DEPART. Por otro lado, con RCL=1, cada lectura solo necesita acceder a una réplica para operar con éxito. La mayoría de las lecturas se enrutan a sus réplicas principales con latencias de lectura menores que las de las réplicas redundantes según lo determina el módulo de delatado dinámico (Sección 2.2). Por lo tanto, la ganancia de rendimiento de lectura bajo RCL=1 es generalmente más alta que bajo RCL≥2.

Experimento 3 (rendimiento a diferentes factores de replicación). Evaluamos el rendimiento de DEPART cambiando el factor de replicación k de 3 a 5. Configuramos la máquina cliente para que primero escribiera aleatoriamente 200 millones de pares de KV y luego emitiera 20 millones de lecturas.

La Figura 13 muestra los resultados de rendimiento para escrituras y lecturas frente al factor de replicación. En comparación con Cassandra, DE-PART aumenta el rendimiento de escritura y lectura entre 1,43 y 1,59 veces y entre 2,43 y 3,61 veces, respectivamente. Además, DEPART logra mayores ganancias de rendimiento para factores de replicación más grandes. Hay dos razones principales. En primer lugar, para las lecturas, DEPART lee la copia principal del árbol LSM o la copia redundante del registro de dos niveles; para este último, solo busca en el registro global y el grupo de rango correspondiente en el registro de dos niveles. Por lo tanto, el rendimiento de lectura de DEPART se ve menos afectado por el número de réplicas. Sin embargo, Cassandra almacena todas las réplicas en un solo árbol LSM y su lectura requiere recorrer todo el árbol LSM. Su rendimiento de lectura se degrada significativamente a medida que aumenta el factor de replicación. En segundo lugar, para escrituras, DE-PART implementa el desacoplamiento de réplicas y administra réplicas redundantes en grupos de rango. Cuando aumenta el número de réplicas, el costo de compactación en el árbol LSM permanece constante, y el costo de clasificación por combinación en el registro de dos niveles aumenta solo levemente. Sin embargo, Cassandra almacena todas las réplicas en un solo árbol LSM y el costo de la compresión aumenta significativamente a medida que aumenta la cantidad de réplicas. Combinando estas dos razones, la ganancia de rendimiento de DEPART aumenta a medida que aumenta el factor de replicación.

Similar a DEPART, mLSM también mejora continuamente el rendimiento de escritura y lectura en Cassandra bajo diferentes factores de replicación. Cuando el factor de replicación aumenta a k = 4 y k = 5, su rendimiento de lectura es incluso mejor que DEPART. La razón principal es que mLSM solo busca el árbol LSM correspondiente que está completamente ordenado en cada nivel, independientemente del factor de replicación, pero DEPART mantiene copias redundantes en los registros de dos niveles que no están completamente ordenados de manera predeterminada. Tenga en cuenta que podemos ajustar el grado de clasificación de los registros de dos niveles para mejorar aún más el rendimiento de lectura. Además, el uso de memoria de DEPART sigue siendo 2 veces mayor que el de Cassandra, pero cuando el factor de replicación aumenta a k = 5, el uso de memoria de mLSM aumenta a 5 veces.

Experimento 4 (rendimiento YCSB) . Comparamos Cassandra, mLSM y DEPART utilizando seis cargas de trabajo principales de YCSB [21, 22], a saber, A (50 % de lectura, 50 % de escritura), B (95 % de lectura, 5 % de escritura), C (100 % de lectura), D (95 % de lectura, 5 % de escritura), E (95 % de escaneo, 5 % de escritura) y F (50 % de lectura, 50 % de lectura, modificación y escritura). Antes de ejecutar cada una de las seis cargas de trabajo principales de YCSB, la máquina cliente primero escribe aleatoriamente 200 millones de pares de KV en el clúster. Cada carga de trabajo consta de 100 millones de operaciones, excepto la carga de trabajo E, que contiene 10 millones de operaciones, lo que implica 100 next() por escaneo.
La figura 14 muestra los resultados. DEPART supera a Cassandra en todas las cargas de trabajo. Específicamente, mejora el rendimiento por un factor de 1,4 a 2,1 bajo la carga de trabajo dominante de lectura BD, por un factor de 1,6 a 2,2 bajo las cargas de trabajo dominantes de escritura A y F, y por un factor de La carga de trabajo principal E mejora por un factor de 2.4. Diseño de registro de capas, DEPART reduce la sobrecarga de compresión del árbol LSM durante la escritura y reduce el espacio de búsqueda durante la lectura, por lo que mejora el rendimiento de lectura y escritura. Por otro lado, mLSM también supera a Cassandra en todas las cargas de trabajo debido al desacoplamiento de réplicas. Sin embargo, DEPART mejora aún más el rendimiento de mLSM, lo que genera una gran sobrecarga de compresión.

Experimento 5 (descomposición temporal de lectura/escritura). Mostramos el desglose de tiempo de los procesos de lectura y escritura en Cassandra y DEPART. Configuramos la máquina cliente para cargar primero 200 millones de pares de KV y luego emitir 20 millones de lecturas. El proceso de lectura incluye la lectura de MemTable, cachés (incluidas la caché de filas y la caché de claves), los bloques de índice de SSTable (por ejemplo, filtros Bloom y compensaciones) y los bloques de datos en SSTable. Tenga en cuenta que cada segmento en el registro de dos niveles se trata aquí como una SSTable. El proceso de escritura incluye escribir en WAL, escribir en MemTable, vaciar MemTable, compactar el árbol LSM y una especie de combinación del registro de dos niveles (solo en DEPART).
La Figura 15 muestra el desglose de tiempo para lecturas y escrituras. Para la lectura, la mayor parte del tiempo de lectura se usa para leer los bloques de índice de SSTables en Cassandra y DEPART, porque la lectura del par KV necesita verificar el nivel del árbol LSM del filtro Bloom en cada bloque de índice para determinar si el par KV existe, si Si existe, el bloque de datos se lee de SSTable de acuerdo con el desplazamiento en el bloque de índice. En general, DEPART reduce el costo de tiempo de lectura de bloques de índice y bloques de datos de SSTables en un 56 % y un 45 %, respectivamente. Hay dos razones. En primer lugar, DEPART solo almacena la copia principal en el árbol LSM, por lo que la cantidad de SSTables en el árbol LSM se reduce considerablemente. Además, DEPART administra réplicas redundantes en grupos de rango, por lo que también se reduce la cantidad de lecturas utilizadas para ubicar pares de KV.
Para escrituras, DEPART reduce el costo de tiempo de escribir en WAL y escribir en MemTable en un 28 % y un 37 %, respectivamente, porque DEPART escribe en réplicas principales y redundantes en paralelo. DEPART también reduce en gran medida la sobrecarga de compresión al reducir el tamaño del árbol LSM; por ejemplo, su tiempo de compresión es solo el 30,7 % del de Cassandra. Además, el tiempo de clasificación de combinación para registros de dos niveles en DEPART es solo el 21,4 % del tiempo de compactación en Cassandra. Por lo tanto, el tiempo total de compactación y clasificación por fusión en DEPART es solo el 52,1 % del tiempo de compactación en Cassandra.

Experimento 6 (rendimiento de recuperación). Evaluamos el rendimiento de recuperación de la recuperación de nodos fallidos. Consideramos diferentes tamaños de escritura configurando máquinas cliente para escribir aleatoriamente pares de KV de 20M, 50M y 100M en el clúster. Luego bloqueamos un nodo eliminando el proceso de almacenamiento de KV con el comando "kill -s processID" y eliminando todos sus datos con el comando "rm -r data". Finalmente, reiniciamos el proceso de almacenamiento de KV en el mismo nodo e invocamos el comando "nodetool repair -full keyspacename" para restaurarlo.
La Figura 16(b) también muestra los resultados de la descomposición del tiempo de recuperación para reparar pares de 50M y 100MKV. Consideramos diferentes pasos: Construir MT (es decir, construir árboles de Merkle para todos los nodos), Comparar MT (es decir, comparar todos los árboles de Merkle), Recibir y escribir (es decir, recibir datos reparados de otros nodos y escribir datos en el disco) y Otros (es decir, otras operaciones en recuperación). En comparación con Cassandra, DEPART reduce el costo de tiempo de Build MT y Receive&Write casi a la mitad al paralelizar el proceso de lectura/escritura en réplicas primarias y redundantes.

Experimento 7 (rendimiento cuando el nodo falla). Evaluamos el rendimiento de lectura, escritura y actualización cuando un nodo falla y antes de que se repare. La máquina cliente primero escribe aleatoriamente 100 millones de pares de KV en el clúster, luego bloqueamos manualmente un nodo, como se muestra en el Experimento 6. Luego emitimos 20 millones de lecturas, 100 millones de escrituras y 100 millones de actualizaciones.

La figura 17(a) muestra el rendimiento en caso de falla del nodo. En comparación con Cassandra, DEPART aumenta el rendimiento de lectura, escritura y actualización en 1,69x, 1,59x y 1,55x, respectivamente. La razón principal es que DEPART siempre busca muchos menos datos que Cassandra, aunque lee copias redundantes de dos capas de registros. Además, DEPART mejora constantemente el rendimiento de escritura en los modos normal y de falla.

También evaluamos la degradación del rendimiento de lectura en diferentes escenarios: (i) la reparación del nodo aún no se ha activado, (ii) la reparación del nodo está en curso, (iii) el soporte de registro de dos niveles para réplicas redundantes en cada nodo es superior al umbral S (Sección 4.4) se redujo del valor predeterminado de 20 a 5 para mejorar la clasificación. La Figura 17(b) muestra el rendimiento de lectura reducido. Cuando la reparación del nodo no se activa o está en curso, DEPART mejora el rendimiento de las lecturas degradadas en 1,69x y 1,75x, respectivamente, porque DEPART siempre busca menos datos en comparación con el índice unificado de Cassandra. Además, cuando el grado de orden del registro de capa 2 es alto (por ejemplo, el umbral S es pequeño), la ganancia de rendimiento de lectura degradada de DEPART aumenta, porque la lectura de los pares KV en el registro de capa 2 es más eficiente y muy ordenada.

Experimento 8 (el efecto de clasificar el grado S). Evaluamos el rendimiento de lectura y escritura bajo diferentes configuraciones de grado de clasificación S en DEPART para mostrar cómo DEPART puede equilibrar las ganancias de rendimiento de lectura y escritura de copias redundantes ajustando el valor de S. La máquina cliente primero escribe aleatoriamente 200 millones de pares KV en el clúster y luego emite 20 millones de lecturas. Aquí usamos una configuración de consistencia (WCL=2, RCL=2) para que cada lectura exitosa deba acceder a la copia redundante.

La Tabla 1 muestra los resultados. Para DEPART, si S = 1, el registro de dos niveles se reduce a un árbol LSM de dos niveles, logrando así el rendimiento de lectura más alto cuando los pares KV están completamente ordenados, pero el rendimiento de escritura más bajo debido a la fusión frecuente, para locales Se mantiene una sola ejecución de clasificación en cada grupo de rango en el registro. A medida que aumentamos S (por ejemplo, S es 10 o 20), la clasificación del registro de dos niveles se relaja, por lo que la sobrecarga de la clasificación combinada se vuelve más pequeña y, por lo tanto, aumenta el rendimiento de escritura. Dado que establecemos S en un valor lo suficientemente grande, el registro de dos niveles se reduce a agregar solo, por lo que el rendimiento de escritura es el más alto, pero el rendimiento de lectura es el más bajo. Tenga en cuenta que cuando S es 1, 10 o 20, DEPART aún mantiene un rendimiento más alto que Cassandra en términos de escrituras y lecturas, aunque existe una compensación de rendimiento entre escrituras y lecturas en DEPART.

Experimento 9 (Efecto de diferentes tamaños de tiendas KV). Ahora evaluamos el impacto de diferentes tamaños de tiendas KV. Aumentamos el tamaño de los datos escritos por los clientes de 200 millones a 400 millones de pares de KV (es decir, la cantidad total de réplicas primarias y redundantes aumentó de 600 GiB a 1200 GiB con la triple replicación). La Figura 18 muestra el rendimiento de escritura y lectura para diferentes tamaños de tiendas KV. En comparación con Cassandra, el rendimiento de escritura y lectura de DEPART aumenta entre 1,43 y 1,52 veces y entre 2,43 y 2,95 veces, respectivamente. Además, la ganancia de rendimiento de DEPART aumenta con el aumento del tamaño de la tienda KV, porque DEPART alivia la amplificación de escritura y lectura a través del desacoplamiento de réplicas, pero Cassandra exacerba la amplificación de escritura y lectura a través del índice unificado.

Para demostrar mejor la escalabilidad del diseño de registro de dos niveles en diferentes tamaños de tiendas KV, también evaluamos el tiempo de compactación del árbol LSM y el tiempo de clasificación de fusión del registro de dos niveles en DEPART, y los comparamos con Cassander Pull el tiempo de transacción. Cuando el tamaño de la tienda KV aumentó de 200 millones a 400 millones de pares KV, el tiempo de compactación en Cassandra aumentó 2,3 veces, mientras que el tiempo total de las operaciones de compactación y clasificación combinada en DEPART solo aumentó 1,9 veces. Específicamente, la relación entre el tiempo de clasificación combinada en DEPART y el tiempo de compactación en Cassandra disminuyó del 21,4 % al 18,7 %, y la relación del tiempo de compactación en DEPART con el tiempo de compactación en Cassandra disminuyó del 30,7 % al 25,2 %. Por lo tanto, DEPART escala bien a medida que crece la tienda KV.

Experimento 10 (Efecto de diferente número de nodos). Evaluamos el rendimiento de DEPART cuando el clúster contiene más nodos. Cambiamos el número de nodos a 5, 8 y 10. Configuramos las computadoras cliente para emitir escrituras de pares de 200M, 320M y 400MKV, respectivamente, para que cada nodo contuviera la misma cantidad de datos. Después de escribir, configuramos las máquinas cliente para emitir 20 millones, 32 millones y 40 millones de lecturas respectivamente.
La Figura 19 muestra los resultados de rendimiento de las operaciones de escritura y lectura. En comparación con Cassandra, DEPART aumenta el rendimiento de escritura y lectura entre 1,35 y 1,43 veces y entre 2,26 y 2,43 veces, respectivamente. Independientemente del tamaño del clúster, DEPART mantiene sus ganancias de rendimiento sobre Cassandra a través del desacoplamiento de réplicas. Por lo tanto, DEPART logra una buena escalabilidad a medida que aumenta el tamaño del clúster.

6 Trabajo relacionado

Almacenamiento KV de árbol LSM local. Muchos estudios optimizan el rendimiento de lectura y escritura del almacenamiento KV de árbol LSM local que se ejecuta en una sola máquina. El rendimiento de lectura se puede mejorar mediante la optimización del filtro Bloom [23, 38], el almacenamiento en caché adaptativo [65] y la optimización de exploración con intentos concisos [68], mientras que el rendimiento de escritura se puede mejorar mediante la optimización de la compresión [24, 32, 55, 56], árbol LSM fragmentado [51], separación KV [12, 36, 43], optimización de la programación de E/S [8], optimización de la estructura de la memoria [9] y componente de registro de disco híbrido de la tecnología de optimización de la memoria [7]. Nuestro trabajo se centra en la gestión de réplicas en un almacén KV distribuido y es compatible con las técnicas de optimización antes mencionadas para almacenes KV de árboles LSM locales en un solo nodo.

Almacenamiento KV distribuido. Los almacenes KV distribuidos se pueden dividir en cachés KV en memoria [42, 53] y almacenes persistentes [1-3, 41, 50]. Los esfuerzos de optimización para los almacenes KV en memoria incluyen un diseño sin bloqueo y compatible con caché para una alta simultaneidad y rendimiento [13,30,40], diseño de codificación de borrado para eficiencia de memoria [66,67], ubicación de datos autoajustables [49] , fragmentación según el tamaño con latencia de cola reducida [26], equilibrio de carga adaptativo [16], indexación secundaria [34], codificación Reed-Solomon ampliada [35] y optimización de puntos de acceso [15]. Para el almacenamiento KV persistente distribuido, estudios previos propusieron la construcción de índices fuera de línea para la carga por lotes [57], la selección de réplicas adaptativas [52], la programación de búsquedas múltiples [58], el ajuste automático para la optimización de la latencia final [39], el equilibrio de carga [11], optimización del rendimiento a través de análisis de costo-beneficio y predicción de carga de trabajo [45], y optimización de la ubicación de datos y migración controlada [63, 64]. El almacenamiento persistente de KV utiliza principalmente el árbol LSM de la capa de almacenamiento para almacenar todos los pares de KV. Por el contrario, DEPART propone el desacoplamiento de réplicas en el almacenamiento KV de árbol LSM distribuido para una gestión eficiente de las réplicas.

gestión de copias. La investigación anterior mejoró la replicación de las tiendas KV distribuidas a través de la colocación eficiente de réplicas. Las primeras investigaciones incluyen la replicación encadenada [61, 62] y sus extensiones [44], la replicación de área amplia de bajo costo [17] y la replicación jerárquica dinámica para cuadrículas de datos [46]. Copyset [19] y la replicación jerárquica [18] se enfocan en mantener una alta confiabilidad de almacenamiento. Replex [59] admite consultas eficientes sobre varias claves. Nuestro trabajo se enfoca en la administración de réplicas dentro de cada nodo de almacenamiento mientras es compatible con las estrategias de ubicación de réplicas de capa superior.

7. Conclusión

Proponemos DEPART, que se basa en un esquema novedoso de gestión de réplicas, desacoplamiento de réplicas, para almacenamiento KV distribuido. DEPART utiliza un diseño de registro novedoso de dos niveles con orden ajustable para administrar de manera eficiente las copias redundantes para cumplir con los diferentes requisitos de rendimiento de lectura y escritura. Nuestro prototipo DEPART supera significativamente a Cassandra en diferentes tipos de operaciones KV y mantiene su ganancia de rendimiento bajo diferentes niveles de consistencia y configuraciones de parámetros. gracias

El código es el siguiente (ejemplo):

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import warnings
warnings.filterwarnings('ignore')
import  ssl
ssl._create_default_https_context = ssl._create_unverified_context

2. Leer datos