Comment Rockset s'empile-t-il contre Elasticsearch dans les index secondaires DynamoDB

De nombreuses équipes de développement se tournent vers DynamoDB pour créer des architectures événementielles et des applications conviviales et performantes à grande échelle. En tant que base de données opérationnelle, DynamoDB est optimisée pour les transactions en temps réel, même lorsqu'elle est déployée sur plusieurs emplacements géographiques. Cependant, il n’offre pas de bonnes performances pour les modèles d’accès à la recherche et à l’analyse.

Recherche et analyses sur DynamoDB

Bien que les bases de données NoSQL comme DynamoDB présentent généralement d'excellentes caractéristiques d'évolutivité, elles ne prennent en charge qu'un ensemble limité d'opérations axées sur le traitement des transactions en ligne. Cela rend difficile la recherche, le filtrage, l’agrégation et la fusion de données sans s’appuyer fortement sur des stratégies d’indexation efficaces.

DynamoDB stocke les données sous le capot en les partitionnant sur un grand nombre de nœuds en fonction d'un champ de clé de partition spécifié par l'utilisateur et présent dans chaque élément. Cette clé de partition spécifiée par l'utilisateur peut éventuellement être combinée avec une clé de tri pour représenter une clé primaire. La clé primaire agit comme un index, ce qui rend les opérations de requête peu coûteuses. Une opération de requête peut effectuer des comparaisons d'égalité (=) sur la clé de partition et des opérations comparatives (>, <, =, BETWEEN) sur la clé de tri si cela est spécifié.

L'exécution de requêtes analytiques non couvertes par le schéma ci-dessus nécessite l'utilisation d'une opération d'analyse, qui est généralement exécutée en analysant l'intégralité de la table DynamoDB en parallèle. Ces analyses peuvent être lentes et coûteuses en termes de débit de lecture, car elles nécessitent une lecture complète de la table entière. Les analyses ont également tendance à ralentir lorsque la taille de la table augmente, car il y a plus de données à analyser pour produire des résultats. Si nous souhaitons prendre en charge les requêtes analytiques sans rencontrer de coûts d'analyse prohibitifs, nous pouvons exploiter les index secondaires, dont nous parlerons ensuite.

Indexation dans DynamoDB

Dans DynamoDB, les index secondaires sont souvent utilisés pour améliorer les performances des applications en indexant les champs fréquemment interrogés. Les opérations de requête sur les index secondaires peuvent également être utilisées pour alimenter des fonctionnalités spécifiques via des requêtes analytiques dont les exigences sont clairement définies.

Les index secondaires consistent à créer des clés de partition et des clés de tri facultatives sur les champs que nous souhaitons interroger. Il existe deux types d'index secondaires :

• Index secondaires locaux (LSI) : les LSI étendent les attributs de clé de hachage et de plage pour une seule partition.

• Index secondaires globaux (GSI) : les GSI sont des index appliqués à une table entière au lieu d'une seule partition.

  
  

Cependant, comme Nike l'a découvert , la surutilisation des GSI dans DynamoDB peut s'avérer coûteuse. Les analyses dans DynamoDB, à moins qu'elles ne soient utilisées uniquement pour des recherches de points très simples ou des analyses à faible portée, peuvent entraîner une utilisation excessive des index secondaires et des coûts élevés.

Les coûts de capacité provisionnée lors de l'utilisation d'index peuvent s'additionner rapidement car toutes les mises à jour de la table de base doivent également être effectuées dans les GSI correspondants. En fait, AWS conseille que la capacité d'écriture allouée pour un index secondaire global soit égale ou supérieure à la capacité d'écriture de la table de base afin d'éviter de limiter les écritures sur la table de base et de paralyser l'application. Le coût de la capacité d'écriture provisionnée augmente de manière linéaire avec le nombre de GSI configurés, ce qui rend prohibitif l'utilisation de nombreux GSI pour prendre en charge de nombreux modèles d'accès.

DynamoDB n'est pas non plus bien conçu pour indexer des données dans des structures imbriquées, notamment des tableaux et des objets. Avant d'indexer les données, les utilisateurs devront dénormaliser les données, en aplatissant les objets et les tableaux imbriqués. Cela pourrait augmenter considérablement le nombre d’écritures et les coûts associés.

Pour un examen plus détaillé de l'utilisation des index secondaires DynamoDB à des fins d'analyse, consultez notre blog Index secondaires pour l'analyse sur DynamoDB .

L'essentiel est que pour les cas d'utilisation analytiques, vous pouvez obtenir des avantages significatifs en termes de performances et de coûts en synchronisant la table DynamoDB avec un autre outil ou service qui agit comme un index secondaire externe pour exécuter efficacement des analyses complexes.

DynamoDB + Elasticsearch

Une approche pour créer un index secondaire sur nos données consiste à utiliser DynamoDB avec Elasticsearch. Elasticsearch basé sur le cloud, tel qu'Elastic Cloud ou Amazon OpenSearch Service, peut être utilisé pour provisionner et configurer des nœuds en fonction de la taille des index, de la réplication et d'autres exigences. Un cluster géré nécessite certaines opérations pour être mis à niveau, sécurisé et rester performant, mais moins que de l'exécuter entièrement par vous-même sur des instances EC2.

Comme l'approche utilisant le plug-in Logstash pour Amazon DynamoDB n'est pas prise en charge et est plutôt difficile à mettre en place, nous pouvons à la place diffuser les écritures de DynamoDB vers Elasticsearch à l'aide de DynamoDB Streams et d'une fonction AWS Lambda. Cette approche nous oblige à effectuer deux étapes distinctes :

• Nous créons d'abord une fonction lambda qui est invoquée sur le flux DynamoDB pour publier chaque mise à jour au fur et à mesure qu'elle se produit dans DynamoDB dans Elasticsearch.
• Nous créons ensuite une fonction lambda (ou une instance EC2 exécutant un script si cela prend plus de temps que le délai d'exécution lambda) pour publier tout le contenu existant de DynamoDB dans Elasticsearch.

Nous devons écrire et connecter ces deux fonctions lambda avec les autorisations appropriées afin de nous assurer de ne manquer aucune écriture dans nos tables. Lorsqu'ils sont configurés avec la surveillance requise, nous pouvons recevoir des documents dans Elasticsearch à partir de DynamoDB et utiliser Elasticsearch pour exécuter des requêtes analytiques sur les données.

L'avantage de cette approche est qu'Elasticsearch prend en charge l'indexation en texte intégral et plusieurs types de requêtes analytiques. Elasticsearch prend en charge les clients dans différents langages et outils comme Kibana pour une visualisation qui peut aider à créer rapidement des tableaux de bord. Lorsqu'un cluster est correctement configuré, les latences des requêtes peuvent être optimisées pour des requêtes analytiques rapides sur les données circulant dans Elasticsearch.

Les inconvénients incluent le fait que les coûts d’installation et de maintenance de la solution peuvent être élevés. Même Elasticsearch géré nécessite de gérer la réplication, le repartitionnement, la croissance de l'index et l'optimisation des performances des instances sous-jacentes.

Elasticsearch possède une architecture étroitement couplée qui ne sépare pas le calcul et le stockage. Cela signifie que les ressources sont souvent surapprovisionnées car elles ne peuvent pas être mises à l’échelle de manière indépendante. De plus, plusieurs charges de travail, telles que les lectures et les écritures, se disputeront les mêmes ressources de calcul.

Elasticsearch ne peut pas non plus gérer efficacement les mises à jour. La mise à jour d'un champ déclenchera une réindexation de l'ensemble du document. Les documents Elasticsearch sont immuables, donc toute mise à jour nécessite qu'un nouveau document soit indexé et que l'ancienne version soit marquée comme supprimée. Cela entraîne des dépenses de calcul et d'E/S supplémentaires pour réindexer même les champs inchangés et pour écrire des documents entiers lors de la mise à jour.

Étant donné que les lambdas se déclenchent lorsqu'ils voient une mise à jour dans le flux DynamoDB, ils peuvent avoir des pics de latence en raison de démarrages à froid . La configuration nécessite des métriques et une surveillance pour garantir qu'elle traite correctement les événements du flux DynamoDB et qu'elle est capable d'écrire dans Elasticsearch.

Sur le plan fonctionnel, en termes de requêtes analytiques, Elasticsearch ne prend pas en charge les jointures , qui sont utiles pour les requêtes analytiques complexes impliquant plusieurs index. Les utilisateurs d'Elasticsearch doivent souvent dénormaliser les données, effectuer des jointures côté application ou utiliser des objets imbriqués ou des relations parent-enfant pour contourner cette limitation.

Avantages

• Prise en charge de la recherche en texte intégral
• Prise en charge de plusieurs types de requêtes analytiques
• Peut travailler sur les dernières données dans DynamoDB

Désavantages

• Nécessite la gestion et la surveillance de l'infrastructure pour l'ingestion, l'indexation, la réplication et le partitionnement.
• Une architecture étroitement couplée entraîne un surapprovisionnement des ressources et des conflits de calcul
• Mises à jour inefficaces
• Nécessite un système séparé pour garantir l'intégrité et la cohérence des données entre DynamoDB et Elasticsearch
• Pas de prise en charge des jointures entre différents index

Cette approche peut bien fonctionner lors de la mise en œuvre d'une recherche en texte intégral sur les données dans DynamoDB et les tableaux de bord à l'aide de Kibana. Cependant, les opérations requises pour régler et maintenir un cluster Elasticsearch en production, son utilisation inefficace des ressources et le manque de capacités de jointure peuvent s'avérer difficiles.

DynamoDB + Rockset

Rockset est une base de données de recherche et d'analyse entièrement gérée, conçue principalement pour prendre en charge les applications en temps réel avec des exigences QPS élevées. Il est souvent utilisé comme index secondaire externe pour les données des bases de données OLTP.

Rockset dispose d'un connecteur intégré avec DynamoDB qui peut être utilisé pour maintenir les données synchronisées entre DynamoDB et Rockset. Nous pouvons spécifier la table DynamoDB à partir de laquelle nous souhaitons synchroniser le contenu et une collection Rockset qui indexe la table. Rockset indexe le contenu de la table DynamoDB dans un instantané complet, puis synchronise les nouvelles modifications au fur et à mesure qu'elles se produisent. Le contenu de la collection Rockset est toujours synchronisé avec la source DynamoDB ; pas plus de quelques secondes d’intervalle en régime permanent.

Rockset gère automatiquement l'intégrité et la cohérence des données entre la table DynamoDB et la collection Rockset en surveillant l'état du flux et en offrant une visibilité sur les modifications de streaming à partir de DynamoDB.

Sans définition de schéma, une collection Rockset peut s'adapter automatiquement lorsque des champs sont ajoutés/supprimés, ou lorsque la structure/le type des données elles-mêmes changent dans DynamoDB. Ceci est rendu possible par un typage dynamique puissant etdes schémas intelligents qui évitent le besoin de tout ETL supplémentaire.

La collection Rockset que nous avons obtenue auprès de DynamoDB prend en charge SQL pour les requêtes et peut être facilement utilisée par les développeurs sans avoir à apprendre un langage spécifique à un domaine. Il peut également être utilisé pour envoyer des requêtes aux applications via une API REST ou en utilisant des bibliothèques clientes dans plusieurs langages de programmation. Le sur-ensemble de SQL ANSI pris en charge par Rockset peut fonctionner de manière native sur des tableaux et des objets JSON profondément imbriqués, et exploiter des index automatiquement construits sur tous les champs, pour obtenir des latences de l'ordre de quelques millisecondes, même sur des requêtes analytiques complexes.

Rockset a été le pionnier de la séparation calcul-calcul , qui permet d'isoler les charges de travail dans des unités de calcul distinctes tout en partageant les mêmes données sous-jacentes en temps réel. Cela offre aux utilisateurs une plus grande efficacité des ressources lors de la prise en charge de l'ingestion et des requêtes simultanées ou de plusieurs applications sur le même ensemble de données.

De plus, Rockset s'occupe de la sécurité, du cryptage des données et du contrôle d'accès basé sur les rôles pour gérer l'accès à celles-ci. Les utilisateurs de Rockset peuvent éviter d'avoir besoin d'ETL en tirant parti des transformations d'ingestion que nous pouvons configurer dans Rockset pour modifier les données à mesure qu'elles arrivent dans une collection. Les utilisateurs peuvent également éventuellement gérer le cycle de vie des données en configurant des politiques de conservation pour purger automatiquement les anciennes données. L'ingestion de données et le traitement des requêtes sont gérés automatiquement, ce qui nous permet de nous concentrer sur la création et le déploiement de tableaux de bord et d'applications en direct tout en éliminant le besoin de gestion et d'exploitation de l'infrastructure.

Particulièrement pertinent en ce qui concerne la synchronisation avec DynamoDB, Rockset prend en charge les mises à jour sur place au niveau du champ, afin d'éviter une réindexation coûteuse. Comparez Rockset et Elasticsearch en termes d'ingestion, de requêtes et d'efficacité pour choisir le bon outil pour le travail.

Résumé

• Conçu pour offrir un QPS élevé et servir des applications en temps réel
• Complètement sans serveur. Aucune opération ou fourniture d’infrastructure ou de base de données requise
• Séparation calcul-calcul pour des performances prévisibles et une utilisation efficace des ressources
• Synchronisation en direct entre DynamoDB et la collection Rockset, afin qu'ils ne soient jamais séparés de plus de quelques secondes
• Surveillance pour assurer la cohérence entre DynamoDB et Rockset
• Index automatiques construits sur les données permettant des requêtes à faible latence
• Mises à jour sur place qui évitent une réindexation coûteuse et réduisent la latence des données
• Se joint aux données provenant d'autres sources telles qu'Amazon Kinesis, Apache Kafka, Amazon S3, etc.

Nous pouvons utiliser Rockset pour mettre en œuvre des analyses en temps réel sur les données dans DynamoDB sans aucun problème opérationnel, de mise à l'échelle ou de maintenance. Cela peut considérablement accélérer le développement d’applications en temps réel. Si vous souhaitez créer votre application sur des données DynamoDB à l'aide de Rockset, vous pouvez commencer gratuitement ici .