Arrière-plan
Le conception de desk distinctive for DynamoDB simplifie l’structure requise pour le stockage des données dans DynamoDB. Au lieu d’avoir plusieurs tables pour chaque kind d’enregistrement, vous pouvez combiner les différents varieties de données dans une seule desk. Cela fonctionne automotive DynamoDB est succesful de stocker des tables très larges avec un schéma variable. DynamoDB prend également en cost les objets imbriqués. Cela permet aux utilisateurs de combiner PK comme clé de partition, SK comme clé de tri, la combinaison des deux devenant une clé primaire composite. Les colonnes communes peuvent être utilisées dans tous les varieties d’enregistrement, comme une colonne de résultats ou une colonne de données qui stocke du JSON imbriqué. Ou les différents varieties d’enregistrements peuvent avoir des colonnes totalement différentes. DynamoDB prend en cost les deux modèles, voire un mélange de colonnes partagées et de colonnes disparates. Souvent, les utilisateurs qui suivent le modèle de desk distinctive utiliseront le PK comme clé primaire dans un SK qui fonctionne comme un espace de noms. Un exemple de ceci :
Notez que le PK est le même pour les deux enregistrements, mais le SK est différent. Vous pouvez imaginer un modèle à deux tables comme celui-ci :
et
Bien qu’aucun de ces modèles de données ne soit réellement un bon exemple de modélisation de données appropriée, l’exemple représente toujours l’idée. Le modèle de desk distinctive utilise PK comme clé primaire dans l’espace de noms d’un SK.
Remark utiliser le modèle de desk distinctive dans Rockset
Rockset est une base de données d’analyse en temps réel souvent utilisée conjointement avec DynamoDB. Il se synchronise avec les données dans DynamoDB pour offrir un moyen easy d’effectuer des requêtes pour lesquelles DynamoDB est moins adapté. En savoir plus sur le weblog d’Alex DeBrie sur Requêtes de filtrage et d’agrégation DynamoDB à l’aide de SQL sur Rockset.
Rockset a 2 façons de créer des intégrations avec DynamoDB. La première est de utiliser des RCU pour analyser la desk DynamoDB, et une fois l’analyse initiale terminée, Rockset go well with les flux DynamoDB. L’autre méthode utilise l’exportation DynamoDB vers S3 pour exporter d’abord la desk DynamoDB vers S3, effectuer une ingestion en masse à partir de S3, puis, après l’exportation, Rockset commencera à suivre les flux DynamoDB. La première méthode est utilisée lorsque les tables sont très petites, < 5 Go, et la seconde est beaucoup plus performante et fonctionne pour les tables DynamoDB plus grandes. L'une ou l'autre méthode est appropriée pour la méthode de desk distinctive.
Rappel : Les cumuls ne peuvent pas être utilisés sur DDB.
Une fois l’intégration configurée, vous avez quelques choices à prendre en compte lors de la configuration des collections Rockset.
Méthode 1 : Assortment et vues
La première et la plus easy consiste à ingérer toute la desk dans une seule assortment et à implémenter des vues au-dessus de Rockset. Ainsi, dans l’exemple ci-dessus, vous auriez une transformation SQL qui ressemble à :
-- new_collection
choose i.* from _input i
Et vous construiriez deux vues au-dessus de la assortment.
-- person view
Choose c.* from new_collection c the place c.SK = 'Consumer';
et
--class view
choose c.* from new_collection c the place c.SK='Class';
Il s’agit de l’approche la plus easy et nécessite le moins de connaissances sur les tables, le schéma de desk, les tailles, les modèles d’accès, and so forth. Généralement, pour les tables plus petites, nous commençons ici. Rappel : les vues sont du sucre syntaxique et ne matérialiseront pas les données, elles doivent donc être traitées comme si elles faisaient partie de la requête à chaque exécution de la requête.
Méthode 2 : Assortment et vues en cluster
Cette méthode est très similaire à la première méthode, sauf que nous implémenterons le clustering lors de la création de la assortment. Sans cela, lorsqu’une requête qui utilise l’index de colonne de Rockset est exécutée, la assortment entière doit être analysée automotive il n’y a pas de séparation réelle des données dans l’index de colonne. Le clustering n’aura aucun affect sur l’index inversé.
La transformation SQL ressemblera à :
-- clustered_collection
choose i.* from _input i cluster by i.SK
La mise en garde ici est que le clustering consomme plus de ressources pour l’ingestion, de sorte que l’utilisation du processeur sera plus élevée pour les collections en cluster par rapport aux collections non en cluster. L’avantage est que les requêtes peuvent être beaucoup plus rapides.
Les vues seront les mêmes qu’avant :
-- person view
Choose c.* from new_collection c the place c.SK = 'Consumer';
et
--class view
choose c.* from new_collection c the place c.SK='Class';
Méthode 3 : Collections séparées
Une autre méthode à prendre en compte lors de la création de collections dans Rockset à partir d’un modèle de desk distinctive DynamoDB consiste à créer plusieurs collections. Cette méthode nécessite plus de configuration initiale que les deux méthodes précédentes, mais offre des avantages considérables en termes de performances. Ici, nous utiliserons le the place clause de notre transformation SQL pour séparer les SK de DynamoDB en collections distinctes. Cela nous permet d’exécuter des requêtes sans implémenter le clustering, ou d’implémenter le clustering à l’intérieur d’un SK individuel.
-- Consumer assortment
Choose i.* from _input i the place i.SK='Consumer';
et
-- Class assortment
Choose i.* from _input i the place i.SK='Class';
Cette méthode ne nécessite pas de vues automotive les données sont matérialisées dans des collections individuelles. Ceci est très utile lors de la séparation de très grandes tables où les requêtes utiliseront des mélanges d’index inversé et d’index de colonne de Rockset. La limitation ici est que nous allons devoir effectuer une exportation et un flux distincts à partir de DynamoDB pour chaque assortment que vous souhaitez créer.
Méthode 4 : mélange de collections séparées et de regroupement
La dernière méthode à discuter est la combinaison des méthodes précédentes. Ici, vous diviseriez les grands SK en collections séparées et utiliseriez le clustering et une desk combinée avec des vues pour les plus petits SK.
Prenez cet ensemble de données :
Vous pouvez créer deux collections ici :
-- user_collection
choose i.* from _input i the place i.SK='Consumer';
et
-- combined_collection
choose i.* from _input i the place i.SK != 'Consumer' Cluster By SK;
Et puis 2 vues au-dessus de Combined_Collection :
-- class_view
choose * from combined_collection the place SK='Class';
et
-- transportation_view
choose * from combined_collection the place SK='Transportation';
Cela vous donne l’avantage de séparer les grandes collections des petites collections, tout en gardant la taille de votre assortment plus petite, ce qui permet d’ajouter d’autres SK plus petites à la desk DynamoDB sans avoir à recréer et à réintégrer les collections. Il permet également la plus grande flexibilité pour les performances des requêtes. Cette choice est associée à la surcharge opérationnelle la plus importante pour la configuration, la surveillance et la upkeep.
Conclusion
La conception de desk distinctive est une method de modélisation de données populaire dans DynamoDB. Ayant soutenu de nombreux utilisateurs de DynamoDB Grâce au développement et à la manufacturing de leurs functions d’analyse en temps réel, nous avons détaillé plusieurs méthodes pour organiser votre modèle de desk distinctive DynamoDB dans Rockset, afin que vous puissiez sélectionner la conception qui convient le mieux à votre cas d’utilisation spécifique.
