Couchbasics: Cómo las necesidades funcionales y de rendimiento determinan el acceso a los datos en Couchbase

Hay múltiples maneras de obtener datos dentro y fuera de Couchbase. Fíjate que no he dicho consultar, he dicho entrar y salir... a propósito. No todas las formas de obtener datos dentro y fuera de Couchbase son consultas como en otras bases de datos. Couchbase ofrece múltiples formas que proporcionan diferentes capacidades/funcionalidad y características de rendimiento que puedes mezclar y combinar para satisfacer las necesidades de tu aplicación. Vamos a enumerar los diferentes patrones de acceso a datos de Couchbase y luego nos sumergiremos en la aplicación práctica de cada uno.

1. Lectura/escritura de datos por ID de objeto (clave)
2. Leer datos de una Vista
3. Lectura/Escritura/Actualización de datos mediante N1QL
4. Búsqueda de texto completo mediante Solr o Elastic

Cuándo y dónde utilizar cada método

Con la introducción de N1QL (pronunciado "nickel") y los Servicios de Consulta e Índice a Couchbase en 4.0, Couchbase obtiene un nuevo nivel de funcionalidad. N1QL aporta un cumplimiento casi total de SQL ANSI-92. (Digo casi, ya que N1QL omite características que son útiles en una base de datos relacional, pero no en una base de datos de documentos. A la inversa, tiene características que son necesarias para una base de datos de documentos, pero que no son apropiadas para una base de datos relacional. En otras palabras, es a la vez un subconjunto y un superconjunto de SQL ANSI-92). Pero seamos claros, N1QL es NO pretendía y debía NO sustituye a los otros medios para leer y escribir datos que tenía Couchbase antes de la versión 4.0. Simplemente ofrece otra forma de acceder a los datos.

Con la introducción de N1QL, la necesidad de Solr y Elastic ha disminuido ya que Couchbase soporta consultas completas para las que la mayoría de la gente utilizaba estas dos herramientas. Todavía son necesarias si tu aplicación necesita búsqueda de texto completo. Ambas plataformas tienen una excelente integración con Couchbase para proporcionar esta funcionalidad.

Cada uno de los cuatro medios de acceso a los datos es una herramienta en su caja de herramientas y cada una tiene un propósito diferente. Cada herramienta debe utilizarse según las necesidades funcionales y de rendimiento de ese caso de uso. Recuerde, estas herramientas no son una situación de "lo uno o lo otro". Usted puede mezclar y combinar estas herramientas para su beneficio. Por ejemplo, puedes consultar una Vista que emita IDs de objetos y luego usar esos IDs con un BulkGet paralelizado usando el SDK de Couchbase para leer todos esos objetos, o simplemente hacer create/read/update/delete (CRUD) en todos esos objetos, lo cual será muy rápido. Así que juntas estas herramientas te proporcionan formas estándar y escalables que cualquiera puede utilizar para obtener datos dentro y fuera de Couchbase con facilidad y flexibilidad.

Pero entremos en detalles...

Lectura/Escritura de datos por ID de objeto (clave)

En su núcleo, Couchbase es una increíble base de datos clave/valor y siempre lo ha sido. Acceder vía ID de objeto es también uno de los conceptos más difíciles en Couchbase para que la gente lo entienda rápidamente y lo use sabiamente (de ahí la longitud de esta sección). Una vez que comprenden su poder, ven lo que puede proporcionar y cómo pueden aplicar esta herramienta. El acceso mediante ID de objeto es la bestia incomprendida y poderosa del rincón. Así que vamos a entender mejor esta bestia y cómo podemos aprovecharla para nuestro beneficio.

Permítanme ser claro antes de empezar, el acceso a los datos a través de ID de objeto (clave) se siempre ser más rápido que la consulta. Es la diferencia entre conocer la respuesta para obtener los datos y tener que hacer una pregunta (consulta) para encontrar esos datos. Supongamos que entras en una biblioteca y necesitas un libro concreto. Si conoce la identificación del libro, vaya a la planta uno, fila tres, estante cuatro, tercer libro por la derecha. Vas allí, lo coges, pasas por caja y te vas. Si no tienes la identificación del libro, puedes preguntar al bibliotecario o al informático, darles la información que tienes (autor, título, etc.) y ellos te llevan al lugar para recuperar el libro, o peor aún, miras todos los libros y al final lo encuentras. Cuando conoces el ID del objeto, no hay necesidad de una búsqueda indexada de tus datos; simplemente obtienes los datos que necesitas directamente de la caché gestionada de Couchbase. Es extremadamente rápido, con tiempos de acceso muy consistentes y una latencia muy baja. Así que asegúrate de no comparar su rendimiento con los otros métodos de acceso, ya que cada uno es para diferentes necesidades funcionales.

Ahora puedes decir al acceso clave/valor: "¡meh, necesito consultas!". Puede que sí y puede que no. En Couchbase, acceder a los datos con el ID de objeto puede ser muy potente, ya que el ID de objeto puede tener un máximo de 250 bytes y, dependiendo de cómo utilices el ID de objeto, podría permitirte evitar la consulta. El verdadero poder de lo que puedes hacer con ese ID de objeto es cuando utilizas un patrón estandarizado para cada ID de objeto que tu aplicación puede construir para ir tras los datos exactos que necesita, cuando los necesita. Piensa en el ID de objeto como una extensión de tu modelado general de objetos. Combina todo esto con la arquitectura de Couchbase, y te habrás asegurado de que tu aplicación obtiene los datos que necesita lo más rápido posible de la caché gestionada integrada. Un momento de precaución. Por defecto, Couchbase almacenará todos los IDs de cada objeto en la caché gestionada por razones de rendimiento. Así que no te vuelvas loco con claves grandes. Por ejemplo, si tienes 250 millones de objetos multiplicados por 250 bytes de datos, se necesitan alrededor de 58GB de RAM en todo el cluster, sólo para las claves. Así que sólo porque puedas tener una clave de 250 bytes, no significa que debas. A gran escala esto podría convertirse en un problema, por lo que yo recomendaría mantenerlas por debajo de 100.

La arquitectura de Couchbase con los niveles combinados de caché y persistencia sobresale en patrones de acceso a datos que podrían ser paralizantes para otras bases de datos, especialmente las relacionales. La lectura de múltiples objetos directamente desde la caché gestionada es considerablemente más rápida que en las bases de datos tradicionales. Y con otras bases de datos, necesitas restringir los viajes de ida y vuelta a la base de datos. Con Couchbase, puedes leer un documento, obtener datos de él, y luego leer más objetos basados en eso, todo en el mismo tiempo total o incluso menos de lo que tardan otras bases de datos en hacer sólo esa consulta y devolver los resultados. La penalización por múltiples viajes a Couchbase es dramáticamente menor y de hecho se fomenta.

Le daré algunos ejemplos de lo que se entiende por patrones estandarizados de identificación de objetos:

login-info::hernandez94

Este objeto almacena la información de inicio de sesión para un nombre de usuario único de hernandez94 en un directorio almacén de perfiles de usuario. Así que cuando usted necesita para autenticar a este usuario, que acaba de agarrar este documento JSON que sólo contiene su información de acceso.

preguntas de seguridad::hernandez94

En este mismo ejemplo de almacén de perfiles de usuario, este objeto almacenaría un documento JSON de las tres preguntas de seguridad de ese usuario. Cuando olviden su contraseña, todo lo que tu aplicación tiene que hacer es obtener este objeto. La otra cosa buena es que como las preguntas de seguridad no se acceden a menudo, pueden caer fuera de la caché gestionada para los objetos que se utilizan a menudo y eso está bien.

Puedes ver que con unos patrones de identificación de objetos estándar como estos, tu aplicación podría crearlos con la información que tiene disponible y luego interactuar con estos objetos directamente en Couchbase. Sin necesidad de consultar la base de datos. Podríamos profundizar en las estrategias de modelado de objetos, pero eso está fuera del alcance de este artículo. Para más información, lee "Arquitectura orientada al rendimiento"por Chris Anderson.

Para ver algunos ejemplos más concretos de cómo puede utilizar un patrón de ID de objeto normalizado en su aplicación, consulte este y este que escribí. Incluso si los casos de uso específicos de los blogs no son aplicables al suyo, podrían ayudarle a comprender mejor el uso de los patrones de ID de objeto y cómo podrían aplicarse a su propio caso de uso.

Pros:

• Acceso muy rápido y si tu cluster tiene el tamaño correcto, el objeto ya está en la caché gestionada de Couchbase.
• Flexibilidad para buscar datos a través del ID del objeto
• Los datos son fuertemente coherentes. Es decir, siempre se leen las propias escrituras.
• Se amplía linealmente con una distribución uniforme de los datos entre los nodos.

Contras:

• La aplicación requiere más inteligencia para acceder a los objetos que necesita
• Modelización de datos más avanzada
• Conocimiento más profundo de los patrones de acceso a datos de su aplicación antes de escribirla.

Lectura de datos de una vista

Hasta Couchbase 4.0, los índices View eran la única forma de consultar Couchbase si no conocías el ID del objeto. Ahora que tenemos los Servicios de Consultas e Índices manejando N1QL, volvamos a ver qué son las Vistas de Couchbase, para qué son mejores, y por qué definitivamente siguen siendo relevantes.

Las vistas en Couchbase son una función map-reduce javascript que genera un índice. La vista es actualizada automáticamente por la base de datos a medida que ocurren las mutaciones. Tu aplicación puede entonces consultar ese índice de vista para devolver IDs de objetos.

Por ejemplo, la dirección necesita saber de forma semiregular cuántos usuarios de iOS tenemos, qué versión de la aplicación utilizan y de qué país son, pero hacerlo a través de 30.000.000 de documentos de usuario en la base de datos. Las vistas lo solucionan muy bien, ya que esa información se calcula a medida que los datos se insertan o actualizan en la base de datos. Así, cuando se necesita consultar esa vista precalculada, la consulta es relativamente barata.

Una cosa a tener en cuenta, sin embargo, es que las vistas son finalmente consistentes por defecto. Al consultarlas, puede utilizar "stale=false" para forzar la actualización de la vista. antes de y es más probable que sea muy coherente. Sin embargo, esto tendrá una penalización en el rendimiento. La penalización depende de la frecuencia con que cambien los datos en la base de datos y de cómo esté diseñada la vista. El flujo de satisfacer una consulta de vista con stale=false activado es: Tu aplicación llama a los nodos del cluster, ellos actualizan el índice de la vista en los nodos del cluster, luego vuelven a la aplicación con los resultados. Ahora imagina esto con una tasa de inserción/actualización muy alta y una tasa de consulta alta y verás dónde puedes tener problemas. Tenlo en cuenta.

Pros:

• Facilita la consulta de grandes cantidades de datos
• Se puede programar con Javascript ejecutado en el lado del servidor en tiempo real para proporcionar funcionalidades no disponibles en otras áreas de Couchbase
• Una vez creado, examina cada objeto a medida que se actualiza o inserta para su inclusión
• Cada nodo del Servicio de Datos sólo procesa su parte de los datos totales del clúster. Por ejemplo, en un clúster de cuatro nodos, cada nodo tiene 25% de los datos activos y, por tanto, sólo indexa esos 25% que tiene.

Contras:

• Deben programarse con Javascript. Esto hace que sean un poco más complicados de acostumbrarse, pero también potentes.
• Los índices de la vista se reparten entre los nodos del Servicio de Datos, no entre el Servicio de Índices. Cuantos más nodos tenga como parte del Servicio de Datos, más nodos tendrá que obtener el motor de vistas para devolver una respuesta a la aplicación.
• Eventualmente consistente por defecto, pero se puede consultar con stale=false, pero asumiendo el impacto en el rendimiento.

Lectura y Escritura de Datos con N1QL

Con N1QL, ahora entramos en la consulta tradicional de datos. SELECT this FROM that WHERE this = 'cosas que sabemos' JOIN con esa otra cosa. Si el acceso a través de ID de objeto es la bestia en la habitación, entonces este es un poderoso Asistente.

N1QL, junto con los Servicios de Consultas e Índices que lo impulsan, te da la mayor flexibilidad para acceder a tus datos en Couchbase a la vez que es eficiente y escalable a través de servicios gestionados de forma independiente. Si necesitas hacer análisis, consultas complejas, comparar datos, etc., entonces N1QL es lo que estás buscando. En la analogía de estar en una biblioteca y necesitar un libro, consultar con N1QL es el bibliotecario que consigue los libros que satisfacen los datos que tienes. "Por favor, consígueme todo lo que haya en la biblioteca del autor Neil Gaiman que haya sido escrito entre 1998 y 2014 y sean libros o novelas gráficas". Esto cambia bastante el tipo de funcionalidades de las aplicaciones para las que se puede usar Couchbase.

Lo bueno de los SDKs de cliente de Couchbase es que sólo tienes que utilizar un método diferente para realizar la consulta y el SDK se encarga de la comunicación con los servicios apropiados. Aparte de eso, no tienes que hacer nada extra. En tu aplicación, la primera llamada puede ser una consulta N1QL compleja con uniones y la siguiente es utilizar los resultados de la consulta para llamar a una vista map reduce para obtener una agregación precalculada. Este es otro ejemplo de cómo usar la herramienta adecuada para el trabajo adecuado tiene sentido y te da opciones.

Ahora que hemos establecido el poder y la flexibilidad, hay otras herramientas que puedes incorporar con el servicio de Consulta. Couchbase se ha asociado con Simba Technologies para crear drivers ODBC y JDBC para el acceso a datos. Esto te permite utilizar Excel o herramientas BI más complejas como Pentaho, Informatica, etc.

Pros:

• Muy flexible para consultar datos de la base de datos y obtener las respuestas que necesita.
• Los índices se encuentran únicamente en los nodos que dan servicio a los nodos de índice y no repartidos por todo el clúster.
• Puede utilizar el escalado multidimensional (MDS) para escalar sólo los servicios que necesita para obtener el rendimiento requerido para su aplicación.
• Los desarrolladores que conocen SQL pueden pasar fácilmente a escribir N1QL
• Controladores ODBC y JDBC para la integración con herramientas de BI

Contras:

• Las consultas nunca tendrán el mismo rendimiento que el acceso a los datos a través del ID de objeto, por las razones que ya he explicado.
• Eventualmente consistente por defecto, pero se puede consultar con stale=false para actualizar inmediatamente el índice, pero con un impacto en el rendimiento. Sin embargo, para la mayoría de las cargas de trabajo, el índice se actualiza lo más rápido posible en segundo plano y la consistencia debería estar bien.

Búsqueda de texto completo con Solr o Elastic

Couchbase se integra con Solr y Elastic (Búsqueda) a través de plugins para proporcionar capacidades de búsqueda de texto completo que Couchbase carece, por el momento. Si tienes un requerimiento funcional para esto, cada uno tiene un plugin que permite que cada operación de escritura/actualización sea transmitida a Solr y/o Elastic. Por defecto, estos servidores de búsqueda no guardan el documento JSON completo, sino que se limitan a crear los componentes internos (índices, etc.) necesarios para permitir la búsqueda de texto completo. Una vez que los documentos son buscables, tu aplicación haría referencia a esas herramientas cuando necesites esa funcionalidad, obtendría los resultados de la búsqueda y, si fuera necesario, leería el documento o documentos completos desde Couchbase. Esto te permite utilizar cada herramienta para lo que son mejores y obtener el mejor rendimiento de cada una.

Pros:

• Capacidad de búsqueda de texto completo
• La aplicación no necesita hacer escrituras duales, escribe en Couchbase y desde allí la escritura se replica automáticamente en Elastic/Solr para su indexación.
• Cada sistema puede escalarse para gestionar el trabajo que necesita

Contras:

• Debe mantener una infraestructura independiente para Solr o Elastic.
• Eventualmente consistente
• No está totalmente integrado en el clúster Couchbase
• No está integrado en el SDK de Couchbase, por lo que tu aplicación tendrá que hablar con uno de ellos y Couchbase

Te preguntarás: "¿Por qué no usar Solr o Elastic y saltarnos Couchbase por completo?". La razón es simple: aunque ambos son geniales para lo que hacen, ni Solr ni Elastic son bases de datos y ninguno tiene el rendimiento u otras potentes capacidades de Couchbase. Pruébalo tú mismo y verás que ambos pueden ser al menos 2-3 veces más lentos que obtener los mismos datos de Couchbase.

Resumen

Dependiendo de cómo necesites acceder a los datos en Couchbase, así como de las necesidades funcionales y de rendimiento que tu aplicación necesite de Couchbase, puedes mezclar y combinar las herramientas que he descrito para obtener los resultados que necesitas. Si necesitas velocidad bruta y/o consistencia total, opta por el acceso mediante ID de objeto y un patrón de clave estandarizado. Si necesita hacer preguntas a los datos, utilice vistas, N1QL o búsqueda de texto completo. Si necesita obtener un montón de documentos y actualizarlos rápidamente, combine vistas con acceso mediante ID de objeto.

La otra gran cosa es que los métodos de acceso #1-3 están todos incorporados en los SDKs de Couchbase, con el "cómo cada uno hace su magia" ofuscado de tu aplicación. Esto te permite no sólo combinar todos estos patrones de acceso para trabajar juntos, sino desarrollar con agilidad con todas las características contra un solo nodo de Couchbase en tu portátil, pero luego operar con ese mismo código a cualquier escala en un clúster. Así que si tienes 3 nodos u 80 nodos de Couchbase en tu clúster, tu aplicación está lista para escalar con cero cambios de código para facilitar eso.