Couchbase Server 2.0: Preguntas más comunes (y respuestas)

Acabo de terminar una serie de webinars técnicos de nueve semanas de duración en los que se destacaban las características de nuestro próximo lanzamiento de Couchbase Server 2.0. Fue una pasada interactuar con cientos de participantes. Ha sido un placer interactuar con los cientos de participantes, y me ha sorprendido el nivel de entusiasmo, compromiso y expectación por este nuevo producto.

(Por cierto, si te perdiste la serie, las nueve sesiones están disponible para reproducción.) A lo largo de la serie de seminarios web, los usuarios plantearon preguntas muy interesantes, y mi plan original era utilizar esta entrada de blog para destacarlas todas. Rápidamente me di cuenta de que eran demasiadas como para esperar que alguien las leyera todas, así que he tomado otro camino. Este blog recogerá las preguntas más comunes, importantes o interesantes y las responderá aquí para beneficio de todos. Antes de entrar en materia, responderé a la pregunta más frecuente: "¿Cuánto falta para la AG de Couchbase Server 2.0?" Actualmente estamos en camino de lanzarlo antes de fin de año. Mientras tanto, siéntete libre de experimentar con la Developer Preview que ya está disponible. En cuanto al resto de preguntas, ¡ahí van!

P: ¿Cuáles son las principales ventajas de incorporar Membase y CouchDB en un único producto?

R: Membase es un almacén de valores clave súper rápido y altamente escalable, conocido por su rendimiento y escalabilidad. Por otro lado, CouchDB es una gran base de datos de documentos, con potentes capacidades de indexación y consulta. La combinación de estos dos productos reúne lo mejor de ambos mundos para crear una base de datos NoSQL de alto rendimiento y gran elasticidad que se escala linealmente al tiempo que proporciona funciones de consulta, indexación y orientadas a documentos.

P: ¿Acelera Couchbase el acceso a un documento de base de datos almacenándolo automáticamente en memoria caché?

R: ¡Por supuesto! Esa es una de las grandes características de Couchbase Server 2.0, y viene de la vasta experiencia que tenemos con memcached. Todo el acceso a los documentos pasa a través de nuestra capa de caché RAM integrada (construida a partir de memcached) para proporcionar una latencia extremadamente baja y, lo que es más importante, predecible, bajo cargas extremadamente pesadas. Por ejemplo, nuestros clientes suelen realizar más de 100.000 operaciones/segundo en un clúster y hemos llegado a realizar más de 200.000 operaciones/segundo en nodos individuales en nuestros propios entornos de prueba. Esta capa de caché RAM también nos permite gestionar picos de carga de escritura (y lectura) sin afectar al rendimiento de la aplicación.

P: Veo en vuestros foros que Couchbase Server 2.0 utiliza el protocolo memcached para acceder a los datos ya que es compatible para los usuarios existentes de Membase y también por el rendimiento mucho mayor. ¿Hay alguna forma de usar APIs REST similares a las de CouchDB para acceder a los documentos en Couchbase Server 2.0?

R: La primera versión de Couchbase Server 2.0 usa el protocolo memcached para el acceso a documentos, y el protocolo HTTP de CouchDB para acceder a vistas. Con el tiempo, estos dos se fusionarán aún más. Mientras tanto, hemos proporcionado un número de librerías cliente que abstraen estos dos métodos de acceso del desarrollador.

P: ¿Couchbase Server 2.0 será de código abierto?

R: ¡Ya lo es! Como compañía, Couchbase está totalmente comprometida con el desarrollo de las comunidades de código abierto que existen y se están construyendo alrededor de nuestros productos. Aunque nuestro objetivo es proporcionar software empresarial a nuestros clientes de pago, aceptamos el libre flujo de ideas y la amplia adopción que permite un proyecto de código abierto y creemos firmemente que hay un lugar para ambos.

Indexación/consulta

P: "Todo lo que necesito es un índice secundario simple, no map/reduce... ¿cómo lo hago?

R: Actualmente, todos nuestros índices se construyen usando una función map (la reducción es totalmente opcional y puede ignorarse aquí). Esto es realmente sólo otra sintaxis para crear un índice y hay una variedad de ejemplos avialable discutir cómo crear índices muy simples. La forma más simple implicaría simplemente poner "emit(doc.)" en tu función map donde está lo que quieres indexar. Esto creará una lista de todos los documentos que contengan ese campo, ordenados por ese campo. Por supuesto, hay escenarios más complejos, pero se puede hacer bastante simple si eso es lo que se necesita.

P: ¿En qué se diferencian las vistas de Couchbase Server 2.0 de las de CouchDB y Couchbase Single Server?

R: En absoluto... el formato, la sintaxis, todo es igual. Además, todas las opciones de consulta son compatibles. Puedes copiar y pegar literalmente el código de la vista de una a otra. También se admiten múltiples documentos de diseño.

P: ¿Soporta Couchbase Server 2.0 consultas ad-hoc?

R: Por el momento, todas las consultas a Couchbase Server (como CouchDB) deben hacerse contra vistas pre-materializadas. En general, esta es la única manera de proporcionar un rendimiento fiable al hacer esas consultas. También entendemos la necesidad de más consultas bajo demanda/ad-hoc y estamos trabajando diligentemente para proporcionar eso también. Couchbase ya ha empezado a adoptar un enfoque líder en el sector para crear un lenguaje específico para datos no estructurados que pueda utilizarse en todo el panorama NoSQL. Echa un vistazo a http://unqlspec.org para ver en qué estamos trabajando.

SDKs/Bibliotecas cliente

P: ¿Qué SDK y bibliotecas cliente son compatibles?

R: A nivel básico, Couchbase Server 2.0 soporta cualquier librería que implemente el protocolo memcached (y hay MUCHAS). Para la funcionalidad adicional que hemos añadido (comandos de protocolo extendidos y acceso a vistas) Couchbase proporciona librerías cliente para una variedad de lenguajes (Java, .NET, PHP, Python, Ruby, C/C++) así como instrucciones de cómo extender librerías para otros lenguajes.

P: ¿Existe alguna posibilidad de dogpiling con stale=update_after? Si se reciben 30 peticiones simultáneas para una vista con stale=update_after, ¿se generarán varias peticiones simultáneas para actualizar el índice?

R: Para recapitular, "stale" indica al servidor que esta solicitud de consulta debe devolverse lo antes posible, sabiendo que algunos datos que ya se han escrito pueden no estar incluidos en la vista. Al poner también "update_after" en la petición, el cliente le está diciendo al servidor que rematerialice el índice en segundo plano... después de devolver la petición inicial lo más rápidamente posible. Una vez iniciada esta rematerialización, las peticiones subsiguientes no harán que ocurra nada diferente, por lo que no hay que preocuparse por problemas de "dogpiling" o "stampeding herd".

P: ¿Cómo sabe el cliente cuándo debe actualizar los mapas del servidor/vbucket?

R: Todos los clientes (ya sean nuestros clientes "inteligentes" o estén pasando por nuestro proceso Moxi) mantendrán una conexión de streaming a un servidor Couchbase. Cuando la topología del cluster cambie (añadir/eliminar/nodos), los clientes serán automáticamente actualizados con un nuevo mapa vbucket a través de esta conexión. Los clientes también pueden solicitar este mapa bajo demanda, y hacerlo cada vez que se inician. Además, cada nodo del cluster sabe de qué vbuckets es responsable y sólo devolverá datos de esos vbuckets. De este modo, aunque un cliente esté temporalmente desincronizado con el clúster, nunca será vulnerable a datos incoherentes.

Uso de la vista Desarrollo/Producción

P: ¿Por qué el esfuerzo adicional de crear una vista en modo "desarrollo" y luego pasarla a producción?

R: Queríamos ofrecer la posibilidad de desarrollar vistas en un conjunto de datos en vivo, pero no queríamos que ese desarrollo afectara a la aplicación en ejecución. Por lo tanto, se creó un modo de "desarrollo" para que los usuarios pudieran crear y editar vistas en datos "reales". Para acelerar las iteraciones de desarrollo, por defecto se materializa una vista sobre un subconjunto de los datos. Una vez finalizado el desarrollo, el usuario puede optar por materializar la vista sobre todo el clúster justo antes de pasarla a producción. Esto ofrece la ventaja añadida de materializar la vista de modo que esté inmediatamente lista para ser utilizada por la aplicación. Por último, este modo de "desarrollo" puede utilizarse para editar vistas que se encuentran actualmente en producción, sin que ello afecte al acceso de la aplicación a las mismas (realizando una copia). Una vez finalizada la edición, la vista puede materializarse y pasar a producción junto con la original.

P: ¿Cómo se controla cuál es el conjunto de datos de desarrollo?

R: Actualmente, el software decide automáticamente el conjunto de datos de desarrollo en función de la cantidad de datos existentes. En el caso de conjuntos de datos pequeños, el software materializará la vista en todo el conjunto. A medida que aumente, el programa lo reducirá automáticamente para proporcionar un tiempo de respuesta más rápido durante el desarrollo. Una vez finalizada la vista, el usuario tiene la opción de ejecutarla en todo el conjunto de datos manualmente (haciendo clic en la pestaña "Conjunto de datos de clúster completo"), tanto a efectos de verificación final como para prepararla para su uso en producción.

Agrupación

P: En el caso de un bucket con réplica y auto-failover, ¿provocará un fallo del servidor sin reequilibrio errores de recuperación/actualización en ese bucket?

R: Cuando un servidor falla inicialmente (por la razón que sea: hardware, red, software) la aplicación obtendrá brevemente errores para cualquier dato del que ese servidor fuera responsable. Las peticiones de datos a otros servidores no se verán afectadas. Estos errores continuarán hasta que el nodo sea "fail over", lo que activará la réplica de datos (vbuckets) en otra parte del cluster. La cantidad de tiempo variará dependiendo de si usted está utilizando la conmutación por error automática o manual ... pero una vez que la conmutación por error se activa no hay más demora. Te preguntarás "pero por qué no puedo leer de la réplica datos que ya existen". La respuesta es doble. En primer lugar, no permitimos específicamente el acceso a los datos de la réplica (mientras es "réplica") para preservar la consistencia muy fuerte que nuestro sistema proporciona. En condiciones normales de funcionamiento, se garantiza la "lectura de sus propias escrituras" y esto se consigue proporcionando una única ubicación para acceder a cualquier dato. Al permitir la lectura sin restricciones de las réplicas, podría darse el caso de que un cliente escribiera un dato en la copia activa y otro cliente intentara leerlo inmediatamente de la réplica... lo que podría provocar una incoherencia. Ahora, la segunda parte de esta respuesta es que actualmente estamos trabajando en una característica para permitir la lectura de estas réplicas. Será una nueva operación que será invocada explícitamente por la aplicación para que no haya ninguna confusión sobre qué copia se está leyendo. Aún así, querrás conmutar por error el nodo lo antes posible, ya que las escrituras seguirán fallando. Este es un ejemplo de las muchas características que hemos añadido como respuesta directa a las demandas de nuestros clientes y usuarios... ¡Usted habla y nosotros escuchamos (y también hacemos algo al respecto)!

P: ¿Existe algún efecto/riesgo/tiempo al reequilibrar un sistema sometido a grandes cargas de escritura? ¿Es mejor añadir nodos en momentos de poca carga?

R: Por su diseño, la operación de reequilibrio se realiza de forma asíncrona para que tenga el menor impacto posible en el rendimiento del clúster. Sin embargo, la realidad es que el reequilibrio aumenta la carga del clúster y requiere recursos para hacerlo (red, disco, RAM, CPU). Si el clúster ya está cerca de su capacidad, cualquier aumento de carga puede afectar al rendimiento de la aplicación. Aunque es seguro hacerlo en cualquier momento, recomendamos encarecidamente que realice sus propias pruebas en su propio entorno para caracterizar qué impacto tendrá un reequilibrio, si es que lo tiene. Por lo general, nuestros clientes realizan estas pruebas en momentos de poca actividad o tranquilidad, pero la principal ventaja es que no es necesario desconectar completamente la aplicación mientras se sigue escalando.

P: ¿Qué es un vbucket?

R: Un vbucket es nuestra forma de particionar lógicamente los datos para que puedan repartirse entre todos los nodos de un clúster. Cada bucket de tipo Couchbase que se crea en el clúster se divide automáticamente (y de forma transparente) en un conjunto estático de porciones (los vbuckets). Estos se "asignan" a servidores individuales. Cuando se añade o elimina un nodo, son estas porciones las que se mueven y se reasignan para proporcionar un escalado lineal y no disruptivo. Aunque totalmente abstraído de la aplicación y el usuario, es importante darse cuenta de que los vbuckets existen "bajo el capó" para proporcionar muchas de las maravillosas capacidades que tiene Couchbase Server. Puedes aprender más sobre el concepto de vbucket.

Supervisión

P: ¿Es la Web UI de Couchbase Server el único método para monitorizar un cluster de Couchbase Server?

R: No necesariamente. Todo lo que ve y puede hacer en la interfaz web está controlado por nuestra interfaz REST, a la que se puede acceder mediante programación externa. Además, cada servidor individual (y cada cubo individual en ese servidor) proporciona sus propias estadísticas "en bruto" que son utilizadas por la API REST. Estas estadísticas en bruto también están disponibles externamente:

Nuestro objetivo es proporcionar toda la información posible sobre el sistema para que nuestros usuarios puedan supervisarlo eficazmente, tanto desde el punto de vista de la planificación de la capacidad como del diagnóstico y la resolución de problemas cuando las cosas empiecen a ir mal (o para evitar que vayan mal desde el principio).

P: ¿Qué tipo de alertas proporciona Couchbase Server?

R: Técnicamente, no somos una empresa que fabrique software de alerta. En nuestra opinión, nuestro trabajo consiste en proporcionar una interfaz que otros sistemas puedan utilizar. La mayoría de las grandes organizaciones no querrían que cada pieza de tecnología de su pila enviara un conjunto de alertas con un formato diferente. Por eso hemos hecho que sea tan fácil conectar nuestras estadísticas y datos de supervisión a cualquier otro sistema. Sin embargo, también somos conscientes de que algunos entornos más pequeños pueden querer que nuestro software proporcione esto de forma inmediata. Estamos trabajando para ampliar nuestras capacidades en este sentido y ya proporcionamos alertas para cuando los nodos se caen.

Autocompactación

P: Si se cancela la compactación al final del periodo de tiempo, ¿se guarda la compactación realizada hasta ese momento o se pierde toda la compactación realizada hasta ese momento?

R: Normalmente, una compactación es todo o nada, por lo que al abortarla se perderá el progreso que se haya hecho hasta el momento. Sin embargo, dentro de Couchbase Server, estamos realizando la compactación en una base por vbucket (ver arriba) y así todo el conjunto de datos puede ser compactado incrementalmente sin perder todo el progreso que ha hecho cuando se aborta.

Autofailover

P: ¿Por qué se produce un retraso antes de que el clúster conmute automáticamente por error un nodo caído?

R: Por defecto, el software está configurado con un mínimo de 30 segundos antes de que se active la conmutación automática por error. Esto está diseñado para evitar que el software haga "lo incorrecto". Por ejemplo, si un nodo es simplemente lento para responder, o hay un breve contratiempo en la red, usted no querría que fallara, por lo que el clúster esperará para asegurarse de que el nodo está realmente caído.

Para obtener aún más información, puedes ver los vídeos de 25-30 minutos del seminario web de cada semana aquí. Y el lugar autorizado para toda la información relativa a Couchbase Server 2.0 se puede encontrar aquí. Aunque esta serie haya llegado a su fin, ya estamos planeando empezar otra para destacar no sólo las características de Couchbase Server 2.0, sino también Couchbase Mobile, nuestros SDKs/librerías cliente y ¡mucho más! Algunos de los temas incluirán:

• Sincronización entre clústeres (también conocida como replicación entre centros de datos)
• Copia de seguridad/restauración con Couchbase Server 2.0
• Actualización desde Membase 1.7
• Y mucho más.

Para hacerlo aún mejor, ¡te pido que me ayudes a participar! Por favor, comenta aquí (o envíame un correo electrónico directamente a perry@couchbase.com) con cualquier tema que crea que necesitamos cubrir más y haremos todo lo posible por incluirlo en un próximo seminario web.