J'ai touché petit à petit le magasin de données de GCP au cours des six derniers mois.
Prenons note des diverses sensations de toucher le magasin de données. Je voudrais le comparer avec DynamoDB, mais c'est presque une caractéristique de NoSQL. Il n'y avait pas beaucoup d'articles qui m'ont enseigné les directives de conception et les changements de pensée lorsque RDB-> KVS, alors je les ai résumés.
["NoSQL Guide for RDB Engineers"](http://www.amazon.co.jp/RDB%E6%8A%80%E8%A1%93%E8%80%85%E3%81%AE % E3% 81% 9F% E3% 82% 81% E3% 81% AENoSQL% E3% 82% AC% E3% 82% A4% E3% 83% 89-% E6% B8% A1% E9% 83% A8- % E5% BE% B9% E5% A4% AA% E9% 83% 8E / dp / 479804573X) Je me demande si c'est écrit dans un tel livre dans une certaine mesure, mais j'ai l'impression que Datastore n'a pas été mentionné. ..
Au fait, je touche de GAE / py.
Tout d'abord, trions les termes de base.
Nouvelles connaissances de base de la base de données Comprendre l'énorme magasin de données distribué Bigtable et Datastore de Google (4/12) Comme mentionné dans cet article,
| datastore | RDB |
|---|---|
| kind | table |
| entity | record |
| property | field |
Il semble.
J'ai résumé ce que j'avais pensé lors de la conception de la table. Fondamentalement, je pense que c'est un concept courant dans Datastore ou NoSQL sans schéma.
Datastore n'a pas le concept de table, mais gère plusieurs entités kind en un seul endroit. On dirait donc que le genre agit comme une table.
Au fait, GCP a appelé namespace? GAE? Il existe également un concept qui vous permet de créer des banques de données indépendantes pour le même projet.
Plusieurs types peuvent être mis à jour dans la transaction en même temps en les plaçant dans le groupe d'entités. Cependant, il semble qu'il existe une restriction selon laquelle seulement 1 / s environ peut être placé dans un groupe d'entités.
L'entité obtenir avec la clé est très rapide. Vous ne pouvez obtenir une propriété qu'après avoir obtenu une entité. Ainsi, la requête ne peut obtenir que la liste des clés, donc si vous émettez une requête normalement, il semble que le contenu soit retardé en interne.
Il y a un compromis pour l'intégrité.
Un put normal qui ne peut pas être inclus dans le groupe d'entités garantit l'intégrité conséquente. Cela ne reflète pas les résultats immédiatement et certaines requêtes renvoient un ancien contenu pendant un certain temps. (Commodité du nœud?) Son intégration dans un groupe d'entités garantit une forte cohérence au prix d'une fréquence de mise à jour limitée et de nouvelles informations peuvent être obtenues immédiatement.
Du point de vue de la gestion des données, cela semble très étrange, mais lors de la conception du magasin de données, il semble préférable de concevoir l'objet avec View, c'est-à-dire comment les données sont affichées et traitées.
En d'autres termes, il est nécessaire d'anticiper correctement les cas d'utilisation d'acquisition / mise à jour de données au stade de la conception. Par exemple, souhaitez-vous obtenir la liste des utilisateurs ou les données? Tel.
La raison est liée à la dénormalisation décrite ci-dessous, mais l'API prend de plus en plus de temps lors de l'émission d'un certain nombre de requêtes. C'est mauvais pour l'UX, et si vous utilisez GAE, il y a une limite d'une minute. Par conséquent, il semble préférable de penser que vous devriez apporter quelque chose à afficher ensemble en tant que données en premier lieu. Jetons les directives de conception dans RDB.
Contrairement à RDB, Datastore est presque impossible de traiter les agrégats. Par conséquent, de nombreux articles recommandaient une technique telle que le total, ou contenant des informations connues pour être mentionnées à l'avance dans tous les tableaux autant que possible.
Je pense personnellement que c'est le point le plus important. Si vous avez une recherche ou une requête, vous l'obtiendrez par requête, mais à la fin, KVS (bien que cela puisse être différent au sens strict) montre sa vraie valeur dans l'acquisition déclenchée par clé. La cohérence au moment du renouvellement est également garantie si la clé est acquise. Et comme je l'ai remarqué plus tard, je ne peux l'obtenir qu'avec la clé dans la transaction w
Je n'ai pas beaucoup pratiqué ça, mais je transpire Il est plus rapide d'obtenir la liste des clés, puis d'obtenir un certain nombre d'entités au lieu d'essayer d'obtenir toutes les propriétés. Si vous n'avez besoin que du nom, récupérez la clé avec l'option get et affichez-la.
J'ai recherché des articles qui pourraient être utiles lors de la conception de données. Ce sont tous de vieux articles, mais ils semblent être utiles dans une certaine mesure.
Cependant, il existe également des informations de contournement, de sorte que cette zone peut être inutile en raison de mises à jour. En particulier, si vous mettez une partie des informations de propriété dans la clé et obtenez la liste des clés, vous n'avez pas à regarder le contenu de l'entité, ce qui semble un peu spécial.
Il était facile de comprendre en quoi la méthode de conception est différente de RDB utilisant SQL du point de vue de la dénormalisation.
Ce qui est écrit:
Le blog de Satoshi Nakajima a également écrit sur Datastore. La dénormalisation est également recommandée ici, mais il était également facile de comprendre comment utiliser le groupe d'entités et la politique de conception. Cependant, j'ai eu l'impression que le problème de la vitesse de requête et le taux d'erreur élevé se sont considérablement améliorés depuis l'époque de ce blog.
Ce qui est écrit:
Il semble y avoir un moyen de diviser l'entité pour obtenir et mettre. (Je pense que ce genre est également différent) Cela peut ne pas être très pratique.
Ceci est le blog officiel de Google de l'année dernière, mais il est très utile pour commencer.
Recommended Posts