Couchbase 101-102-103 (Serie 1)

Recientemente comenzamos una serie de webinars online para cubrir los componentes principales de Couchbase Server, desde la instalación hasta la configuración para el desarrollo y la comprensión de la indexación. Varias preguntas surgieron durante los webinars y estoy publicando un escrito Q & A aquí.

Mi generador de carga basado en Ruby puede descargarse aquí: https://github.com/scalabl3/ruby-couchbase-loadgen

Couchbase 101 - Instalación y configuración

P: Cuando se añade un servidor, ¿se hace sharding?

R: Sí, usamos "Hash Sharding" para todos los datos, lo que significa que para cada par clave-valor, hacemos un hash de la cadena clave para obtener el número de partición (un contenedor lógico) en el que debería vivir. Buscamos el número de partición en el mapa del cluster para ver dónde se encuentra esa partición en el cluster de Couchbase, y luego hacemos CRUD directamente con el nodo de Couchbase responsable de esa partición. Cuando añades un nuevo servidor (o más de uno), simplemente redistribuimos las particiones uniformemente entre el nuevo número de nodos.

P: ¿Tenemos que añadir servidores sólo para la réplica?

R: Las replicas, para ser efectivas en una situación de failover, necesitan estar localizadas en diferentes nodos para que los nodos puedan ser "failover". Para una réplica, tiene que haber al menos dos nodos Couchbase. Para dos réplicas tiene que haber al menos tres nodos Couchbase, y para tres réplicas tiene que haber al menos cuatro nodos Couchbase. Por supuesto, aumentar el número de réplicas también aumenta la necesidad de mayores recursos para un rendimiento óptimo.

P: ¿Todos los documentos con el mismo valor hash se almacenan en la misma partición?

R: Si, nuestra función Hash simplemente convierte una cadena de claves en un número de [0...1023], todas las claves que tengan como hash el número 2 vivirán dentro del contenedor de particiones #2. Esa partición residirá en un nodo particular de Couchbase en el cluster, si añades más servidores y reequilibras, esa partición puede ser movida a otro servidor, pero sólo hay un nodo que es el "maestro" para esa partición. La "réplica" de esa partición vivirá, por supuesto, en un nodo separado.

P: En tu ejemplo de escala horizontal, el total de particiones es siempre 1024. Es 1024 el máximo de particiones en un clúster?

R: Al conocer por primera vez nuestro esquema de fragmentación y distribución, muchos desarrolladores ven este número como un botón que ajustar, naturalmente, ya que todos somos unos manitas. Sin embargo, el número de particiones no cambia las características de rendimiento. Creemos que 1024 es un buen número de particiones para una distribución uniforme de los datos, no es realmente algo que deba cambiarse y no es un parámetro de configuración. El número podría ser fácilmente 10.000 o 990, y no cambiaría la arquitectura de cómo distribuimos los datos (sólo aumentaría o reduciría el número de archivos de datos).

P: ¿Cuántos Buckets se pueden instalar en una sola máquina virtual?

R: Esta es una pregunta difícil para dar una regla general, porque los recursos asignados a esa máquina virtual pueden variar mucho, pero en general para una máquina de tamaño considerable de 8+ núcleos, alrededor de 10-12 Buckets es factible. Para cada Bucket asignamos recursos para gestionar y monitorizar, por lo que tener un gran número de Buckets aumenta la sobrecarga de la CPU y generalmente no es recomendable.

P: ¿El reequilibrio de los nodos tiene algún efecto sobre la eficiencia de Couchbase?

R: Priorizamos las operaciones primarias sobre las operaciones de rebalanceo en Couchbase, pero dicho esto, hay un incremento de CPU y tráfico de red entre los nodos de Couchbase durante un rebalanceo. Se recomienda hacer el rebalanceo en horas de menor uso, por supuesto, lo mismo va para hacer copias de seguridad, al igual que cualquier otro sistema. Hacer un rebalanceo en horas punta de uso ralentizará el tiempo de rebalanceo si el pico de uso es muy alto.

P: Al reequilibrar, ¿se mueven las particiones a otro nodo o se duplican?

R: Se copian hasta que finaliza el reequilibrio, en caso de que se produzca un fallo durante el reequilibrio. El nodo maestro original sigue siendo el nodo maestro hasta que el reequilibrio finaliza por completo. Una vez finalizado el reequilibrio, el nuevo nodo maestro para esa partición se convierte en el maestro y el antiguo elimina sus datos, y los mapas del clúster se actualizan en consecuencia en todo el clúster, y luego los sdk del cliente.

P: ¿Qué herramientas hay disponibles para hacer copias de seguridad/restaurar y para ayudar a la recuperación en caso de catástrofe?

R: Disponemos de las herramientas de línea de comandos cbbackup y cbrestore para este propósito, puede leer sobre ellas aquí: http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-backup-restore-backup-cbbackup.html

Couchbase 102 - Desarrollo

P: ¿Qué ocurre cuando se almacenan imágenes en Couchbase? 

R: Puedes almacenar imágenes de dos maneras diferentes con Couchbase, una es almacenar datos binarios directamente como un valor Document. La segunda opción es almacenarla como bases64 pre-codificadas dentro de un documento JSON, entonces es un documento JSON estándar con una o más imágenes codificadas como valores JSON (con claves JSON). La ventaja de almacenamiento de imágenes en Couchbase es que se servirá desde RAM en lugar de disco, por lo que tendrá un gran rendimiento. Combina esto con XDCR (Cross Data Center Replication) y podrás crear tu propia CDN para imágenes.

P: ¿Cómo se modifican/actualizan varios documentos y se da marcha atrás si se produce un error en uno de ellos?

R: En Couchbase puedes usar fácilmente Optimistic (CAS) o Pessimistic (Lock) Concurrency para transacciones en solo pero para múltiples documentos en una única "transacción", necesitará utilizar lo que se denomina Two-Phase Commit. Puede leer más sobre ello aquí: http://www.couchbase.com/docs/couchbase-devguide-2.0/two-phase-commits.html

P: ¿Existe la posibilidad de realizar transacciones en Couchbase?

R: Como en la pregunta anterior, puede realizar fácilmente transacciones de un solo documento utilizando Optimistic Concurrency con (CAS - Compare and Swap), o Get and Lock.

P: ¿Existe una operación de inserción/actualización por lotes que devuelva la llamada con una lista de inserciones/actualizaciones fallidas después de la escritura en el disco primario?

R: En algunos SDK's (Python por ejemplo) tienen operaciones de tipo multi-conjunto (todos ellos tienen operaciones multi-get), pero no creo que tengamos soporte para operaciones de tipo multi-conjunto Y observar.

P: ¿Cómo puedo hacer una consulta con múltiples parámetros a pasar, como nombre, fecha y estado? ¿algo así como un "where" en SQL?

R: Esto se hace con nuestras Vistas (Índices), la consulta de múltiples parámetros puede requerir a) consultar vistas separadas y hacer una intersección dentro de su aplicación, o ser creativo con la clave de su índice para que pueda realizar una consulta de rango. Hay varias estrategias diferentes para esto, y será particular a un caso de uso y el diseño del documento para ser capaz de responder de manera sucinta.

P: ¿Son compatibles con otros lenguajes como Go o Clojure?

R: ¡Sí! Tenemos ediciones comunitarias para Go (https://github.com/dustin/go-couchbase), puedes ver todos los clientes de la comunidad en nuestra página Todos los clientes en couchbsae.com: http://www.couchbase.com/communities/all-client-libraries Las bibliotecas de clientes de la comunidad no están soportadas oficialmente por nuestros contratos de soporte, pero puedes encontrar fácilmente ayuda de nuestros ingenieros a través de IRC o twitter.

P: ¿Los patrones clave son más rápidos que las vistas?

R: En la mayoría de los casos en los que se pueden utilizar Key Patterns, sí, porque son operaciones binarias que salen de la caché RAM, pero no todo se puede modelar utilizando Key Patterns. En esos casos, es cuando nuestras Vistas (Índices) son útiles y también nuestra integración con Elastic Search.

Couchbase 103 - Vistas, indexación y consultas

P: ¿Los índices se guardan en memoria?

R: No, todos los índices (al igual que otros sistemas de indexación en otras bases de datos) se crean y consultan desde el disco. El sistema operativo utilizará la RAM para la caché del sistema de archivos, lo que mejorará considerablemente el rendimiento de la consulta de índices. Por eso dejamos una buena porción de RAM para que lo haga el sistema operativo (40% de RAM disponible).

P: ¿Se distribuyen automáticamente los índices entre varios nodos? ¿Se pueden colocar índices sólo en determinados nodos por motivos de rendimiento? Por ejemplo, si tuviera una operación de consulta/índice pesada que no quisiera que afectara a varios nodos.  

R: Cada nodo de Couchbase mantiene índices para las particiones maestras/activas que residen en él (para las que es el "maestro"). Debido a que los datos están distribuidos uniformemente por nuestro Hash sharding de claves a particiones, no podrás tener índices sólo en ciertos nodos sin un índice incompleto. Sin embargo, una vez dicho esto, se podría emplear una estrategia diferente de tener un clúster completo separado que está en el extremo receptor de un XDCR unidireccional (Cross Data Center Replication) que está recibiendo documentos de su almacén de datos primario (sólo recibiendo, no utilizado para la creación o actualización de datos) que puede utilizarse para indexación y consultas pesadas y optimizarse completamente para ese fin.

P: ¿Se puede ocultar el meta.id de una vista concreta a nivel de interfaz? ¿Simplemente se elimina de los parámetros de la función map? Cuando usted está utilizando un sitio web, por ejemplo, y un cliente está consultando la base de datos .. y usted no desea mostrar la meta.id?

R: No, todas las claves del documento (id's) se incluyen con el conjunto de resultados en JSON para el documento que generó esa "fila" de resultados (en realidad un elemento del array de resultados). Dejarlo fuera de la función map no cambia eso. Lo que puedes hacer para resolver el segundo caso sería no hacer que el javascript de tu página web consulte a Couchbase directamente (lo cual no recomendaría de todos modos ya que significa que tu servidor Couchbase está expuesto, al igual que cualquier base de datos que normalmente no se expone al público). En su lugar, puedes ejecutar la consulta a través de tu propia API y filtrar el conjunto de resultados para que no tengan id's de documentos (meta.id).

P: Al consultar una vista con skip, el tiempo de respuesta parece proporcional al tamaño del skip. ¿Es eso lo que se espera?

R: Es mejor usar un par de parámetros en lugar de usar skip, la startkey y startkey_docid para buscar. Los resultados se ordenan primero por startkey (su clave de índice) y luego, si hay varias claves de índice idénticas en el conjunto de resultados, se ordenan por startkey_docid. La razón para utilizar este método es doble, una es que evita el problema del tiempo de respuesta, que también empeora a medida que crece el cluster porque la dispersión se verá afectada por el salto - cuantos más nodos, más tiempo se tarda en saltar en cada nodo ya que las consultas están dispersas por todo el cluster. En segundo lugar, el conjunto de resultados cambiará cuando se actualice el índice, por lo que el "salto" no saltará exactamente lo mismo después de la primera consulta.

Gracias por leerme.

Jasdeep Jaitla
jasdeep@couchbase.com
@scalabl3