Historia de dos métodos de eyección: Sólo valor frente a completo

Introducción

Me gustaría agradecer a nuestro equipo de ingenieros de Couchbase Server - especialmente, Dave Rigby y Jim Walker - por su tremenda ayuda con este artículo y su infinita paciencia con todas mis preguntas. Muchas gracias chicos, ¡realmente aprecio vuestro vasto conocimiento y vuestra disposición a compartirlo!

En Couchbase Server, los datos se almacenan en buckets. Por defecto tipo de cubo - llamado de forma poco creativa Couchbase tipo - asegura la persistencia asíncrona de los datos en disco. El servidor intentará tener todos sus datos, el conjunto activo y el conjunto o conjuntos de réplica, en memoria. Sin embargo, si los datos en memoria alcanzan 85% de la cuota de memoria del bucket (este nivel se denomina marca de pleamar), el servidor empezará a expulsar (desalojar) de la memoria algunos de los documentos no utilizados recientemente. Los documentos activos tienen 40% posibilidades de ser desalojados, y los documentos réplica tienen 60% posibilidades de ser desalojados. La razón es la siguiente: es más importante que los documentos activos residan en memoria; sin embargo, también queremos algunas réplicas de documentos en memoria, en caso de que un nodo falle y las réplicas necesiten activarse. El proceso de desalojo continúa hasta que los datos en memoria se sitúan por debajo de 75% de la cuota de memoria del bucket (este nivel se denomina marca de bajamar).

Sólo un breve recordatorio sobre la estructura de los documentos almacenados en Couchbase:

• Documento clave o IDlongitud variable - hasta 250 bytes, debe ser única para los documentos almacenados en el mismo bucket
• Documento metadatoslongitud fija - 56 bytes para documentos almacenados en el tipo de bucket Couchbase, 72 bytes para documentos almacenados en el tipo de bucket Efímero (este tipo de bucket queda fuera del ámbito de este artículo)
• Documento valorLongitud variable: hasta 20 MB, normalmente JSON, aunque también pueden utilizarse otros formatos.

Dos métodos de expulsión

Por defecto, un bucket Couchbase utiliza Sólo valores método de expulsión (o desalojo). Hace muchas versiones, ésta era la única opción disponible. Como su nombre indica, el proceso de expulsión eliminará sólo el valor de los documentos y mantendrá las claves y metadatos del documento en memoria en todo momento.

A partir de la versión 3.0 (Servidor Couchbase se encuentra en la versión 6.5.1 en el momento de redactar este documento), hemos añadido la función Completo método de expulsión. Es fácil adivinar que un cubo configurado para la expulsión total eliminará las claves, metadatos y valores de los documentos como parte del proceso de expulsión.

Compromiso: rendimiento frente a tamaño de memoria

Entonces, ¿qué opción deberías elegir para tus buckets? Esto es lo que explica el tooltip en la GUI de nuestra última versión de Couchbase Server:

• Expulsión de valor: Durante la expulsión, sólo se expulsará el valor (la clave y los metadatos permanecerán en memoria).
• Expulsión total: Durante la expulsión, se expulsará todo (incluida la clave, los metadatos y el valor).
  Value Ejection necesita más memoria del sistema, pero proporciona el mejor rendimiento. La expulsión completa reduce la sobrecarga de memoria necesaria.

Para ser más precisos, ni método "necesita más memoria del sistema“: Completo expulsión permite que el conjunto de datos supere la memoria de forma significativa, mientras que Valor La eyección permite que el conjunto de datos sea mayor que la memoria hasta cierto punto, ya que debe mantener las claves y los metadatos en memoria.

Si latencia de lectura constante de las aplicaciones que trabajan con los datos en Couchbase Server es (muy) importante, deberías ceñirte a la expulsión de valores. Esto también requiere que dimensione su cluster correctamente, asigne cuotas de memoria suficientes a sus cubos, aplique conservación de documentos políticas (archivar o eliminar periódicamente los documentos antiguos), y supervisar el uso de la memoria.

Si se queda en presupuesto o límites de la tecnología existente es (muy) importante, entonces deberías considerar el desalojo completo para tus buckets grandes. Este puede ser el caso cuando estás al máximo de tus recursos de hardware locales, y no hay manera de exprimir más RAM en tus nodos Couchbase. Cuando el dinero es escaso para el gasto en tecnología local o en la nube, el rendimiento puede salvar el día.

Otra razón para considerar la eyección completa es cuando espera que su conjunto de datos sea grandepara que superar configuraciones de memoria razonables. ¿Qué tamaño tiene grande? Digamos miles de millones (¡sí, en plural!) de documentos, decenas (¡también en plural!) de terabytes de datos. Nuestros ingenieros y arquitectos de soluciones están siempre a su disposición para ayudarle. dimensionar su cluster Couchbase correctamente - por favor, hable con nosotros.

Aunque es posible cambiar de un método de expulsión a otro, es una de las pocas operaciones que requieren reiniciar el cubo y, por tanto, cierto tiempo de inactividad. Mostramos la siguiente advertencia en letra roja en la interfaz de usuario cuando se intenta cambiar el método de expulsión: Cambiar la política de desalojo reiniciará el cubo. Esto provocará el cierre de todas las conexiones abiertas y un cierto tiempo de inactividad. Por lo tanto, es aconsejable decidir el método de expulsión de sus cubos antes de ponerlos en producción.

¿A qué se debe la diferencia de rendimiento?

Veamos los diferentes escenarios para los métodos de expulsión de cubos y la residencia de datos. Esto nos ayudará a entender cómo se ve afectado el rendimiento.

1. Residencia de datos completa

Cuando los datos son totalmente residentes (es decir, caben en ~85% de la cuota de memoria del bucket), el rendimiento de los buckets de sólo valor y de eyección completa debería ser similar. Las operaciones con documentos funcionan como se muestra a continuación:

• Obtener (leer) un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, devuelva el documento de memoria.
    • RÁPIDO: Si no, devuelve el error "el documento no existe".
• Insertar un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, devuelve el error "el documento ya existe".
    • RÁPIDO: Si no, escribe el documento en memoria. A continuación, persistirlo y replicarlo de forma asíncrona.
• Sustituir un documento con clave = = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, guarda los cambios en memoria. A continuación, persístelos y replícalos de forma asíncrona.
    • RÁPIDO: Si no, devuelve el error "el documento no existe".

2. Residencia parcial de datos, expulsión sólo de valores

Cuando la residencia de datos es inferior a 100% para un cubo con sólo valores eyección, Couchbase Server sabe que las claves del documento y los metadatos siguen en memoria. Por lo tanto, las operaciones documentales tendrán el siguiente aspecto:

• Obtener (leer) un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, compruebe si el valor del documento está en memoria
      • RÁPIDO: En caso afirmativo, devuelva el documento de memoria.
      • LENTO: Si no, lee el documento del disco a la memoria y lo devuelve.
    • RÁPIDO: Si no, devuelve el error "el documento no existe".
• Insertar un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, devuelve el error "el documento ya existe".
    • RÁPIDO: Si no, escribe el documento en memoria. A continuación, persistirlo y replicarlo de forma asíncrona.
• Sustituir un documento con clave = = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, guarda los cambios en memoria. A continuación, persístelos y replícalos de forma asíncrona.
    • RÁPIDO: Si no, devuelve el error "el documento no existe".

3. Residencia parcial de datos, expulsión completa

Cuando la residencia de datos es inferior a 100% para un cubo con completo expulsión, Couchbase Server no puede confiar en la presencia de claves de documento y metadatos en memoria, porque podrían haber sido desalojados. Por lo tanto, las operaciones con documentos tendrán el siguiente aspecto:

• Obtener (leer) un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, compruebe si el valor del documento está en memoria
      • RÁPIDO: En caso afirmativo, devuelva el documento de memoria.
      • LENTO: Si no es así, compruebe el disco
        • LENTO: Si el documento se encuentra en el disco, lee el documento del disco a la memoria y lo devuelve.
        • LENTO: Si no, devuelve el error "el documento no existe".
• Insertar un documento con clave = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, devuelve el error "el documento ya existe".
    • LENTO: Si no es así, compruebe el disco
      • LENTO: Si no, escribe el documento en memoria. A continuación, persistirlo y replicarlo de forma asíncrona.
      • LENTO: En caso afirmativo, devuelve el error "el documento ya existe".
• Sustituir un documento con clave = = perfil::john-doe::123
  • RÁPIDO: comprueba en memoria si esta clave existe.
    • RÁPIDO: En caso afirmativo, guarda los cambios en memoria. A continuación, persístelos y replícalos de forma asíncrona.
    • LENTO: Si no es así, compruebe el disco
      • LENTO: Si no, devuelve el error "el documento no existe".
      • LENTO: En caso afirmativo, escribe el documento en memoria. A continuación, persistirlo y replicarlo de forma asíncrona.

Con cubos de desalojo completo que no son 100% residentes en memoria, muchos Existe operaciones tienen que ir al disco. También es probable que el número de "background fetches" (lectura de documentos del disco a la memoria, también conocidos como "caché misses") sea mayor para los cubos de expulsión completa.

¿Hay formas de mejorar el rendimiento?

Además de Inserte y Sustituir los SDK de Couchbase admiten Upserts. En upsert insertará un documento si no existe o reemplazará el documento existente. Debido a la naturaleza append-only del manejo de mutaciones de datos en Couchbase Server, el upsert operaciones no requieren correspondiente existe operación.  Por lo tanto, el uso de upserts en lugar de inserciones y sustituye a mejorará el rendimiento de su aplicación, siempre que su caso de uso lo permita.

Los discos rápidos dedicados también mejorarán el rendimiento de los buckets de expulsión completa. Es una de las configuraciones recomendadas para nodos Couchbase: discos dedicados por nodo sobre almacenamiento virtualizado.

Cuándo pasar de la expulsión por valor a la expulsión total

Consideremos la siguiente situación:

• Tiene un cubo configurado con expulsión sólo por valor
• El cubo ha crecido hasta el punto de que menos de 15-20% de los datos residen en memoria, que es nuestro ratio mínimo de residencia recomendado.
• Anticipa la llegada de más datos, ya archiva/elimina los documentos de acuerdo con los requisitos del caso de uso y no hay forma de proporcionar más RAM al bucket.

¿Debería cambiar al método de eyección total?

Existe una buena métrica que puede ayudarle a responder a esta pregunta: la cantidad de metadatos en RAM, comparada con los datos de usuario en RAM para el mismo bucket. Por "metadatos", entendemos documento claves + metadatosen este caso concreto. "Datos del usuario" en este caso significa documento valor.

Puede encontrar estas métricas en Recursos de vBucket en la interfaz de usuario. En la siguiente captura de pantalla, vemos que los metadatos ocupan aproximadamente 42% de los datos del bucket en memoria:

Estadísticas de sobrecarga de metadatos

En cierto punto, puede que empieces a ver mensajes como los siguientes en la interfaz de usuario y en tus registros de Couchbase:

Aviso de sobrecarga de metadatos

Con gran parte de la cuota de memoria ocupada por claves de documento y metadatos, hay poco o ningún espacio para mantener los valores del documento. En este caso, verás que el servidor hace muchas búsquedas en segundo plano para cargar datos del disco a la memoria, sólo para ser expulsado en un futuro próximo, ya que la memoria disponible es demasiado pequeña.

Si no puede añadir más nodos al clúster y/o reasignar memoria de otros cubos, entonces es aconsejable cambiar al método de expulsión completa para el cubo en cuestión. Ten en cuenta que habrá un tiempo de inactividad mientras tu cubo se reinicia y se somete al proceso de calentamiento.

Resumen

• Sólo valores ejection/eviction elimina de la memoria sólo los valores de los documentos, mientras que completo El desalojo también elimina las claves de los documentos y los metadatos.
• Deberías hacer un elección informada del método de expulsión antes de poner un cubo en producción. Los casos de uso de escritura intensiva con muchos millones de documentos son buenos candidatos para la expulsión total. Cambiar el método de expulsión más adelante en la producción puede resultar costoso debido a cierto tiempo de inactividad.
• Upsert y los discos rápidos dedicados siempre mejoran el rendimiento de la aplicación, y más aún en el caso de los cubos de expulsión completa.
• Controlar el cubo sobrecarga de metadatos. Es un buen indicador de que tu cluster puede necesitar más RAM. Si no puedes conseguir más memoria para tu cluster Couchbase, y tu la sobrecarga de metadatos es igual o superior a 40%puede considerar cambiar sus grandes cubos de escritura pesada a expulsión total.