Las expectativas de los clientes y las correspondientes exigencias sobre las aplicaciones nunca han sido tan altas. Los usuarios esperan que las aplicaciones sean rápidas, confiables y estén disponibles. Además, los datos son los reyes y los usuarios quieren poder dividir los datos agregados según sea necesario para encontrar información valiosa. Los usuarios no quieren esperar a que los ingenieros de datos proporcionen nuevos índices o creen nuevas cadenas ETL. Quieren acceso ilimitado a los datos más recientes disponibles. Pero manejar todas las necesidades de su aplicación es una tarea ardua para cualquier base de datos. Para la base de datos, optimizar operaciones frecuentes y de baja latencia en registros individuales es diferente de optimizar agregaciones menos frecuentes o filtrado intenso en muchos registros. Muchas veces, intentamos manejar ambos patrones con la misma base de datos y lidiar con el rendimiento inconsistente a medida que nuestra aplicación escala. Creemos que estamos optimizando con un esfuerzo o costo mínimo, cuando en realidad estamos haciendo lo contrario. La ejecución de análisis en una base de datos OLTP generalmente requiere que aprovisionemos en exceso una base de datos para tener en cuenta los picos de tráfico. Esto termina costando mucho dinero y generalmente no brinda una experiencia agradable al usuario final. En este tutorial, veremos cómo manejar las altas demandas de los usuarios con ambos patrones de acceso. Crearemos una aplicación financiera en la que los usuarios registrarán transacciones y verán transacciones recientes y al mismo tiempo querrán filtros complejos o agregaciones de sus transacciones pasadas. Un enfoque híbrido Para manejar las necesidades de nuestra aplicación, usaremos con . DynamoDB manejará nuestros patrones principales de acceso a transacciones: registrará las transacciones y proporcionará una fuente de transacciones recientes para que los usuarios exploren. Rockset complementará DynamoDB para manejar nuestros patrones de acceso "encantadores" y con gran cantidad de datos. Permitiremos que nuestros usuarios filtren por tiempo, comerciante, categoría u otros campos para encontrar las transacciones relevantes o realizar agregaciones poderosas para ver las tendencias en el gasto a lo largo del tiempo. Amazon DynamoDB Rockset A medida que analicemos estos patrones, veremos cómo cada uno de estos sistemas se adapta al trabajo en cuestión. DynamoDB se destaca en las operaciones centrales de OLTP: leer o escribir un elemento individual o recuperar una variedad de elementos secuenciales basados en filtros conocidos. Debido a la forma en que divide los datos según la clave principal, DynamoDB puede proporcionar un rendimiento consistente para este tipo de consultas a cualquier escala. Por el contrario, Rockset se destaca en la ingesta continua de grandes cantidades de datos y en el empleo de múltiples estrategias de indexación en esos datos para proporcionar filtrado altamente selectivo, agregaciones en tiempo real o en tiempo de consulta y otros patrones que DynamoDB no puede manejar fácilmente. A medida que trabajamos en este ejemplo, aprenderemos tanto los conceptos fundamentales que subyacen a los dos sistemas como los pasos prácticos para lograr nuestros objetivos. Puede seguir la aplicación utilizando el . repositorio de GitHub Implementación de funciones principales con DynamoDB Comenzaremos este tutorial implementando las funciones principales de nuestra aplicación. Este es un punto de partida común para cualquier aplicación, a medida que crea las operaciones "CRUDL" estándar para brindar la capacidad de manipular registros individuales y enumerar un conjunto de registros relacionados. Para una aplicación de comercio electrónico, esta sería la funcionalidad para realizar un pedido y ver pedidos anteriores. Para una aplicación de redes sociales, esto sería crear publicaciones, agregar amigos o ver a las personas que sigues. Esta funcionalidad generalmente la implementan bases de datos que se especializan en flujos de trabajo que enfatizan muchas operaciones simultáneas en una pequeña cantidad de filas. de procesamiento transaccional en línea (OLTP) Para este ejemplo, estamos creando una aplicación de finanzas comerciales donde un usuario puede realizar y recibir pagos, así como ver el historial de sus transacciones. El ejemplo se simplificará intencionalmente para este tutorial, pero puede pensar en tres patrones de acceso principales para nuestra aplicación: , que almacenará un registro de un pago realizado o recibido por la empresa; Registro de transacción , lo que permitirá a los usuarios ver los pagos más recientes realizados y recibidos por una empresa; y Ver transacciones por rango de fechas , lo que permitirá al usuario profundizar en los detalles de una sola transacción. Ver transacción individual Cada uno de estos patrones de acceso es un patrón de acceso crítico y de gran volumen. Registraremos constantemente las transacciones de los usuarios y el feed de transacciones será la primera vista cuando abran la aplicación. Además, cada uno de estos patrones de acceso utilizará parámetros conocidos y consistentes para recuperar los registros relevantes. Usaremos DynamoDB para manejar estos patrones de acceso. DynamoDB es una base de datos NoSQL proporcionada por AWS. Es una base de datos totalmente administrada y tiene una popularidad creciente tanto en aplicaciones de alta escala como en aplicaciones sin servidor. Una de las características más exclusivas de DynamoDB es cómo proporciona un rendimiento constante a cualquier escala. Ya sea que su tabla sea de 1 megabyte o 1 petabyte, debería ver el mismo tiempo de respuesta para sus operaciones. Esta es una cualidad deseable para casos de uso básicos de OLTP como los que estamos implementando aquí. Este es un gran y valioso logro de ingeniería, pero es importante comprender que se logró siendo selectivo sobre los tipos de consultas que funcionarán bien. DynamoDB puede proporcionar este rendimiento consistente a través de dos decisiones de diseño centrales. Primero, cada registro de su tabla de DynamoDB debe incluir una clave principal. Esta clave principal se compone de una clave de partición y una clave de clasificación opcional. La segunda decisión de diseño clave para DynamoDB es que la API exige en gran medida el uso de la clave principal; hablaremos más sobre esto más adelante. En la imagen a continuación, tenemos algunos datos de transacciones de muestra en nuestra aplicación FinTech. Nuestra tabla utiliza una clave de partición del nombre de la organización en nuestra aplicación, además de una clave de clasificación basada en que proporciona las características de unicidad de un UUID más la capacidad de clasificación por tiempo de creación que nos permite realizar consultas basadas en el tiempo. ULID Los registros de nuestra tabla incluyen otros atributos, como nombre del comerciante, categoría y monto, que son útiles en nuestra aplicación pero que no son tan críticos para la arquitectura subyacente de DynamoDB. La parte importante está en la clave principal, y específicamente en la clave de partición. Básicamente, DynamoDB dividirá sus datos en múltiples particiones de almacenamiento, cada una de las cuales contendrá un subconjunto de los datos de su tabla. DynamoDB utiliza el elemento de clave de partición de la clave principal para asignar un registro determinado a una partición de almacenamiento particular. A medida que aumenta la cantidad de datos en su tabla o el tráfico en su tabla, DynamoDB agregará particiones como una forma de escalar horizontalmente su base de datos. Como se mencionó anteriormente, la segunda decisión de diseño clave para DynamoDB es que la API exige en gran medida el uso de la clave principal. Casi todas las acciones de API en DynamoDB requieren al menos la clave de partición de su clave principal. Debido a esto, DynamoDB puede enrutar rápidamente cualquier solicitud a la partición de almacenamiento adecuada, sin importar la cantidad de particiones y el tamaño total de la tabla. Con estas dos compensaciones, necesariamente existen limitaciones en la forma de utilizar DynamoDB. Debe planificar y diseñar cuidadosamente sus patrones de acceso desde el principio, ya que su clave principal debe estar involucrada en sus patrones de acceso. Cambiar sus patrones de acceso más adelante puede resultar difícil y puede requerir algunos pasos de migración manual. Cuando sus casos de uso estén dentro de las competencias principales de DynamoDB, obtendrá los beneficios. Recibirá un rendimiento constante y predecible sin importar la escala y no verá una degradación a largo plazo de su aplicación con el tiempo. Además, obtendrá una experiencia totalmente administrada con una carga operativa baja, lo que le permitirá concentrarse en lo que es importante para el negocio. Las operaciones centrales de nuestro ejemplo encajan perfectamente con este modelo. Al recuperar una fuente de transacciones para una organización, tendremos el ID de la organización disponible en nuestra aplicación que nos permitirá usar la operación de DynamoDB para recuperar un conjunto contiguo de registros con la misma clave de partición. Para recuperar detalles adicionales sobre una transacción específica, tendremos disponibles el ID de la organización y el ID de la transacción para realizar una solicitud de DynamoDB para recuperar el artículo deseado. de consulta GetItem Puede ver estas operaciones en acción con la . Siga las instrucciones para implementar la aplicación y inicializarla con datos de muestra. Luego, realice solicitudes HTTP al servicio implementado para recuperar el feed de transacciones de usuarios individuales. Estas operaciones serán rápidas y eficientes independientemente del número de solicitudes simultáneas o del tamaño de su tabla de DynamoDB. aplicación de muestra Complementando DynamoDB con Rockset Hasta ahora, hemos utilizado DynamoDB para manejar nuestros patrones de acceso principales. DynamoDB es excelente para estos patrones ya que su partición basada en claves proporcionará un rendimiento consistente a cualquier escala. Sin embargo, DynamoDB no es muy bueno manejando otros patrones de acceso. DynamoDB no le permite realizar consultas de manera eficiente por atributos distintos de la clave principal. Puede utilizar para volver a indexar sus datos mediante atributos adicionales, pero aún así puede resultar problemático si tiene muchos atributos diferentes que pueden usarse para indexar sus datos. los índices secundarios de DynamoDB Además, DynamoDB no proporciona ninguna funcionalidad de agregación lista para usar. Puede calcular sus propios agregados utilizando DynamoDB, pero puede ser con una flexibilidad reducida o con un consumo de lectura no optimizado en comparación con una solución que diseña para la agregación por adelantado. Para manejar estos patrones, . complementaremos DynamoDB con Rockset Es mejor considerar a Rockset como un conjunto secundario de índices de sus datos. Rockset usa solo estos índices en el momento de la consulta y no proyecta ninguna carga en DynamoDB durante una lectura. En lugar de actualizaciones transaccionales individuales de sus clientes de aplicaciones, Rockset está diseñado para la ingesta continua y en streaming desde su almacén de datos principal. Tiene conectores directos para varios almacenes de datos primarios, incluidos DynamoDB, MongoDB, Kafka y muchas bases de datos relacionales. A medida que Rockset ingiere datos de su base de datos principal, luego los indexa en un , que toma prestados conceptos de: un índice de filas, un índice invertido y un índice de columnas. Se crean automáticamente índices adicionales, como rango, tipo y geoespacial, en función de los tipos de datos ingeridos. Discutiremos los detalles de estos índices a continuación, pero este índice convergente permite patrones de acceso más flexibles a sus datos. índice convergente Este es el concepto central detrás de Rockset: es un índice secundario de sus datos que utiliza una canalización de ingesta casi en tiempo real y totalmente administrada desde su almacén de datos principal. Los equipos llevan mucho tiempo extrayendo datos de DynamoDB para insertarlos en otro sistema y manejar casos de uso adicionales. Antes de pasar a los detalles de cómo Rockset ingiere datos de su tabla, analicemos brevemente en qué se diferencia Rockset de otras opciones en este espacio. Existen algunas diferencias fundamentales entre Rockset y otros enfoques. En primer lugar, Rockset está totalmente gestionado. No solo no es necesario que administre la infraestructura de la base de datos, sino que tampoco necesita mantener la canalización para extraer, transformar y cargar datos en Rockset. Con muchas otras soluciones, usted está a cargo del código "pegamento" entre sus sistemas. Estos sistemas son críticos pero propensos a fallar, ya que debe protegerse defensivamente contra cualquier cambio en la estructura de datos. Los cambios ascendentes pueden resultar en problemas para quienes mantienen estos sistemas. En segundo lugar, Rockset puede manejar datos en tiempo real de forma mutable. Con muchos otros sistemas, obtienes uno u otro. Puede optar por realizar exportaciones periódicas y cargas masivas de sus datos, pero esto da como resultado datos obsoletos entre cargas. Alternativamente, puede transmitir datos a su almacén de datos en forma de solo anexos, pero no puede realizar actualizaciones in situ sobre los datos cambiantes. Rockset puede manejar actualizaciones de elementos existentes con la misma rapidez y eficiencia que inserta datos nuevos y, por lo tanto, puede brindarle una visión en tiempo real de sus datos cambiantes. En tercer lugar, Rockset genera sus índices automáticamente. Otras soluciones "totalmente administradas" aún requieren que usted configure índices a medida que los necesita para admitir nuevas consultas. El motor de consultas de Rockset está diseñado para utilizar un conjunto de índices para admitir todas y cada una de las consultas. A medida que agrega más y más consultas a su sistema, no necesita agregar índices adicionales, lo que ocupa cada vez más espacio y recursos computacionales. Esto también significa que las consultas ad hoc también pueden aprovechar al máximo los índices, haciéndolos más rápidos sin tener que esperar a que un administrador agregue un índice personalizado para respaldarlos. Cómo Rockset ingiere datos de DynamoDB Ahora que conocemos los conceptos básicos de qué es Rockset y cómo nos ayuda, conectemos nuestra tabla de DynamoDB a Rockset. Al hacerlo, aprenderemos cómo funciona el proceso de ingesta de Rockset y en qué se diferencia de otras opciones. Rockset tiene conectores especialmente diseñados para varias fuentes de datos, y la implementación específica del conector depende de las características específicas de la fuente de datos ascendente. Para conectarse con DynamoDB, Rockset confía en . DynamoDB Streams es una función de captura de datos modificados de DynamoDB donde los detalles de cada operación de escritura en una tabla de DynamoDB se registran en la secuencia. Los consumidores de la transmisión pueden procesar estos cambios en el mismo orden en que ocurrieron en la tabla para actualizar los sistemas posteriores. DynamoDB Streams Una transmisión de DynamoDB es excelente para que Rockset se mantenga actualizado con una tabla de DynamoDB casi en tiempo real, pero no es la historia completa. Una secuencia de DynamoDB solo contiene registros de operaciones de escritura que ocurrieron después de que se habilitó la secuencia en la tabla. Además, un . Las operaciones que ocurrieron antes de que se habilitara la transmisión o hace más de 24 horas no estarán presentes en la transmisión. flujo de DynamoDB conserva registros solo durante 24 horas Pero Rockset necesita no sólo los datos más recientes, sino todos los datos de su base de datos para poder responder sus consultas correctamente. Para manejar esto, realiza una exportación masiva inicial (usando un escaneo de DynamoDB o , dependiendo del tamaño de su tabla) para capturar el estado inicial de su tabla. una exportación a S3 Así, el proceso de conexión de DynamoDB de Rockset tiene dos partes: Un proceso inicial para exportar su tabla completa para su ingesta en Rockset; de arranque Un proceso posterior y para consumir actualizaciones de su DynamoDB Stream y actualizar los datos en Rockset. continuo Tenga en cuenta que ambos procesos están totalmente administrados por Rockset y son transparentes para usted como usuario. No estará a cargo de mantener estas canalizaciones ni de responder a las alertas si hay un error. Además, si elige el método de exportación S3 para el proceso de ingesta inicial, ninguno de los procesos de ingesta de Rockset consumirá unidades de capacidad de lectura de su tabla principal. Por lo tanto, Rockset no consumirá los casos de uso de su aplicación ni afectará la disponibilidad de producción. Aplicación: Conexión de DynamoDB a Rockset Antes de continuar con el uso de Rockset en nuestra aplicación, conectemos Rockset a nuestra tabla de DynamoDB. Primero, necesitamos crear una nueva integración entre Rockset y nuestra mesa. Revisaremos los pasos de alto nivel a continuación, pero puede encontrar si es necesario. instrucciones paso a paso más detalladas en el repositorio de aplicaciones En la consola de Rockset, navegue hasta el para iniciar este proceso. nuevo asistente de integración En el asistente de integración, elija como su tipo de integración. Luego, haga clic en para pasar al siguiente paso. Amazon DynamoDB Iniciar El asistente de integración de DynamoDB tiene instrucciones paso a paso para autorizar a Rockset a acceder a su tabla de DynamoDB. Esto requiere la creación de una política de IAM, una función de IAM y un depósito de S3 para la exportación de su tabla. Puede seguir esas instrucciones para crear los recursos manualmente si lo prefiere. En el mundo sin servidores, preferimos crear cosas a través de tanto como sea posible, y eso incluye estos recursos de soporte. infraestructura como código El repositorio de ejemplo incluye la infraestructura como código necesaria para crear los recursos de integración de Rockset. Para usarlos, primero busque los valores de ID de cuenta de Rockset y de ID externo en la parte inferior del asistente de integración de Rockset. Copie y pegue estos valores en las bloque del archivo serverless.yml. Luego, para crear estos recursos. secciones relevantes del custom descomente los recursos en las líneas 71 a 122 de serverless.yml Vuelva a implementar su aplicación para crear estos nuevos recursos. En los resultados de la implementación, copie y pegue el nombre del depósito S3 y el ARN del rol de IAM en los lugares apropiados de la consola de Rockset. Luego, haga clic en el botón Guardar integración para guardar su integración. Una vez que haya creado su integración, deberá crear una a partir de la integración. Navegue hasta el en la consola de Rockset y siga los pasos para usar su integración para crear una colección. También puede encontrar en el repositorio de la aplicación. colección Rockset asistente de creación de colecciones instrucciones paso a paso para crear una colección Una vez que haya completado esta conexión, generalmente, en un conjunto de instancias del tamaño adecuado, las inserciones, actualizaciones o eliminaciones de datos en DynamoDB se reflejarán en el índice de Rockset y estarán disponibles para consultas en menos de 2 segundos. Uso de Rockset para filtrado complejo Ahora que hemos conectado Rockset a nuestra tabla de DynamoDB, veamos cómo Rockset puede habilitar nuevos patrones de acceso a nuestros datos existentes. Recuerde de nuestra sección de funciones principales que DynamoDB se centra en gran medida en sus claves principales. Debe utilizar su clave principal para acceder de manera eficiente a sus datos. En consecuencia, estructuramos nuestra tabla para usar el nombre de la organización y el tiempo de la transacción en nuestras claves principales. Esta estructura funciona para nuestros patrones de acceso principales, pero es posible que queramos proporcionar una forma más flexible para que los usuarios exploren sus transacciones. Hay una serie de atributos útiles (categoría, nombre del comerciante, monto, etc.) que pueden resultar útiles para el filtrado. Podríamos usar los índices secundarios de DynamoDB para permitir el filtrado de más atributos, pero eso todavía no encaja bien aquí. La estructura de clave principal de DynamoDB no permite fácilmente consultas flexibles que impliquen combinaciones de muchos atributos opcionales. Podría tener un índice secundario para filtrar por nombre del comerciante y fecha, pero necesitaría otro índice secundario si quisiera permitir el filtrado por nombre del comerciante, fecha y monto. Un patrón de acceso que filtre por categoría requeriría un tercer índice secundario. En lugar de lidiar con esa complejidad, aquí nos apoyaremos en Rockset. Vimos antes que Rockset utiliza un índice convergente para indexar sus datos de múltiples maneras. Una de esas formas es un índice invertido. Con un índice invertido, Rockset indexa cada atributo directamente. Observe cómo está organizado este índice. Cada nombre y valor de atributo se utiliza como clave del índice, y el valor es una lista de ID de documento que incluyen el nombre y valor del atributo correspondiente. Las claves están construidas de modo que su orden de clasificación natural pueda admitir consultas de rango de manera eficiente. Un índice invertido es excelente para consultas que tienen condiciones de filtro selectivo. Imaginemos que queremos permitir a nuestros usuarios filtrar sus transacciones para encontrar aquellas que coincidan con ciertos criterios. Alguien en la organización de Vandelay Industries está interesado en saber cuántas veces ha pedido Chipotle recientemente. Puede encontrar esto con una consulta de la siguiente manera: SELECT * FROM transactions WHERE organization = 'Vandelay Industries' AND merchant_name = 'Chipotle' Debido a que estamos realizando filtros selectivos en el nombre del cliente y del comerciante, podemos usar el índice invertido para encontrar rápidamente los documentos coincidentes. Rockset buscará pares de nombre y valor de atributo en el índice invertido para encontrar las listas de documentos coincidentes. Una vez que tenga estas dos listas, puede fusionarlas para encontrar el conjunto de registros que coincidan con ambos conjuntos de condiciones y devolver los resultados al cliente. Así como la indexación basada en particiones de DynamoDB es eficiente para operaciones que usan la clave de partición, el índice invertido de Rockset le brinda búsquedas eficientes en cualquier campo de su conjunto de datos, incluso en atributos de objetos incrustados o en valores dentro de matrices incrustadas. Aplicación: uso de la API de Rockset en su aplicación Ahora que sabemos cómo Rockset puede ejecutar consultas selectivas de manera eficiente en nuestro conjunto de datos, repasemos los aspectos prácticos de la integración de consultas de Rockset en nuestra aplicación. Rockset expone servicios RESTful que están protegidos por un token de autorización. Los SDK también están disponibles para lenguajes de programación populares. Esto lo convierte en una excelente opción para la integración con aplicaciones sin servidor porque no necesita establecer una configuración de red privada complicada para acceder a su base de datos. Para interactuar con la API de Rockset en nuestra aplicación, necesitaremos una clave de API de Rockset. Puede crear una en la de la consola Rockset. Una vez que lo haya hecho, copie su valor en su archivo serverless.yml y vuelva a implementarlo para que esté disponible para su aplicación. sección de claves API Nota al margen: para simplificar, utilizamos esta clave API como variable de entorno. En una aplicación real, debería utilizar algo como o para almacenar su secreto y evitar variables de entorno. Parameter Store AWS Secrets Manager Mire nuestra para ver cómo interactuamos con la API de Rockset. La inicialización de la clase incluye un objeto de cliente Rockset que se utilizará para realizar llamadas a Rockset. clase TransactionService En el , tenemos la siguiente consulta para interactuar con Rockset: método filterTransactions de nuestra clase de servicio const response = await this._rocksetClient.queries.query({ sql: { query: ` SELECT * FROM Transactions WHERE organization = :organization AND category = :category AND amount BETWEEN :minAmount AND :maxAmount ORDER BY transactionTime DESC LIMIT 20`, parameters: [ { name: "organization", type: "string", value: organization, }, { name: "category", type: "string", value: category, }, { name: "minAmount", type: "float", value: minAmount, }, { name: "maxAmount", type: "float", value: maxAmount, }, ], }, }); Hay dos cosas a tener en cuenta sobre esta interacción. Primero, utilizamos parámetros con nombre en nuestra consulta cuando manejamos entradas de los usuarios. Esta es una práctica común con las bases de datos SQL para evitar ataques de inyección SQL. En segundo lugar, el código SQL está entremezclado con el código de nuestra aplicación y puede resultar difícil realizar un seguimiento con el tiempo. Si bien esto puede funcionar, existe una manera mejor. A medida que apliquemos nuestro próximo caso de uso, veremos cómo usar Rockset Query Lambdas en nuestra aplicación. Usando Rockset para agregación Hasta este punto, hemos revisado las estrategias de indexación de DynamoDB y Rockset al analizar cómo la base de datos puede encontrar un registro individual o un conjunto de registros que coincidan con un predicado de filtro particular. Por ejemplo, vimos que DynamoDB lo empuja a usar una clave principal para buscar un registro, mientras que el índice invertido de Rockset puede encontrar registros de manera eficiente utilizando condiciones de filtro altamente selectivas. En esta sección final, cambiaremos un poco de tema para centrarnos en el diseño de los datos en lugar de indexarlos directamente. Al pensar en el diseño de los datos, contrastaremos dos enfoques: basado en filas versus basado en columnas. Las bases de datos basadas en filas, como su nombre lo indica, organizan sus datos en el disco en filas. La mayoría de las bases de datos relacionales, como PostgreSQL y MySQL, son bases de datos basadas en filas. También lo son muchas bases de datos NoSQL, como DynamoDB, incluso si sus registros no son técnicamente "filas" en el sentido de una base de datos relacional. Las bases de datos basadas en filas son excelentes para los patrones de acceso que hemos analizado hasta ahora. Cuando recuperamos una transacción individual por su ID o un conjunto de transacciones de acuerdo con algunas condiciones de filtro, generalmente queremos que todos los campos regresen para cada una de las transacciones. Debido a que todos los campos del registro se almacenan juntos, generalmente se necesita una sola lectura para devolver el registro. (Nota: algunos matices sobre esto llegarán en un momento). La agregación es una historia completamente diferente. Con las consultas de agregación, queremos calcular un agregado: un recuento de todas las transacciones, una suma de los totales de las transacciones o un gasto promedio por mes para un conjunto de transacciones. Volviendo al usuario de la organización Vandelay Industries, imagine que quiere mirar los últimos tres meses y encontrar el gasto total por categoría para cada mes. Una versión simplificada de esa consulta sería la siguiente: SELECT category, EXTRACT(month FROM transactionTime) AS month, sum(amount) AS amount FROM transactions WHERE organization = 'Vandelay Industries' AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month ORDER BY category, month DESC Para esta consulta, podría haber una gran cantidad de registros que deban leerse para calcular el resultado. Sin embargo, observe que no necesitamos muchos de los campos para cada uno de nuestros registros. Sólo necesitamos cuatro (categoría, tiempo de transacción, organización y monto) para determinar este resultado. Por lo tanto, no solo necesitamos leer muchos más registros para satisfacer esta consulta, sino que nuestro diseño basado en filas leerá un montón de campos que son innecesarios para nuestro resultado. Por el contrario, un diseño basado en columnas almacena datos en el disco en columnas. El índice convergente de Rockset utiliza un índice de columnas para almacenar datos en un diseño basado en columnas. En un diseño basado en columnas, los datos se almacenan juntos por columnas. Un registro individual se divide en las columnas que lo constituyen para su indexación. Si mi consulta necesita realizar una agregación para sumar el atributo "cantidad" para una gran cantidad de registros, Rockset puede hacerlo simplemente escaneando la parte "cantidad" del índice de columnas. Esto reduce enormemente la cantidad de datos leídos y procesados en comparación con los diseños basados en filas. Tenga en cuenta que, de forma predeterminada, el índice de columnas de Rockset no ordenará los atributos dentro de una columna. Debido a que tenemos casos de uso orientados al usuario que operarán con los datos de un cliente en particular, preferiríamos organizar nuestro índice en columnas por cliente para reducir la cantidad de datos a escanear mientras usamos el índice en columnas. Rockset proporciona para ayudar con esto. Con la agrupación, podemos indicar que queremos que nuestro índice de columnas esté agrupado por el atributo "organización". Esto agrupará todos los valores de las columnas por organización dentro de los índices de columnas. Por lo tanto, cuando Vandelay Industries agrega sus datos, el procesador de consultas de Rockset puede omitir las partes del índice de columnas para otros clientes. agrupación de datos en su índice de columnas Cómo el índice basado en filas de Rockset ayuda al procesamiento Antes de continuar con el uso del índice columnar en nuestra aplicación, quiero hablar sobre otro aspecto del índice convergente de Rockset. Anteriormente, mencioné que se usaban diseños basados en filas al recuperar registros completos e indiqué que tanto DynamoDB como nuestras consultas de índice invertido de Rockset estaban usando estos diseños. Eso es sólo parcialmente cierto. El índice invertido tiene algunas similitudes con un índice basado en columnas, ya que almacena los nombres y valores de las columnas juntos para realizar búsquedas eficientes por cualquier atributo. Cada entrada de índice incluye un puntero a los ID de los registros que incluyen la combinación de valor y nombre de columna dada. Una vez que se descubren los ID relevantes a partir del índice invertido, Rockset puede recuperar el registro completo utilizando el índice de fila. Rockset utiliza codificación de diccionario y otras técnicas de compresión avanzadas para minimizar el tamaño de almacenamiento de datos. Por lo tanto, ahora hemos visto cómo encaja el índice convergente de Rockset: El se utiliza para escanear rápidamente una gran cantidad de valores en una columna particular en busca de agregaciones; índice basado en columnas El se utiliza para filtros selectivos en cualquier nombre y valor de columna; índice invertido El se utiliza para recuperar cualquier atributo adicional al que se pueda hacer referencia en la cláusula de proyección. índice basado en filas Debajo del capó, el potente motor de consulta e indexación de Rockset realiza un seguimiento de las estadísticas de sus datos y genera planes óptimos para ejecutar su consulta de manera eficiente. Aplicación: uso de Rockset Query Lambdas en su aplicación Implementemos nuestra consulta de agregación Rockset que utiliza el índice columnar. Para nuestra consulta anterior, escribimos nuestra consulta SQL directamente en la API de Rockset. Si bien esto es lo correcto desde algunas interfaces de usuario altamente personalizables, existe una mejor opción cuando el código SQL es más estático. Nos gustaría evitar mantener nuestro código SQL desordenado en medio de la lógica de nuestra aplicación. Para ayudar con esto, Rockset tiene una función llamada Query Lambdas. Query Lambdas son consultas con nombre, versionadas y parametrizadas que se registran en la consola de Rockset. Después de haber configurado Query Lambda en Rockset, recibirá un punto final escalable y completamente administrado para Query Lambda al que puede llamar con sus parámetros para que Rockset lo ejecute. Además, incluso obtendrá estadísticas de seguimiento para cada Query Lambda, de modo que pueda realizar un seguimiento del rendimiento de su Query Lambda a medida que realiza cambios. Puede , pero configuremos nuestro primer Query Lambda para manejar nuestra consulta de agregación. . obtener más información sobre Query Lambdas aquí Puede encontrar un tutorial completo en el repositorio de la aplicación Navegue a la de la consola Rockset. Pegue la siguiente consulta en el editor: sección Editor de consultas SELECT category, EXTRACT( month FROM transactionTime ) as month, EXTRACT( year FROM transactionTime ) as year, TRUNCATE(sum(amount), 2) AS amount FROM Transactions WHERE organization = :organization AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month, year ORDER BY category, month, year DESC Esta consulta agrupará las transacciones de los últimos tres meses para una organización determinada en depósitos según la categoría determinada y el mes de la transacción. Luego, sumará los valores de una categoría por mes para encontrar la cantidad total gastada durante cada mes. Observe que incluye un parámetro para el atributo "organización", como lo indica la sintaxis ":organización" en la consulta. Esto indica que se debe pasar un valor de organización para ejecutar la consulta. Guarde la consulta como Query Lambda en la consola de Rockset. Luego, observe el . Llama a Query Lambda por su nombre y pasa por alto la propiedad de "organización" proporcionada por un usuario. código fetchTransactionsByCategoryAndMonth en nuestra clase TransactionService Este es un código mucho más sencillo de manejar en nuestra aplicación. Además, Rockset proporciona control de versiones y monitoreo específico de consultas para cada Query Lambda. Esto hace que sea más fácil mantener sus consultas a lo largo del tiempo y comprender cómo los cambios en la sintaxis de la consulta afectan el rendimiento. Conclusión En esta publicación, vimos cómo usar DynamoDB y Rockset juntos para crear una experiencia de aplicación rápida y agradable para nuestros usuarios. Al hacerlo, aprendimos tanto los fundamentos conceptuales como los pasos prácticos para implementar nuestra aplicación. Primero, utilizamos DynamoDB para manejar la funcionalidad principal de nuestra aplicación. Esto incluye patrones de acceso como recuperar un feed de transacciones para un cliente en particular o ver una transacción individual. Gracias a la estrategia de partición basada en clave primaria de DynamoDB, es capaz de proporcionar un rendimiento consistente a cualquier escala. Pero el diseño de DynamoDB también limita su flexibilidad. No puede manejar consultas selectivas en campos arbitrarios o agregaciones en una gran cantidad de registros. Para manejar estos patrones, utilizamos Rockset. Rockset proporciona un índice secundario totalmente administrado para impulsar aplicaciones con muchos datos. Vimos cómo Rockset mantiene un canal de ingesta continuo desde su almacén de datos principal que indexa sus datos en un índice convergente, que combina indexación invertida, en columnas y en filas. Mientras recorríamos nuestros patrones, vimos cómo cada una de las técnicas de indexación de Rockset funciona en conjunto para manejar experiencias de usuario placenteras. Finalmente, repasamos los pasos prácticos para conectar Rockset a nuestra tabla DynamoDB e interactuar con Rockset en nuestra aplicación. También aparece . aquí
