Les attentes des clients et les exigences correspondantes en matière d'applications n'ont jamais été aussi élevées. Les utilisateurs attendent des applications rapides, fiables et disponibles. De plus, les données sont reines et les utilisateurs veulent pouvoir découper les données agrégées selon leurs besoins pour obtenir des informations. Les utilisateurs ne veulent pas attendre que les ingénieurs de données provisionnent de nouveaux index ou créent de nouvelles chaînes ETL. Ils veulent un accès illimité aux données les plus récentes disponibles. Mais gérer tous les besoins de vos applications est une tâche ardue pour n’importe quelle base de données. Pour la base de données, l’optimisation pour des opérations fréquentes et à faible latence sur des enregistrements individuels est différente de l’optimisation pour des agrégations moins fréquentes ou un filtrage intensif sur de nombreux enregistrements. Souvent, nous essayons de gérer les deux modèles avec la même base de données et de gérer les performances incohérentes à mesure que notre application évolue. Nous pensons que nous optimisons pour un effort ou un coût minimal, alors qu'en fait nous faisons le contraire. L'exécution d'analyses sur une base de données OLTP nécessite généralement de surprovisionner une base de données pour tenir compte des pics de trafic. Cela finit par coûter beaucoup d’argent et ne parvient généralement pas à offrir une expérience agréable à l’utilisateur final. Dans cette procédure pas à pas, nous verrons comment gérer les demandes élevées des utilisateurs avec ces deux modèles d'accès. Nous allons créer une application financière dans laquelle les utilisateurs enregistrent les transactions et visualisent les transactions récentes tout en souhaitant également un filtrage ou des agrégations complexes sur leurs transactions passées. Une approche hybride Pour répondre aux besoins de nos applications, nous utiliserons avec . DynamoDB gérera nos principaux modèles d'accès aux transactions - en enregistrant les transactions et en fournissant un flux de transactions récentes que les utilisateurs pourront parcourir. Rockset complétera DynamoDB pour gérer nos modèles d'accès « délicieux » riches en données. Nous permettrons à nos utilisateurs de filtrer par heure, commerçant, catégorie ou autres champs pour trouver les transactions pertinentes, ou d'effectuer des agrégations puissantes pour afficher les tendances des dépenses au fil du temps. Amazon DynamoDB Rockset Au fur et à mesure que nous étudierons ces modèles, nous verrons comment chacun de ces systèmes est adapté au travail à accomplir. DynamoDB excelle dans les opérations OLTP de base : lire ou écrire un élément individuel, ou récupérer une gamme d'éléments séquentiels basés sur des filtres connus. Grâce à la manière dont il partitionne les données en fonction de la clé primaire, DynamoDB est capable de fournir des performances cohérentes pour ces types de requêtes à n'importe quelle échelle. À l'inverse, Rockset excelle dans l'ingestion continue de grandes quantités de données et dans l'utilisation de plusieurs stratégies d'indexation sur ces données pour fournir un filtrage hautement sélectif, des agrégations en temps réel ou au moment de la requête, ainsi que d'autres modèles que DynamoDB ne peut pas gérer facilement. En travaillant sur cet exemple, nous apprendrons à la fois les concepts fondamentaux qui sous-tendent les deux systèmes ainsi que les étapes pratiques pour atteindre nos objectifs. Vous pouvez suivre l'application en utilisant le . dépôt GitHub Implémentation des fonctionnalités de base avec DynamoDB Nous commencerons cette procédure pas à pas en implémentant les fonctionnalités de base de notre application. Il s'agit d'un point de départ courant pour toute application, car vous créez les opérations « CRUDL » standard pour offrir la possibilité de manipuler des enregistrements individuels et de répertorier un ensemble d'enregistrements associés. Pour une application de commerce électronique, il s’agirait de la fonctionnalité permettant de passer une commande et d’afficher les commandes précédentes. Pour une application de réseau social, il s’agirait de créer des publications, d’ajouter des amis ou de consulter les personnes que vous suivez. Cette fonctionnalité est généralement implémentée par des bases de données spécialisées dans les flux de travail qui mettent l'accent sur de nombreuses opérations simultanées sur un petit nombre de lignes. de traitement transactionnel en ligne (OLTP) Pour cet exemple, nous construisons une application de finance d'entreprise où un utilisateur peut effectuer et recevoir des paiements, ainsi que consulter l'historique de ses transactions. L'exemple sera intentionnellement simplifié pour cette procédure pas à pas, mais vous pouvez penser à trois modèles d'accès principaux pour notre application : , qui stockera un enregistrement d'un paiement effectué ou reçu par l'entreprise ; Enregistrer la transaction , ce qui permettra aux utilisateurs de voir les paiements les plus récents effectués et reçus par une entreprise ; et Afficher les transactions par plage de dates , ce qui permettra à un utilisateur d'explorer les détails d'une seule transaction. Afficher une transaction individuelle Chacun de ces modèles d’accès est un modèle d’accès critique à volume élevé. Nous enregistrerons constamment les transactions des utilisateurs et le flux de transactions sera la première vue lorsqu'ils ouvriront l'application. De plus, chacun de ces modèles d'accès utilisera des paramètres connus et cohérents pour récupérer le ou les enregistrements pertinents. Nous utiliserons DynamoDB pour gérer ces modèles d'accès. DynamoDB est une base de données NoSQL fournie par AWS. Il s'agit d'une base de données entièrement gérée, et elle jouit d'une popularité croissante à la fois dans les applications à grande échelle et dans les applications sans serveur. L'une des fonctionnalités les plus uniques de DynamoDB est la manière dont il fournit des performances cohérentes à n'importe quelle échelle. Que votre table fasse 1 mégaoctet ou 1 pétaoctet, vous devriez voir le même temps de réponse pour vos opérations. Il s’agit d’une qualité souhaitable pour les cas d’utilisation de base d’OLTP comme ceux que nous implémentons ici. Il s’agit d’une réalisation technique importante et précieuse, mais il est important de comprendre qu’elle a été réalisée en étant sélectif quant aux types de requêtes qui fonctionneront bien. DynamoDB est en mesure de fournir ces performances cohérentes grâce à deux décisions de conception fondamentales. Tout d'abord, chaque enregistrement de votre table DynamoDB doit inclure une clé primaire. Cette clé primaire est composée d'une clé de partition ainsi que d'une clé de tri facultative. La deuxième décision de conception clé pour DynamoDB est que l'API impose fortement l'utilisation de la clé primaire - nous y reviendrons plus tard. Dans l'image ci-dessous, nous avons quelques exemples de données de transaction dans notre application FinTech. Notre table utilise une clé de partition du nom de l'organisation dans notre application, plus une clé de tri basée sur qui fournit les caractéristiques d'unicité d'un UUID ainsi qu'une possibilité de tri par heure de création qui nous permettent d'effectuer des requêtes basées sur le temps. l'ULID Les enregistrements de notre table incluent d'autres attributs, tels que le nom du commerçant, la catégorie et le montant, qui sont utiles dans notre application mais ne sont pas aussi critiques pour l'architecture sous-jacente de DynamoDB. La partie importante réside dans la clé primaire, et plus particulièrement dans la clé de partition. Sous le capot, DynamoDB divisera vos données en plusieurs partitions de stockage, chacune contenant un sous-ensemble des données de votre table. DynamoDB utilise l'élément clé de partition de la clé primaire pour attribuer un enregistrement donné à une partition de stockage particulière. À mesure que la quantité de données dans votre table ou le trafic sur votre table augmente, DynamoDB ajoutera des partitions afin de mettre à l'échelle horizontalement votre base de données. Comme mentionné ci-dessus, la deuxième décision de conception clé pour DynamoDB est que l'API impose fortement l'utilisation de la clé primaire. Presque toutes les actions d'API dans DynamoDB nécessitent au moins la clé de partition de votre clé primaire. De ce fait, DynamoDB est capable d'acheminer rapidement toute requête vers la partition de stockage appropriée, quel que soit le nombre de partitions et la taille totale de la table. Avec ces deux compromis, il existe nécessairement des limites dans la façon dont vous utilisez DynamoDB. Vous devez planifier et concevoir soigneusement vos modèles d'accès dès le départ, car votre clé primaire doit être impliquée dans vos modèles d'accès. Modifier vos modèles d'accès ultérieurement peut s'avérer difficile et nécessiter certaines étapes de migration manuelle. Lorsque vos cas d'utilisation relèvent des compétences de base de DynamoDB, vous en récolterez les bénéfices. Vous bénéficierez de performances cohérentes et prévisibles, quelle que soit l'échelle, et vous ne constaterez aucune dégradation à long terme de votre application au fil du temps. De plus, vous bénéficierez d'une expérience entièrement gérée avec une faible charge opérationnelle, vous permettant de vous concentrer sur ce qui compte pour l'entreprise. Les opérations principales de notre exemple correspondent parfaitement à ce modèle. Lors de la récupération d'un flux de transactions pour une organisation, nous aurons l'ID de l'organisation disponible dans notre application qui nous permettra d'utiliser l'opération DynamoDB pour récupérer un ensemble contigu d'enregistrements avec la même clé de partition. Pour récupérer des détails supplémentaires sur une transaction spécifique, nous aurons à la fois l'ID de l'organisation et l'ID de transaction disponibles pour effectuer une requête DynamoDB afin de récupérer l'élément souhaité. de requête GetItem Vous pouvez voir ces opérations en action avec l' . Suivez les instructions pour déployer l’application et l’amorcer avec des exemples de données. Ensuite, envoyez des requêtes HTTP au service déployé pour récupérer le flux de transaction pour les utilisateurs individuels. Ces opérations seront rapides et efficaces quel que soit le nombre de requêtes simultanées ou la taille de votre table DynamoDB. exemple d'application Compléter DynamoDB avec Rockset Jusqu'à présent, nous avons utilisé DynamoDB pour gérer nos principaux modèles d'accès. DynamoDB est idéal pour ces modèles car son partitionnement basé sur des clés fournira des performances cohérentes à n'importe quelle échelle. Cependant, DynamoDB n'est pas doué pour gérer d'autres modèles d'accès. DynamoDB ne vous permet pas d'interroger efficacement par des attributs autres que la clé primaire. Vous pouvez utiliser pour réindexer vos données avec des attributs supplémentaires, mais cela peut toujours poser problème si vous disposez de nombreux attributs différents pouvant être utilisés pour indexer vos données. les index secondaires de DynamoDB De plus, DynamoDB ne fournit aucune fonctionnalité d'agrégation prête à l'emploi. Vous pouvez calculer vos propres agrégats à l'aide de DynamoDB, mais cela peut être avec une flexibilité réduite ou avec une consommation de lecture non optimisée par rapport à une solution conçue pour l'agrégation dès le départ. Pour gérer ces modèles, nous . compléterons DynamoDB avec Rockset Il est préférable de considérer Rockset comme un ensemble secondaire d'index sur vos données. Rockset utilise uniquement ces index au moment de la requête et ne projette aucune charge dans DynamoDB lors d'une lecture. Plutôt que des mises à jour transactionnelles individuelles de vos clients d'application, Rockset est conçu pour une ingestion continue et en continu à partir de votre magasin de données principal. Il dispose de connecteurs directs pour un certain nombre de magasins de données principaux, notamment DynamoDB, MongoDB, Kafka et de nombreuses bases de données relationnelles. Au fur et à mesure que Rockset ingère les données de votre base de données principale, il indexe ensuite vos données dans un , qui emprunte des concepts à : un index de lignes, un index inversé et un index de colonnes. Des index supplémentaires, tels que la plage, le type et le géospatial, sont automatiquement créés en fonction des types de données ingérés. Nous aborderons les spécificités de ces index ci-dessous, mais cet index convergé permet des modèles d'accès plus flexibles à vos données. index convergé Il s'agit du concept principal de Rockset : il s'agit d'un index secondaire sur vos données utilisant un pipeline d'ingestion entièrement géré en temps quasi réel à partir de votre banque de données principale. Les équipes extraient depuis longtemps des données de DynamoDB pour les insérer dans un autre système afin de gérer des cas d'utilisation supplémentaires. Avant d'entrer dans les détails de la façon dont Rockset ingère les données de votre table, discutons brièvement en quoi Rockset diffère des autres options dans cet espace. Il existe quelques différences fondamentales entre Rockset et d’autres approches. Premièrement, Rockset est entièrement géré. Non seulement vous n'êtes pas obligé de gérer l'infrastructure de la base de données, mais vous n'avez pas non plus besoin de maintenir le pipeline pour extraire, transformer et charger les données dans Rockset. Avec de nombreuses autres solutions, vous êtes en charge du code « colle » entre vos systèmes. Ces systèmes sont critiques mais sujets aux pannes, car vous devez vous prémunir de manière défensive contre tout changement dans la structure des données. Les changements en amont peuvent entraîner des difficultés en aval pour ceux qui assurent la maintenance de ces systèmes. Deuxièmement, Rockset peut gérer les données en temps réel de manière modifiable. Avec de nombreux autres systèmes, vous obtenez l’un ou l’autre. Vous pouvez choisir d'effectuer des exportations périodiques et des chargements groupés de vos données, mais cela entraîne des données obsolètes entre les chargements. Vous pouvez également diffuser des données dans votre entrepôt de données en mode ajout uniquement, mais vous ne pouvez pas effectuer de mises à jour sur place en cas de modification des données. Rockset est capable de gérer les mises à jour des éléments existants aussi rapidement et efficacement qu'il insère de nouvelles données et peut ainsi vous donner un aperçu en temps réel de l'évolution de vos données. Troisièmement, Rockset génère automatiquement ses index. D'autres solutions « entièrement gérées » nécessitent toujours que vous configuriez les index selon vos besoins pour prendre en charge de nouvelles requêtes. Le moteur de requêtes de Rockset est conçu pour utiliser un ensemble d'index pour prendre en charge toutes les requêtes. À mesure que vous ajoutez de plus en plus de requêtes à votre système, vous n'avez pas besoin d'ajouter d'index supplémentaires, ce qui occupe de plus en plus d'espace et de ressources de calcul. Cela signifie également que les requêtes ad hoc peuvent également exploiter pleinement les index, les rendant rapides sans attendre qu'un administrateur ajoute un index sur mesure pour les prendre en charge. Comment Rockset ingère les données de DynamoDB Maintenant que nous connaissons les bases de Rockset et comment il nous aide, connectons notre table DynamoDB à Rockset. Ce faisant, nous apprendrons comment fonctionne le processus d’ingestion de Rockset et en quoi il diffère des autres options. Rockset dispose de connecteurs spécialement conçus pour un certain nombre de sources de données, et la mise en œuvre spécifique du connecteur dépend des spécificités de la source de données en amont. Pour se connecter à DynamoDB, Rockset s'appuie sur . DynamoDB Streams est une fonctionnalité de capture de données modifiées de DynamoDB où les détails de chaque opération d'écriture sur une table DynamoDB sont enregistrés dans le flux. Les consommateurs du flux peuvent traiter ces modifications dans le même ordre dans lequel elles se sont produites par rapport à la table pour mettre à jour les systèmes en aval. DynamoDB Streams Un flux DynamoDB est idéal pour que Rockset reste à jour avec une table DynamoDB en temps quasi réel, mais ce n'est pas toute l'histoire. Un flux DynamoDB contient uniquement les enregistrements des opérations d'écriture survenues après l'activation du flux sur la table. De plus, un . Les opérations survenues avant l'activation du flux ou il y a plus de 24 heures ne seront pas présentes dans le flux. flux DynamoDB conserve les enregistrements pendant seulement 24 heures Mais Rockset a besoin non seulement des données les plus récentes, mais de toutes les données de votre base de données afin de répondre correctement à vos requêtes. Pour gérer cela, il effectue une exportation groupée initiale (en utilisant soit une analyse DynamoDB, soit , en fonction de la taille de votre table) pour récupérer l'état initial de votre table. une exportation vers S3 Ainsi, le processus de connexion DynamoDB de Rockset comporte deux parties : Un processus initial pour exporter votre table complète pour l'ingestion dans Rockset ; d'amorçage Un processus ultérieur et pour consommer les mises à jour de votre flux DynamoDB et mettre à jour les données dans Rockset. continu Notez que ces deux processus sont entièrement gérés par Rockset et transparents pour vous en tant qu'utilisateur. Vous ne serez pas en charge de maintenir ces pipelines et de répondre aux alertes en cas d'erreur. De plus, si vous choisissez la méthode d'exportation S3 pour le processus d'ingestion initial, aucun des processus d'ingestion Rockset ne consommera d'unités de capacité de lecture de votre table principale. Ainsi, Rockset ne réduira pas la consommation de vos cas d'utilisation d'applications et n'affectera pas la disponibilité en production. Application : connexion de DynamoDB à Rockset Avant de passer à l'utilisation de Rockset dans notre application, connectons Rockset à notre table DynamoDB. Tout d'abord, nous devons créer une nouvelle intégration entre Rockset et notre table. Nous passerons en revue les étapes de haut niveau ci-dessous, mais vous pouvez trouver si nécessaire. des instructions étape par étape plus détaillées dans le référentiel d'application Dans la console Rockset, accédez au pour démarrer ce processus. nouvel assistant d'intégration Dans l'assistant d'intégration, choisissez comme type d'intégration. Cliquez ensuite sur pour passer à l'étape suivante. Amazon DynamoDB Démarrer L'assistant d'intégration DynamoDB contient des instructions étape par étape pour autoriser Rockset à accéder à votre table DynamoDB. Cela nécessite la création d'une stratégie IAM, d'un rôle IAM et d'un compartiment S3 pour l'exportation de votre table. Vous pouvez suivre ces instructions pour créer les ressources manuellement si vous préférez. Dans le monde sans serveur, nous préférons créer autant que possible des choses via , et cela inclut ces ressources de support. une infrastructure en tant que code L'exemple de référentiel inclut l'infrastructure en tant que code nécessaire pour créer les ressources d'intégration Rockset. Pour les utiliser, recherchez d'abord les valeurs Rockset Account ID et External ID au bas de l'assistant d'intégration Rockset. Copiez et collez ces valeurs dans les bloc du fichier serverless.yml. Ensuite, pour créer ces ressources. sections appropriées du custom décommentez les ressources sur les lignes 71 à 122 du serverless.yml Redéployez votre application pour créer ces nouvelles ressources. Dans les résultats du déploiement, copiez et collez le nom du compartiment S3 et l'ARN du rôle IAM aux endroits appropriés dans la console Rockset. Ensuite, cliquez sur le bouton Enregistrer l'intégration pour enregistrer votre intégration. Après avoir créé votre intégration, vous devrez créer une à partir de l'intégration. Accédez à dans la console Rockset et suivez les étapes pour utiliser votre intégration pour créer une collection. Vous pouvez également trouver dans le référentiel d'applications. collection Rockset l'assistant de création de collection des instructions étape par étape pour créer une collection Une fois que vous avez effectué cette connexion, généralement sur un ensemble d'instances de taille appropriée, les insertions, mises à jour ou suppressions de données dans DynamoDB seront reflétées dans l'index de Rockset et disponibles pour une interrogation en moins de 2 secondes. Utiliser Rockset pour le filtrage complexe Maintenant que nous avons connecté Rockset à notre table DynamoDB, voyons comment Rockset peut activer de nouveaux modèles d'accès à nos données existantes. Rappelez-vous de notre section sur les fonctionnalités principales que DynamoDB est fortement axé sur vos clés primaires. Vous devez utiliser votre clé primaire pour accéder efficacement à vos données. En conséquence, nous avons structuré notre tableau pour utiliser le nom de l'organisation et l'heure de la transaction dans nos clés primaires. Cette structure fonctionne pour nos principaux modèles d'accès, mais nous souhaitons peut-être fournir aux utilisateurs un moyen plus flexible de parcourir leurs transactions. Il existe un certain nombre d'attributs utiles (catégorie, nom du commerçant, montant, etc.) qui peuvent être utiles pour le filtrage. Nous pourrions utiliser les index secondaires de DynamoDB pour activer le filtrage sur davantage d'attributs, mais ce n'est toujours pas une solution idéale ici. La structure de clé primaire de DynamoDB ne permet pas facilement des requêtes flexibles impliquant des combinaisons de nombreux attributs facultatifs. Vous pourriez avoir un index secondaire pour filtrer par nom de commerçant et par date, mais vous auriez besoin d'un autre index secondaire si vous souhaitez autoriser le filtrage par nom de commerçant, date et montant. Un modèle d'accès qui filtre par catégorie nécessiterait un troisième index secondaire. Plutôt que de traiter de cette complexité, nous nous appuierons ici sur Rockset. Nous avons vu précédemment que Rockset utilise un index convergé pour indexer vos données de plusieurs manières. L'une de ces méthodes est un index inversé. Avec un index inversé, Rockset indexe directement chaque attribut. Remarquez comment cet index est organisé. Chaque nom et valeur d'attribut est utilisé comme clé de l'index et la valeur est une liste d'ID de document qui incluent le nom et la valeur d'attribut correspondants. Les clés sont construites de manière à ce que leur ordre de tri naturel puisse prendre en charge efficacement les requêtes de plage. Un index inversé est idéal pour les requêtes comportant des conditions de filtre sélectives. Imaginez que nous souhaitions permettre à nos utilisateurs de filtrer leurs transactions pour trouver celles qui correspondent à certains critères. Un membre de l'organisation Vandelay Industries souhaite savoir combien de fois il a récemment commandé du Chipotle. Vous pourriez trouver cela avec une requête comme suit : SELECT * FROM transactions WHERE organization = 'Vandelay Industries' AND merchant_name = 'Chipotle' Comme nous effectuons des filtres sélectifs sur le nom du client et du commerçant, nous pouvons utiliser l'index inversé pour trouver rapidement les documents correspondants. Rockset recherchera à la fois les paires nom d'attribut et valeur dans l'index inversé pour trouver les listes de documents correspondants. Une fois qu'il dispose de ces deux listes, il peut les fusionner pour trouver l'ensemble d'enregistrements qui correspondent aux deux ensembles de conditions et renvoyer les résultats au client. Tout comme l'indexation basée sur les partitions de DynamoDB est efficace pour les opérations qui utilisent la clé de partition, l'index inversé de Rockset vous permet des recherches efficaces sur n'importe quel champ de votre ensemble de données, même sur les attributs d'objets incorporés ou sur les valeurs à l'intérieur de tableaux intégrés. Application : Utilisation de l'API Rockset dans votre application Maintenant que nous savons comment Rockset peut exécuter efficacement des requêtes sélectives sur notre ensemble de données, passons en revue les aspects pratiques de l'intégration des requêtes Rockset dans notre application. Rockset expose les services RESTful protégés par un jeton d'autorisation. Des SDK sont également disponibles pour les langages de programmation populaires. Cela en fait un excellent choix pour l'intégration d'applications sans serveur, car vous n'avez pas besoin de configurer une configuration de réseau privé compliquée pour accéder à votre base de données. Afin d'interagir avec l'API Rockset dans notre application, nous aurons besoin d'une clé API Rockset. Vous pouvez en créer une dans la de la console Rockset. Une fois cela fait, copiez sa valeur dans votre fichier serverless.yml et redéployez-la pour la rendre disponible pour votre application. section Clés API Remarque : par souci de simplicité, nous utilisons cette clé API comme variable d'environnement. Dans une application réelle, vous devez utiliser quelque chose comme ou pour stocker votre secret et éviter les variables d'environnement. Parameter Store AWS Secrets Manager Regardez notre pour voir comment nous interagissons avec l'API Rockset. L'initialisation de la classe prend en compte un objet client Rockset qui sera utilisé pour effectuer des appels à Rockset. classe TransactionService Dans la , nous avons la requête suivante pour interagir avec Rockset : méthode filterTransactions de notre classe de service 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, }, ], }, }); Il y a deux choses à noter à propos de cette interaction. Premièrement, nous utilisons des paramètres nommés dans notre requête lors du traitement des entrées des utilisateurs. Il s'agit d'une pratique courante avec les bases de données SQL pour éviter les attaques par injection SQL. Deuxièmement, le code SQL est mêlé au code de notre application et il peut être difficile à suivre au fil du temps. Même si cela peut fonctionner, il existe une meilleure solution. Au fur et à mesure que nous appliquerons notre prochain cas d'utilisation, nous verrons comment utiliser Rockset Query Lambdas dans notre application. Utiliser Rockset pour l'agrégation Jusqu'à présent, nous avons examiné les stratégies d'indexation de DynamoDB et Rockset en expliquant comment la base de données peut trouver un enregistrement individuel ou un ensemble d'enregistrements correspondant à un prédicat de filtre particulier. Par exemple, nous avons vu que DynamoDB vous pousse à utiliser une clé primaire pour rechercher un enregistrement, alors que l'index inversé de Rockset peut rechercher efficacement des enregistrements en utilisant des conditions de filtrage hautement sélectives. Dans cette dernière section, nous changerons un peu de sujet pour nous concentrer sur la disposition des données plutôt que sur l'indexation directe. En réfléchissant à la présentation des données, nous comparerons deux approches : basée sur les lignes et basée sur les colonnes. Les bases de données basées sur des lignes, comme leur nom l'indique, organisent leurs données sur le disque en lignes. La plupart des bases de données relationnelles, comme PostgreSQL et MySQL, sont des bases de données basées sur des lignes. Il en va de même pour de nombreuses bases de données NoSQL, comme DynamoDB, même si leurs enregistrements ne sont pas techniquement des « lignes » au sens d'une base de données relationnelle. Les bases de données basées sur des lignes conviennent parfaitement aux modèles d'accès que nous avons examinés jusqu'à présent. Lors de la récupération d'une transaction individuelle par son ID ou d'un ensemble de transactions selon certaines conditions de filtrage, nous souhaitons généralement que tous les champs reviennent pour chacune des transactions. Étant donné que tous les champs de l'enregistrement sont stockés ensemble, il faut généralement une seule lecture pour renvoyer l'enregistrement. (Remarque : quelques nuances à ce sujet arriveront un peu). L’agrégation est une tout autre histoire. Avec les requêtes d'agrégation, nous souhaitons calculer un agrégat : un nombre de toutes les transactions, une somme des totaux des transactions ou une dépense moyenne par mois pour un ensemble de transactions. Revenant à l'utilisateur de l'organisation Vandelay Industries, imaginez qu'il souhaite examiner les trois derniers mois et trouver les dépenses totales par catégorie pour chaque mois. Une version simplifiée de cette requête ressemblerait à ceci : 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 Pour cette requête, il peut y avoir un grand nombre d’enregistrements à lire pour calculer le résultat. Cependant, notez que nous n'avons pas besoin de beaucoup de champs pour chacun de nos enregistrements. Nous n’en avons besoin que de quatre : catégorie, transactionTime, organisation et montant - pour déterminer ce résultat. Ainsi, non seulement nous devons lire beaucoup plus d'enregistrements pour satisfaire cette requête, mais notre disposition basée sur les lignes lira également un certain nombre de champs inutiles pour notre résultat. À l’inverse, une disposition basée sur des colonnes stocke les données sur le disque en colonnes. L'index convergé de Rockset utilise un index en colonnes pour stocker les données dans une disposition basée sur des colonnes. Dans une présentation basée sur des colonnes, les données sont stockées ensemble par colonnes. Un enregistrement individuel est déchiqueté dans ses colonnes constitutives pour être indexé. Si ma requête doit effectuer une agrégation pour additionner l'attribut « montant » pour un grand nombre d'enregistrements, Rockset peut le faire en analysant simplement la partie « montant » de l'index en colonnes. Cela réduit considérablement la quantité de données lues et traitées par rapport aux dispositions basées sur des lignes. Notez que, par défaut, l'index en colonnes de Rockset ne classera pas les attributs dans une colonne. Étant donné que nous avons des cas d'utilisation destinés aux utilisateurs qui fonctionneront sur les données d'un client particulier, nous préférerions organiser notre index en colonnes par client afin de réduire la quantité de données à analyser lors de l'utilisation de l'index en colonnes. Rockset fournit pour vous aider. Avec le clustering, nous pouvons indiquer que nous voulons que notre index en colonnes soit clusterisé par l'attribut « organisation ». Cela regroupera toutes les valeurs de colonne par organisation dans les index en colonnes. Ainsi, lorsque Vandelay Industries effectue une agrégation de ses données, le processeur de requêtes de Rockset peut ignorer les parties de l'index en colonnes destinées aux autres clients. un clustering de données sur votre index en colonnes Comment l'index basé sur les lignes de Rockset facilite le traitement Avant de passer à l'utilisation de l'index en colonnes dans notre application, je souhaite parler d'un autre aspect de l'index convergé de Rockset. Plus tôt, j'ai mentionné que des mises en page basées sur les lignes étaient utilisées lors de la récupération d'enregistrements complets et j'ai indiqué que DynamoDB et nos requêtes à index inversé Rockset utilisaient ces mises en page. Ce n'est que partiellement vrai. L'index inversé présente certaines similitudes avec un index basé sur des colonnes, car il stocke les noms et les valeurs des colonnes ensemble pour des recherches efficaces par n'importe quel attribut. Chaque entrée d'index comprend un pointeur vers les ID des enregistrements qui incluent la combinaison de nom de colonne et de valeur donnée. Une fois le ou les identifiants pertinents découverts à partir de l'index inversé, Rockset peut récupérer l'enregistrement complet à l'aide de l'index de ligne. Rockset utilise le codage par dictionnaire et d'autres techniques de compression avancées pour minimiser la taille du stockage des données. Ainsi, nous avons maintenant vu comment l'indice convergé de Rockset s'articule : L' est utilisé pour analyser rapidement un grand nombre de valeurs dans une colonne particulière à des fins d'agrégation ; index basé sur les colonnes L' est utilisé pour les filtres sélectifs sur n'importe quel nom et valeur de colonne ; index inversé L' est utilisé pour récupérer tous les attributs supplémentaires pouvant être référencés dans la clause de projection. index basé sur les lignes Sous le capot, le puissant moteur d'indexation et d'interrogation de Rockset suit les statistiques sur vos données et génère des plans optimaux pour exécuter efficacement votre requête. Application : utilisation de Rockset Query Lambdas dans votre application Implémentons notre requête d'agrégation Rockset qui utilise l'index en colonnes. Pour notre requête précédente, nous avons écrit notre requête SQL directement dans l'API Rockset. Bien que ce soit la bonne chose à faire à partir de certaines interfaces utilisateur hautement personnalisables, il existe une meilleure option lorsque le code SQL est plus statique. Nous aimerions éviter de maintenir notre code SQL désordonné au milieu de notre logique applicative. Pour vous aider, Rockset dispose d'une fonctionnalité appelée Query Lambdas. Les Lambda de requête sont des requêtes nommées, versionnées et paramétrées qui sont enregistrées dans la console Rockset. Après avoir configuré une requête Lambda dans Rockset, vous recevrez un point de terminaison entièrement géré et évolutif pour la requête Lambda que vous pourrez appeler avec vos paramètres pour qu'il soit exécuté par Rockset. De plus, vous obtiendrez même des statistiques de surveillance pour chaque requête Lambda, afin que vous puissiez suivre les performances de votre requête Lambda lorsque vous apportez des modifications. Vous pouvez , mais configurons notre première requête Lambda pour gérer notre requête d'agrégation. Une . en savoir plus sur les requêtes Lambda ici procédure pas à pas complète peut être trouvée dans le référentiel d'applications Accédez à la de la console Rockset. Collez la requête suivante dans l'éditeur : section Éditeur de requête 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 Cette requête regroupera les transactions des trois derniers mois pour une organisation donnée en catégories en fonction de la catégorie donnée et du mois de la transaction. Ensuite, il additionnera les valeurs d’une catégorie par mois pour trouver le montant total dépensé au cours de chaque mois. Notez qu'il inclut un paramètre pour l'attribut « organisation », comme indiqué par la syntaxe « : organisation » dans la requête. Cela indique qu'une valeur d'organisation doit être transmise pour exécuter la requête. Enregistrez la requête en tant que requête Lambda dans la console Rockset. Ensuite, regardez le . Il appelle la requête Lambda par son nom et transmet la propriété « organisation » qui a été donnée par un utilisateur. code fetchTransactionsByCategoryAndMonth dans notre classe TransactionService Il s'agit d'un code beaucoup plus simple à gérer dans notre application. De plus, Rockset fournit un contrôle de version et une surveillance spécifique aux requêtes pour chaque requête Lambda. Cela facilite la maintenance de vos requêtes dans le temps et permet de comprendre comment les modifications apportées à la syntaxe des requêtes affectent les performances. Conclusion Dans cet article, nous avons vu comment utiliser DynamoDB et Rockset ensemble pour créer une expérience d'application rapide et agréable pour nos utilisateurs. Ce faisant, nous avons appris à la fois les fondements conceptuels et les étapes pratiques pour mettre en œuvre notre application. Tout d'abord, nous avons utilisé DynamoDB pour gérer les fonctionnalités de base de notre application. Cela inclut des modèles d'accès tels que la récupération d'un flux de transaction pour un client particulier ou l'affichage d'une transaction individuelle. Grâce à la stratégie de partitionnement basée sur la clé primaire de DynamoDB, il est capable de fournir des performances cohérentes à n'importe quelle échelle. Mais la conception de DynamoDB limite également sa flexibilité. Il ne peut pas gérer les requêtes sélectives sur des champs arbitraires ou des agrégations sur un grand nombre d'enregistrements. Pour gérer ces modèles, nous avons utilisé Rockset. Rockset fournit un index secondaire entièrement géré pour alimenter les applications gourmandes en données. Nous avons vu comment Rockset maintient un pipeline d'ingestion continu à partir de votre magasin de données principal qui indexe vos données dans un index convergé, qui combine l'indexation inversée, en colonnes et en lignes. En parcourant nos modèles, nous avons vu comment chacune des techniques d'indexation de Rockset fonctionnent ensemble pour gérer des expériences utilisateur agréables. Enfin, nous avons parcouru les étapes pratiques pour connecter Rockset à notre table DynamoDB et interagir avec Rockset dans notre application. Apparaît également . ici
