Plataforma de bases de datos de compromiso Couchbase
¡¡¡Woo-Hoo!!! ¿Has oído hablar de Bases de datos de compromisos? Estoy seguro, "No", no hasta que Anuncio de Couchbase con la versión 5.0. En la economía digital de hoy en día, el éxito de una empresa depende de su capacidad para aprovechar la transformación digital con éxito para proporcionar un compromiso y una experiencia del cliente superiores. El ADN de todo esto reside en los datos, y eso requiere una potente plataforma de base de datos que pueda abordar los problemas de datos en los sistemas de compromiso a escala, con facilidad y en las raíces. Estos problemas son bastante únicos y, por lo tanto, las soluciones también deberían serlo. La comprensión superior de los problemas en este espacio y las soluciones elegantes y eficientes a esos problemas llevaron al descubrimiento de una nueva categoría de bases de datos, que llamamos Bases de datos de compromisos. Una base de datos de este tipo es complementaria a las bases de datos transaccionales y analíticas que pueda tener en su infraestructura de tejido de datos. La siguiente imagen muestra cómo encajan.
N1QLes el lenguaje de consulta SQL extendido diseñado para permitir que sus aplicaciones aprovechen el poder de las bases de datos de compromiso y JSON. N1QL tiene toda la sofisticación necesaria para tratar con esquemas flexibles y datos JSON estructurados jerárquicamente. Usted puede escribir consultas declarativas simples usando N1QL para tratar naturalmente con tales datos.
Couchbase 5.0 aporta una serie de funcionalidades de consulta enriquecidas y optimizaciones de rendimiento en N1QL para satisfacer las demandas de las aplicaciones centradas en el compromiso del cliente. Muchas de las mejoras de funcionalidad y rendimiento también incluyen las correspondientes mejoras en los índices GSI para ayudar a N1QL a aprovechar al máximo las optimizaciones. Véase Novedades de Couchbase Server 5.0 para ver la lista completa y los detalles.
Índices adaptativos
Los índices adaptativos son un tipo especial de índices en Couchbase que pueden indexar todos o un conjunto de campos específicos de un documento de forma extremadamente adaptable. A diferencia de los índices GSI compuestos, un índice de este tipo es genérico por naturaleza. Me explico... Los índices adaptativos pueden buscar eficientemente cualquiera de los valores de la clave del índice sin restricciones tales como el orden prefijo de la clave del índice, en índices compuestos típicos. Esto permite consultas de búsqueda ad-hoc eficientes que pueden utilizar predicados de cláusula WHERE en campos arbitrarios sin necesidad de crear múltiples índices compuestos o diferentes combinaciones de claves de índice.
Por ejemplo, consideremos un caso de uso de perfil de usuario. Puede ser necesario buscar en el perfil de una persona en función de atributos personales como el nombre, los apellidos, la edad, la ciudad, la dirección, el trabajo, el cargo, la empresa, la hoja de servicios, etc. Del mismo modo, la disponibilidad de una habitación de hotel puede buscarse basándose en criterios amplios, como las instalaciones de la habitación, las comodidades, el precio, la ubicación, la distancia a puntos de interés específicos, etc. En estos casos, los índices compuestos secundarios tradicionales no pueden utilizarse eficazmente (véase la sección Contraste con los índices compuestos para entender los problemas). Los índices adaptativos resuelven este problema creando un índice genérico que puede ejecutar esas consultas de búsqueda ad hoc con eficacia y eficiencia.
Por ejemplo, la siguiente figura(1) muestra cómo se necesitan tres índices diferentes I1, I2, I3 para las 3 consultas Q1, Q2, Q3. Además, no es posible realizar una consulta sobre cualquier otro campo no indexado sin crear los índices correspondientes. Además, una consulta sólo sobre la edad, como Q4, no podrá utilizar el índice I2, ya que también necesita el prefijo id de la clave del índice. La figura (2) muestra cómo un único índice adaptativo puede ayudar a realizar consultas en todos los campos, independientemente del orden de la clave del índice.
Tenga en cuenta que los índices adaptativos no son la panacea. Estas cifras pueden dar la impresión de que los índices adaptativos son mejores que los índices simples/compuestos. No es del todo cierto. Si conoce las consultas (y las claves de índice) a priori, siempre es mejor utilizar índices secundarios normales. Porque serían más rápidos que los índices adaptativos. Recuerde que los índices adaptativos pueden tener un tamaño mucho mayor, ya que indexan múltiples/todas las claves de índice y los valores correspondientes. Por lo tanto, puede que no sean tan rápidos como los índices secundarios simples. Sin embargo, los índices adaptativos resuelven los problemas que los índices secundarios no pueden con poca sobrecarga.
En la vida hay que hacer concesiones. Para más detalles y ejemplos, consulte el Índice adaptativo documentación.
Potentes expresiones de subconsulta
N1QL es un potente lenguaje de consulta. Es SQL para JSON, y tiene todas las extensiones del lenguaje y expresiones necesarias para hacer frente a muchas sutilezas en el modelado de datos JSON, tales como:
- Esquema flexible
- Faltan campos y valores de datos.
- Matriz de valores múltiples
- Datos anidados en los que un campo de un documento puede ser otro objeto JSON completamente formado.
Este tipo de cosas no existen en las bases de datos relacionales, y por lo tanto SQL no tiene que lidiar con ello. Sin embargo, por diseño, N1QL está obligado a abordar todos los matices en el trabajo con datos JSON. De hecho, estas son el tipo de características complejas de los datos y la flexibilidad, y la escalabilidad, y la simplicidad, que ha gravitado aplicaciones de hoy en día a una plataforma de base de datos de compromiso como Couchbase.
Una de estas funcionalidades para simplificar elegantemente el trabajo con datos de arreglos es el soporte de N1QL para expresiones de Subconsulta en Arreglos. Esto le permite tratar un arreglo como un espacio de llaves de documentos, y le permite usar todo el poder de N1QL en el arreglo tratando los elementos del arreglo como documentos del espacio de llaves. Puede que no te des cuenta, pero eso es mucho más poderoso que como se lee ;-)
Por ejemplo, considere los siguientes datos de pedidos de clientes:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "type": "order", "customerId": "Prasad_4444", "order_number": "12345", "products": [ { "productId": "prod1", "quantity": 1, "price": 39.99 }, { "productId": "prod2", "quantity": 2, "price": 49.99 } ] } |
Aquí, el campo de matriz productos[] contiene los detalles del pedido de todos los productos solicitados. Ahora, vamos a intentar escribir una consulta para encontrar el valor total del pedido. La consulta debe recorrer cada elemento de la tabla productos[] y calcular la suma de cantidad * precio. Sin utilizar esta función (por ejemplo, cuando se utiliza Couchbase 4.5), la consulta tendría el siguiente aspecto:
|
1 2 3 4 5 6 7 8 |
SELECT d1.customerId, ((SELECT RAW SUM(d2u.price * d2u.quantity) FROM default d2 USE KEYS meta(d1).id UNNEST d2.products d2u WHERE d2.customerId = d1.customerId GROUP BY meta(d2).id))[0] AS total FROM default d1 ; |
Esta consulta es posible gracias a la maravillosa cláusula UNNEST en la sentencia SELECT de N1QL. Sin embargo, la misma consulta puede ser reescrita como abajo, usando la Expresión de Subconsulta en Arrays:
|
1 2 3 4 |
SELECT customerId, (SELECT RAW SUM(p.price * p.quantity) FROM d.products AS p)[0] AS total FROM default AS d; |
¡¡No es ridículamente simple e intuitivo!! De hecho, también funcionaría mejor. Así es como N1QL empodera a los desarrolladores de aplicaciones, y una Base de Datos de Compromiso permite a los clientes abordar sus retos de datos en aplicaciones de Sistemas de Compromiso. Hay mucho más que hablar sobre esta maravillosa característica.. Ver documentación y esto blog.
Por cierto, imagina modelar estos datos simples con un RDBMS y escribir una consulta equivalente en SQL, u otra base de datos NoSql. ¡Estoy seguro de que puede ser un problema divertido de resolver si quieres perder tu fin de semana!
Acceso a datos externos y consultas federadas
Uno de los problemas de la explosión de datos es que las aplicaciones de captación de clientes pueden necesitar encontrar e integrar datos relevantes de múltiples fuentes internas y externas. Cada vez es más importante que las aplicaciones centradas en los datos los combinen con fuentes de datos externas:
-
Proveedores de servicios de datos como API de geocodificación de Googleo API de Yahoo etc.
-
Proveedores de datos como www.data.gov
-
Micro servicios como Couchbase Full Text Search, otros Clusters de Couchbase, o cualquier otra fuente de datos que pueda proporcionar datos JSON.
Couchbase Server 5.0 añade una nueva función N1QL CURL(), que permite a las consultas N1QL interactuar e integrarse con fuentes de datos JSON externas disponibles sobre HTTP/REST. Esto permite consultas N1QL federadas contra fuentes de datos externas. Por ejemplo:
-
Puede acceder a la API de geocodificación de Google para obtener más detalles sobre una ubicación determinada almacenada en su base de datos.
|
1 2 3 4 5 |
SELECT CURL("https://maps.googleapis.com/maps/api/geocode/json", { "data":["address=santa+cruz","components=country:ES"], "get":true }); |
-
Puede utilizar la API de datos financieros de Yahoo para obtener más detalles sobre un determinado símbolo bursátil almacenado en su base de datos.
|
1 2 3 4 5 6 |
SELECT meta().id, to_number(hdp_low) AS hdp_low FROM bucket_name LET hdp_low = curl("https://query.yahooapis.com/v1/public/yql", {"data":"q=select%20*%20from%20yahoo.finance.quotes%20where%20symbol%20in%20(%22HDP%22)&format=json&diagnostics=true&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&callback=" }).query.results.quote.DaysLow WHERE to_number(hdp_low) < $min_threshold; |
De forma similar, puedes usar índices FTS en tu consulta N1QL para búsquedas de texto completo, o acceder a datos de otros Clusters Couchbase u otras fuentes de datos JSON en tus consultas N1QL (usando todo el poder de las expresiones N1QL en los datos externos). Para más información, consulta Función CURL.
RBAC para Declaraciones N1QL
El Control de Acceso Basado en Roles (RBAC) es vital para la administración de la seguridad en los despliegues empresariales. Couchbase Server 5.0 incorpora RBAC para aplicaciones mediante el cual se pueden añadir usuarios al sistema con varios roles predefinidos. El servicio de consulta añade soporte para RBAC con las siguientes características principales:
-
Se añaden roles a nivel de sentencia para ejecutar varias sentencias N1QL como SELECT, UPDATE, INSERT, y para acceder a los espacios de claves del sistema.
-
Se añaden las nuevas sentencias N1QL GRANT y REVOKE alineadas con el estándar SQL.
-
Se añaden los nuevos espacios clave del sistema user_info, my_user_info y applicable_roles para acceder a los detalles de la asignación de roles.
Más información aquí.
Supervisión y elaboración de perfiles de consultas N1QL
Esta función permite realizar un seguimiento y un perfil detallados de las consultas. Esto proporciona información detallada sobre varias fases de consulta, operadores de consulta implicados en el procesamiento de la consulta, y tiempos y características de ejecución correspondientes (como resultados intermedios). Toda la información de supervisión también se captura en varios espacios clave del sistema, como system:active_requests y system:completed_requests. Esto ayuda a diagnosticar consultas problemáticas y problemas de rendimiento. La siguiente imagen muestra el plan visual y los detalles del perfil de consulta en el banco de trabajo de consultas.
Se proporcionan nuevos parámetros de consulta para activar, desactivar y controlar las capacidades de supervisión, y pueden configurarse para un motor de consulta o para consultas individuales. Véase Supervisión de las consultas N1QL para más detalles.
Mejoras en el rendimiento de N1QL
En Couchbase Server 5.0, N1QL y los Índices Secundarios Globales juntos permiten muchas optimizaciones de rendimiento.
-
Despliegue de predicados complejos: Soporta el pushdown eficiente y exacto de predicados complejos AND/OR al índice. Esto ayuda en:
-
evitar resultados espurios del Indexador en determinadas consultas en las que los predicados tienen exploraciones de rango en claves de índice prefijadas.
-
utilizar eficazmente varios índices para diferentes condiciones de un predicado OR, etc.
-
-
Proyección de Índices: En la versión 5.0, N1QL añade soporte para solicitar sólo la información necesaria a Index, y así evitar cualquier procesamiento innecesario.
-
Se añade soporte para crear índices con ASC/DESC especificado para claves de índice individuales, y aprovechar el orden de índice para consultas con cláusula ORDER BY alineada.
-
Operadores como OFFSET, MAX(), MIN(), DISTINCT, COUNT (campo DISTINCT) son empujados hacia abajo al indexador.
Para más información, consulte Optimización de la compresión de índices.
Resumen
Estoy seguro de que esto es bastante emocionante y abrumador. Estamos muy contentos de compartir nuestra visión sobre las bases de datos de compromiso e innovar N1QL para ayudarte a prepararte. En este artículo hablamos de muchas mejoras en las características y rendimiento de N1QL en la Plataforma de Bases de Datos de Compromiso Couchbase Server 5.0. Escríbenos si tienes algún comentario o pregunta. ¡Saludos!