Muchos equipos de desarrollo recurren a DynamoDB para crear arquitecturas basadas en eventos y aplicaciones de alto rendimiento y fáciles de usar a escala. Como base de datos operativa, DynamoDB está optimizada para transacciones en tiempo real incluso cuando se implementa en múltiples ubicaciones geográficas. Sin embargo, no proporciona un rendimiento sólido para los patrones de acceso a análisis y búsqueda. Búsqueda y análisis en DynamoDB Si bien las bases de datos NoSQL como DynamoDB generalmente tienen excelentes características de escalamiento, solo admiten un conjunto limitado de operaciones que se centran en el procesamiento de transacciones en línea. Esto dificulta buscar, filtrar, agregar y unir datos sin depender en gran medida de estrategias de indexación eficientes. DynamoDB almacena datos de forma interna dividiéndolos en una gran cantidad de nodos en función de un campo de clave de partición especificado por el usuario presente en cada elemento. Esta se puede combinar opcionalmente con una clave de clasificación para representar una clave principal. La clave principal actúa como índice, lo que hace que las operaciones de consulta sean económicas. Una operación de consulta puede realizar comparaciones de igualdad (=) en la clave de partición y operaciones comparativas (>, <, =, ENTRE) en la clave de clasificación, si se especifica. clave de partición especificada por el usuario La realización de consultas analíticas no cubiertas por el esquema anterior requiere el uso de una operación de escaneo, que generalmente se ejecuta escaneando toda la tabla de DynamoDB en paralelo. Estos escaneos pueden ser lentos y costosos en términos de rendimiento de lectura porque requieren una lectura completa de toda la tabla. Los escaneos también tienden a ralentizarse cuando crece el tamaño de la tabla, ya que hay más datos que escanear para producir resultados. Si queremos admitir consultas analíticas sin encontrar costos de escaneo prohibitivos, podemos aprovechar los índices secundarios, que discutiremos a continuación. Indexación en DynamoDB En DynamoDB, los índices secundarios se utilizan a menudo para mejorar el rendimiento de la aplicación mediante la indexación de campos que se consultan con frecuencia. Las operaciones de consulta en índices secundarios también se pueden utilizar para potenciar funciones específicas a través de consultas analíticas que tienen requisitos claramente definidos. Los índices secundarios consisten en crear claves de partición y claves de clasificación opcionales sobre los campos que queremos consultar. Hay dos tipos de índices secundarios: Índices secundarios locales (LSI): los LSI amplían los atributos de clave hash y de rango para una sola partición. Índices secundarios globales (GSI): los GSI son índices que se aplican a una tabla completa en lugar de a una sola partición. Sin embargo, como , el uso excesivo de GSI en DynamoDB puede resultar costoso. Los análisis en DynamoDB, a menos que se utilicen solo para búsquedas de puntos muy simples o escaneos de rango pequeño, pueden generar un uso excesivo de índices secundarios y costos elevados. descubrió Nike Los costos de capacidad aprovisionada cuando se utilizan índices pueden acumularse rápidamente porque todas las actualizaciones de la tabla base también deben realizarse en los GSI correspondientes. De hecho, AWS recomienda que para evitar limitar las escrituras en la tabla base y paralizar la aplicación. El costo de la capacidad de escritura aprovisionada crece linealmente con la cantidad de GSI configurados, lo que hace que sea prohibitivo usar muchos GSI para admitir muchos patrones de acceso. la capacidad de escritura aprovisionada para un índice secundario global debe ser igual o mayor que la capacidad de escritura de la tabla base DynamoDB tampoco está bien diseñado para indexar datos en estructuras anidadas, incluidas matrices y objetos. Antes de indexar los datos, los usuarios deberán desnormalizarlos, aplanando los objetos y matrices anidados. Esto podría aumentar considerablemente la cantidad de escrituras y los costos asociados. Para obtener un examen más detallado del uso de índices secundarios de DynamoDB para análisis, consulte nuestro blog . Índices secundarios para análisis en DynamoDB La conclusión es que, para los casos de uso analítico, puede obtener importantes ventajas de rendimiento y costos al sincronizar la tabla de DynamoDB con una herramienta o servicio diferente que actúa como un índice secundario externo para ejecutar análisis complejos de manera eficiente. DynamoDB + Elasticbúsqueda Un método para crear un índice secundario sobre nuestros datos es utilizar DynamoDB con Elasticsearch. Elasticsearch basado en la nube, como Elastic Cloud o Amazon OpenSearch Service, se puede utilizar para aprovisionar y configurar nodos según el tamaño de los índices, la replicación y otros requisitos. Un clúster administrado requiere algunas operaciones para actualizarlo, protegerlo y mantener su rendimiento, pero menos que ejecutarlo usted mismo en instancias EC2. Como el enfoque que utiliza el no es compatible y es bastante difícil de configurar, podemos transmitir escrituras desde DynamoDB a Elasticsearch utilizando DynamoDB Streams y una función AWS Lambda. Este enfoque requiere que realicemos dos pasos separados: complemento Logstash para Amazon DynamoDB Primero creamos una función lambda que se invoca en la secuencia de DynamoDB para publicar cada actualización tal como ocurre en DynamoDB en Elasticsearch. Luego creamos una función lambda (o una instancia EC2 que ejecuta un script si tardará más que el tiempo de espera de ejecución de lambda) para publicar todo el contenido existente de DynamoDB en Elasticsearch. Debemos escribir y conectar ambas funciones lambda con los permisos correctos para asegurarnos de no perder ninguna escritura en nuestras tablas. Cuando se configuran junto con el monitoreo requerido, podemos recibir documentos en Elasticsearch desde DynamoDB y podemos usar Elasticsearch para ejecutar consultas analíticas sobre los datos. La ventaja de este enfoque es que Elasticsearch admite la indexación de texto completo y varios tipos de consultas analíticas. Elasticsearch admite clientes en varios idiomas y herramientas como Kibana para visualización que pueden ayudar a crear paneles rápidamente. Cuando un clúster está configurado correctamente, las latencias de las consultas se pueden ajustar para realizar consultas analíticas rápidas sobre los datos que fluyen hacia Elasticsearch. Las desventajas incluyen que el costo de instalación y mantenimiento de la solución puede ser alto. Incluso Elasticsearch administrado requiere lidiar con la replicación, la fragmentación, el crecimiento del índice y el ajuste del rendimiento de las instancias subyacentes. Elasticsearch tiene una arquitectura estrechamente acoplada que no separa la computación y el almacenamiento. Esto significa que los recursos a menudo se sobreaprovisionan porque no se pueden escalar de forma independiente. Además, múltiples cargas de trabajo, como lecturas y escrituras, competirán por los mismos recursos informáticos. Elasticsearch tampoco puede manejar las actualizaciones de manera eficiente. La actualización de cualquier campo provocará una reindexación de todo el documento. Los documentos de Elasticsearch son inmutables, por lo que cualquier actualización requiere que se indexe un documento nuevo y que la versión anterior se marque como eliminada. Esto da como resultado un cálculo adicional y un gasto de E/S para volver a indexar incluso los campos sin cambios y escribir documentos completos tras la actualización. Debido a que las lambdas se activan cuando ven una actualización en la transmisión de DynamoDB, pueden tener picos de latencia debido a . La configuración requiere métricas y monitoreo para garantizar que procese correctamente los eventos del flujo de DynamoDB y pueda escribir en Elasticsearch. arranques en frío Funcionalmente, en términos de consultas analíticas, , que son útiles para consultas analíticas complejas que involucran más de un índice. Los usuarios de Elasticsearch a menudo tienen que desnormalizar datos, realizar uniones del lado de la aplicación o utilizar objetos anidados o relaciones padre-hijo para sortear esta limitación. Elasticsearch carece de soporte para uniones Ventajas Soporte de búsqueda de texto completo Soporte para varios tipos de consultas analíticas. Puede trabajar con los datos más recientes en DynamoDB Desventajas Requiere gestión y supervisión de la infraestructura para la ingesta, indexación, replicación y fragmentación. La arquitectura estrechamente acoplada da como resultado un sobreaprovisionamiento de recursos y contención informática Actualizaciones ineficientes Requiere un sistema independiente para garantizar la integridad y coherencia de los datos entre DynamoDB y Elasticsearch No hay soporte para uniones entre diferentes índices. Este enfoque puede funcionar bien al implementar la búsqueda de texto completo sobre los datos en DynamoDB y paneles usando Kibana. Sin embargo, las operaciones necesarias para ajustar y mantener un clúster de Elasticsearch en producción, su uso ineficiente de recursos y la falta de capacidades de unión pueden ser un desafío. DynamoDB + Rockset es una base de datos de búsqueda y análisis totalmente administrada y creada principalmente para admitir aplicaciones en tiempo real con altos requisitos de QPS. A menudo se utiliza como índice secundario externo para datos de bases de datos OLTP. Rockset Rockset tiene un conector integrado con DynamoDB que se puede utilizar para mantener los datos sincronizados entre DynamoDB y Rockset. Podemos especificar la tabla de DynamoDB desde la que queremos sincronizar el contenido y una colección Rockset que indexe la tabla. Rockset indexa el contenido de la tabla de DynamoDB en una instantánea completa y luego sincroniza los nuevos cambios a medida que ocurren. El contenido de la colección Rockset siempre está sincronizado con la fuente de DynamoDB; no más de unos pocos segundos de diferencia en estado estable. Rockset administra automáticamente la integridad y la coherencia de los datos entre la tabla de DynamoDB y la colección de Rockset al monitorear el estado de la transmisión y brindar visibilidad de los cambios de la transmisión desde DynamoDB. Sin una definición de esquema, una colección Rockset puede adaptarse automáticamente cuando se agregan o eliminan campos, o cuando la estructura/tipo de los datos cambia en DynamoDB. Esto es posible gracias a y que eliminan la necesidad de cualquier ETL adicional. una fuerte tipificación dinámica esquemas inteligentes La colección Rockset que obtuvimos de DynamoDB admite SQL para consultas y los desarrolladores pueden usarla fácilmente sin tener que aprender un lenguaje específico de dominio. También se puede utilizar para atender consultas a aplicaciones a través de una API REST o utilizar bibliotecas cliente en varios lenguajes de programación. El superconjunto de ANSI SQL que admite Rockset puede funcionar de forma nativa en matrices y objetos JSON profundamente anidados, y aprovechar índices que se crean automáticamente en todos los campos, para obtener latencias de milisegundos incluso en consultas analíticas complejas. Rockset ha sido pionero en , que permite aislar cargas de trabajo en unidades de computación separadas mientras se comparten los mismos datos subyacentes en tiempo real. Esto ofrece a los usuarios una mayor eficiencia de recursos al admitir la ingesta y consultas simultáneas o múltiples aplicaciones en el mismo conjunto de datos. la separación entre computación Además, Rockset se encarga de la seguridad, el cifrado de datos y el control de acceso basado en roles para gestionar el acceso a los mismos. Los usuarios de Rockset pueden evitar la necesidad de ETL aprovechando que podemos configurar en Rockset para modificar los datos a medida que llegan a una colección. Opcionalmente, los usuarios también pueden administrar el ciclo de vida de los datos configurando políticas de retención para eliminar automáticamente los datos más antiguos. Tanto la ingesta de datos como el servicio de consultas se administran automáticamente, lo que nos permite centrarnos en crear e implementar paneles y aplicaciones en vivo y, al mismo tiempo, eliminar la necesidad de operaciones y administración de infraestructura. las transformaciones de ingesta Especialmente relevante en relación con la sincronización con DynamoDB, Rockset admite actualizaciones a nivel de campo in situ, para evitar una reindexación costosa. en términos de ingesta, consultas y eficiencia para elegir la herramienta adecuada para el trabajo. Compare Rockset y Elasticsearch Resumen Diseñado para ofrecer un alto QPS y servir aplicaciones en tiempo real Completamente sin servidor. No se requieren operaciones ni aprovisionamiento de infraestructura o base de datos Separación entre computación para un rendimiento predecible y una utilización eficiente de los recursos Sincronización en vivo entre DynamoDB y la colección Rockset, para que nunca estén separados por más de unos pocos segundos. Monitoreo para garantizar la coherencia entre DynamoDB y Rockset Índices automáticos creados sobre los datos que permiten consultas de baja latencia. Actualizaciones locales que evitan la costosa reindexación y reducen la latencia de los datos Se une con datos de otras fuentes como Amazon Kinesis, Apache Kafka, Amazon S3, etc. Podemos utilizar Rockset para implementar sin ningún problema operativo, de escalado o de mantenimiento. Esto puede acelerar significativamente el desarrollo de aplicaciones en tiempo real. Si desea crear su aplicación con datos de DynamoDB utilizando Rockset, puede comenzar de forma gratuita . análisis en tiempo real de los datos en DynamoDB aquí
