Con Couchbase diseño de almacenamiento en apéndicees imposible corromper los archivos de datos e índices, ya que las actualizaciones sólo llegan hasta el final del archivo. No hay actualizaciones de archivos en el mismo lugar y los archivos nunca están en un estado inconsistente. Pero escribir en un archivo en constante expansión acabará por consumir todo el espacio de disco. Por lo tanto, el servidor Couchbase tiene un proceso llamado compactación. La compactación limpia el espacio de disco eliminando datos obsoletos y valores de índice para que los archivos de datos e índice no consuman innecesariamente espacio de disco. Si el caso de uso de tu aplicación es principalmente de lectura, esto puede estar bien, pero si tienes cargas de trabajo de escritura pesada, es posible que desees aprender acerca de cómo funciona la auto-compactación en Couchbase Server.
Por diseño, los documentos en Couchbase Server están particionados en vBuckets (o particiones). Hay múltiples archivos utilizados para el almacenamiento - un archivo de datos por partición (los "archivos de datos"), múltiples archivos de índice (activo, réplica y temp) por documento de diseño y un archivo maestro que tiene metadatos relacionados con los documentos de diseño y definiciones de vista. Por ejemplo, en Mac OSX (como se muestra a continuación), el bucket de muestra 'gamesim' tiene
64 archivos de datos individualesuno por partición (0.couch.1 a 63.couch.1) y un archivo maestro que contiene los documentos de diseño y otros metadatos de la vista (master.couch.1).
Datos y archivo maestro de Couchbase
Los archivos de índice se encuentran en la carpeta @indexes y consisten en el archivo de índice activo que empieza por main_, el archivo de índice de réplica (si la replicación de índices está activada) que empieza por replica_ y un archivo temporal que se utiliza mientras se construye y actualiza el índice que empieza por tmp_.
Archivos de índice en Couchbase Server
Los archivos de datos e índices en Couchbase Server se organizan como árboles b. Los nodos raíz (en rojo) contienen punteros a los nodos intermedios, que a su vez contienen punteros a los nodos hoja (en azul). En el caso de los ficheros de datos, los nodos raíz e intermedios registran el tamaño de los documentos de su subárbol. Los nodos hoja almacenan el identificador del documento, los metadatos del documento y los punteros al contenido del documento. En el caso de los archivos de índices, los nodos raíz e intermedios registran el resultado de la función de mapa y los valores de reducción en su subárbol.
Almacenamiento en árbol B para archivos de datos (a la izquierda) y archivos de índices (a la derecha)
Todas las mutaciones, incluidas las inserciones, actualizaciones y eliminaciones, se escriben al final del archivo, dejando los datos antiguos en su lugar. ¿Añadir un nuevo documento? El árbol b crece al final. ¿Borrar un documento? Eso se registra al final del árbol b. Por ejemplo, como se muestra en la figura siguiente, el documento A sufre una mutación seguida de una mutación en el documento B y, a continuación, se añade un nuevo documento D seguido de otra mutación en el documento A. Los datos antiguos se muestran con los nodos tachados en rojo en la figura siguiente.
Disposición lógica de datos para ficheros de datos e índices
Examinando el tamaño de los documentos rastreados por el nodo raíz en la estructura de archivos b-tree, se calcula la relación entre el tamaño real y el tamaño actual del archivo. Si esta relación alcanza un determinado umbral configurable, como se muestra en la figura siguiente, se activa un proceso de compactación en línea. La compactación explora los ficheros de datos e índices actuales y crea nuevos ficheros de datos e índices, sin los elementos marcados para su limpieza. Durante la compactación, los árboles b se equilibran y los valores de reducción se vuelven a calcular para el nuevo árbol. Además, también se limpian los datos que no pertenecen a un nodo concreto.
Finalmente, para ponerse al día con la carga de trabajo activa que podría haber cambiado el antiguo archivo de datos de partición durante la compactación, Couchbase copia los datos que se añadieron desde el inicio del proceso de compactación al nuevo archivo de datos de partición para que esté actualizado. El nuevo archivo de índice también se actualiza de esta manera. Los datos de la partición y el fichero de índice antiguos se borran y se utilizan los datos y ficheros de índice nuevos.
Normalmente, la compactación es una operación de todo o nada, pero como la compactación en Couchbase es por partición (vbucket)el conjunto de datos puede ser compactado incrementalmente sin perder los cambios que haya realizado al ser abortado.
Configuración de los umbrales de compactación en la pestaña UI de ajustes para archivos de datos e índices
La compactación en Couchbase Server es una funcionamiento en línea. Por defecto, la auto-compactación se activa cuando el umbral de fragmentación alcanza 30%, pero deberías probar qué configuración funciona bien para tu carga de trabajo y ajustar esta configuración en consecuencia.
Porque La compactación consume muchos recursos también puede programarla durante las horas de menor actividad. Para evitar que la compactación automática tenga lugar cuando su base de datos está en uso intensivo, puede configurar un período de tiempo fuera de pico durante el cual se permite la compactación utilizando la interfaz de usuario que se muestra arriba. Por ejemplo, aquí he configurado la compactación para que se ejecute todos los días entre las 12 de la mañana y la 1 de la madrugada, hora del servidor. Si la operación de compactación no se completa en este periodo de tiempo, continuará, pero puedes marcar la casilla para abortarla.
La compactación también puede activarse manualmente por cubo o por documento de diseño, como se muestra en las figuras siguientes.
Compactar manualmente un bucket de datos en Couchbase
Compactación manual de un documento de diseño en Couchbase
El rendimiento de compactación en Couchbase Server depende de la capacidad de IO y
dimensionamiento adecuado del cluster. Su clúster debe tener el tamaño adecuado para que haya suficiente capacidad en todas las distintas áreas para soportar todo lo demás que el sistema está haciendo para mantener el nivel requerido de rendimiento.
Entonces, ¿cómo se ajusta la compactación en Couchbase Server?No hay una solución mágica aquí... Dependiendo de los requisitos de IOPS de su aplicación, necesitará dimensionar su clúster adecuadamente y puede que desee probar su carga de trabajo a través de una variedad de hardware de almacenamiento diferente. Si su aplicación requiere mucha escritura, los SSD podrían ser la mejor opción, pero para ratios de lectura elevados, EBS podría ser una buena solución a bajo coste.
Por defecto, si tanto los índices de datos como los de vistas están configurados para la compactación automática, la compactación opera secuencialmente, primero en la base de datos y luego en las vistas. Si se activa la compactación paralela, tanto las bases de datos como las vistas pueden compactarse al mismo tiempo. Esto requiere más CPU y E/S de disco, pero si los índices de la base de datos y de las vistas se almacenan en diferentes dispositivos de disco físico (
como es nuestra mejor práctica de todos modos), los dos pueden completarse en paralelo para que el índice y los archivos de datos no crezcan extremadamente.
Conclusión
Al fin y al cabo, toda base de datos necesita un mantenimiento regular. La compactación en línea es una gran ventaja, pero hay que probar el sistema y configurar los parámetros de compactación adecuadamente para que no afecte a la carga del sistema.
Buen artículo. ¿Puede explicar un poco cómo funciona la compactación, y lo que es "Disk Cleanup", o si es lo mismo? Estamos ejecutando una instalación de "escritura intensiva". Digamos que tenemos 16 horas "off peak" por día donde queremos ejecutar el trabajo de compactación, y luego detener el proceso de compactación. ¿La compactación se realiza en un vBucket a la vez, y los vBuckets completados durante las 16 horas de compactación serán compactados, y durante el siguiente mantenimiento, continuará con los vBuckets que no fueron compactados? ¿Sería posible empezar la compactación con los vBuckets más fragmentados primero?
Hola David,
Gracias por leer este artículo y sí, grandes preguntas.
Q1 : ¿La compactación se realiza de un vBucket a la vez?
Sí. Al hacer la compactación, procesamos los vBuckets uno a uno.
P2: Los vBuckets completados durante las 16 horas de compactación serán compactados, y durante el siguiente mantenimiento, ¿continuará con los vBuckets que no fueron compactados?
Sí, después de reiniciar la compactación, la retomará desde el último punto de control donde se detuvo y continuará el proceso de compactación.
P3: ¿Sería posible iniciar la compactación con los vBuckets más fragmentados en primer lugar?
vbuckets y distribuidos aleatoriamente por el cluster couchbase y, en el caso más general, tienden a acumular fragmentación aproximadamente al mismo ritmo. En el peor de los casos, cuando uno o más vBuckets estén más fragmentados, una única pasada de compactación igualará el nivel de fragmentación.
Espero que le sirva de ayuda.
-Don
¿Podría por favor dar más detalles sobre "los índices de la base de datos y de las vistas se almacenan en diferentes dispositivos de disco físico"? ¿Cómo se puede configurar esto? He intentado crear un enlace simbólico para que los índices persistan en otro dispositivo, pero al final la fragmentación de las vistas aumentaba continuamente. Incluso cuando detuve el tráfico entrante, la pila de fragmentación de vistas en 80% (el umbral de framentación es 30%).
Gracias,
Kostas
[...] compactación de los archivos de disco para tener lugar y esto requerirá una cierta cantidad de IO de disco añadido. Este blog puede ayudarle a entender la compactación [...]
[...] La compactación es un proceso importante que se ejecuta todo el tiempo para recuperar espacio dada la arquitectura append-only de Couchbase. También se puede programar. Aprende más sobre compactación aquí. [...]