Con el lanzamiento de Couchbase Server 5.5hemos introducido compresión de extremo a extremo que permite que los datos sigan comprimidos: cliente a caché, a almacenamiento en disco, a replicación de datos entre centros de datos. Dado que la mayoría de los datos de nuestros clientes están en texto JSON, que es fácilmente comprimible, creemos que esto supondría un ahorro incalculable de almacenamiento y ancho de banda.
Permítanme proporcionarles una rápida visión general del flujo de datos dentro de Couchbase para sentar las bases para profundizar en la compresión de datos.
Fig. 1. Flujo de datos en la plataforma de datos Couchbase
Los datos de la aplicación cliente fluyen primero a la caché gestionada a través de SDKs, ya que Couchbase soporta y aboga por una arquitectura de memoria primero. Estos datos en la caché se persisten en el disco a través de la cola de persistencia. Todas las operaciones clave-valor se realizan sobre los datos en la caché a menos que haya un fallo de caché, donde los datos se recuperan del disco y se mantienen en la caché para futuros accesos. Estos datos de la caché también se replican en otros nodos réplica a través de la cola de replicación intraclúster para una alta disponibilidad. Esto es seguido por la replicación intercluster (si procede), donde los datos de la memoria se replican a otros clusters Couchbase que se distribuyen principalmente a través de centros de datos en diversas geografías utilizando la propia tecnología de Couchbase Cross Datacenter Replication (XDCR).
Todas las formas de replicación en Couchbase ya sea persistencia local, replicación intra cluster o replicación inter cluster se basan en un único protocolo llamado Database Change Protocol (DCP) que se caracteriza por la recuperación sin pérdida en caso de interrupción, streaming RAM a RAM y procesamiento paralelo multihilo.
La figura siguiente indica las distintas etapas de este flujo de datos desde la aplicación cliente hasta el almacenamiento, donde los datos se comprimen dentro de la plataforma de datos couchbase.
Fig. 2. Compresión de datos en la plataforma de datos Couchbase
- En SDK puede elegir recibir los datos en el modo comprimido o descomprimido dependiendo de la elección del usuario de la aplicación. El SDK indica este estado mediante banderas a la caché Managed.
- En Caché gestionada que también es un almacén de valores clave, soporta ahora la compresión, pudiendo recibir datos comprimidos y descomprimidos.Funciona en tres modos :
Off: Sin compresión
Pasivo : (Predeterminado) Si la caché recibe documentos comprimidos, se almacena de forma comprimida, pero no se hace ningún esfuerzo por comprimir los documentos sin comprimir.
Activa: Incluso los documentos sin comprimir se comprimen y almacenan.
- En el Discolos datos siempre se almacenan comprimidos.
- En Replicación entre centros de datos (XDCR) soporta la compresión. Pero el usuario tiene que elegir si desea activar la compresión durante la replicación de sus datos entre centros de datos.
- Cbbackupmgr es la tecnología nativa de backup y restauración de Couchbase. Desde, 5.0 cbbackupmgr soporta compresión donde los datos pueden ser almacenados comprimidos cuando son respaldados.
Todas las réplicas se gestionan mediante el protocolo de cambio de base de datos y admite la compresión de documentos. Pero los clientes del DCP, como XDCR, backup & restore, etc., reciben datos comprimidos o sin comprimir del DCP en función de las entradas proporcionadas por el cliente específico.
Creemos que la compresión es un valor añadido significativo para los clientes de la plataforma de datos Couchbase, ya que minimiza los costes de almacenamiento, red y memoria, incluso para los despliegues existentes. Para las empresas que despliegan Couchbase en nubes públicas como AWS, Azure o GCP, la conservación del ancho de banda durante la replicación de grandes cantidades de datos (TB) entre centros de datos supondría un ahorro directo de costes, ya que los proveedores de la nube cobran en función de la utilización del ancho de banda.
Tenga en cuenta lo siguiente: No existe una regla general que dicte si los datos se comprimen o descomprimen siempre en el flujo, ya que la eficiencia final está sujeta a varios factores como el tipo de datos, el ancho de banda disponible, el impacto en el rendimiento, la utilización de la CPU, etc. El sistema está diseñado para optar por la ruta con la máxima eficiencia en función de todos los factores.
Comparta aquí sus comentarios y experiencias o póngase en contacto con nosotros en nuestro foro. Véase Documentación relacionada con la compresión de Couchbase aquí.
Gracias Chaitra por este post.
¿Hay alguna forma de medir la compresión alcanzada (en disco)? Supongamos que se rellena un bucket con 100m de documentos. Una vez hecho esto, vemos que hay 3-4 sabores diferentes. Así que no podemos multiplicar realmente el número de documentos por el tamaño de cada documento porque no conocemos el tamaño de cada documento. E incluso si identificamos un documento (de muestra) de cada sabor, no es necesario que todos los documentos de ese sabor tengan el mismo tamaño. Y parece que no hay forma de hallar el tamaño medio de los 100 millones de documentos (¿o hay alguna forma?).
Entonces, si nos fijamos en el tamaño de los datos en el disco, es el tamaño después de la compresión.
Si conociéramos el tamaño antes de la compresión y lo comparáramos con el tamaño en disco (datos comprimidos), se podría haber determinado la relación de compresión.
Gracias