Comment penser dans les magasins de données plutôt que dans les bases de données?
Par exemple, Google App Engine utilise Google Datastore, pas une base de données standard, pour stocker des données. Quelqu'un a-t-il des conseils pour utiliser Google Datastore au lieu des bases de données? Il semble que j'ai formé mon esprit à penser à 100% dans les relations d'objets qui correspondent directement aux structures de table, et maintenant il est difficile de voir les choses différemment. Je peux comprendre certains des avantages de Google Datastore (par exemple, les performances et la capacité de distribuer des données), mais certaines bonnes fonctionnalités de base de données sont sacrifiées (par exemple, les jointures).
Quelqu'un qui a travaillé avec Google Datastore ou BigTable a-t-il de bons conseils pour travailler avec eux?
Il y a deux choses principales auxquelles s'habituer à propos de la banque de données App Engine par rapport aux bases de données relationnelles "traditionnelles":
- Le magasin de données ne fait aucune distinction entre les insertions et les mises à jour. Lorsque vous appelez put () sur une entité, cette entité est stockée dans le magasin de données avec sa clé unique, et tout ce qui a cette clé est remplacé. Fondamentalement, chaque type d'entité dans le magasin de données agit comme une énorme carte ou liste triée.
- L'interrogation, comme vous y avez fait allusion, est beaucoup plus limitée. Pas de jointures, pour commencer.
La chose clé à réaliser - et la raison derrière ces deux différences - est que Bigtable agit essentiellement comme un énorme dictionnaire ordonné. Ainsi, une opération put définit simplement la valeur d'une clé donnée - quelle que soit la valeur précédente de cette clé, et les opérations d'extraction sont limitées à l'extraction de clés uniques ou de plages de clés contiguës. Des requêtes plus sophistiquées sont rendues possibles avec des index, qui ne sont en fait que des tables, ce qui vous permet d'implémenter des requêtes plus complexes sous forme d'analyses sur des plages contiguës.
Une fois que vous avez absorbé cela, vous disposez des connaissances de base nécessaires pour comprendre les capacités et les limites de la banque de données. Des restrictions qui ont pu sembler arbitraires ont probablement plus de sens.
L'essentiel ici est que, bien que ce soient des restrictions sur ce que vous pouvez faire dans une base de données relationnelle, ces mêmes restrictions rendent pratique la mise à l'échelle du type d'ampleur que Bigtable est conçu pour gérer. Vous ne pouvez tout simplement pas exécuter le type de requête qui a l'air bien sur papier mais qui est atrocement lente dans une base de données SQL.
En termes de modification de la façon dont vous représentez les données, le plus important est le précalcul. Au lieu de faire des jointures au moment de la requête, précalculez les données et stockez-les dans la banque de données dans la mesure du possible. Si vous souhaitez choisir un enregistrement aléatoire, générez un nombre aléatoire et stockez-le avec chaque enregistrement. Il y a tout un livre de recettes de ce genre de trucs et astuces ici Edit: Le livre de cuisine n'existe plus.
La façon dont j'ai abordé le changement de mentalité est d'oublier complètement la base de données.
Dans le monde relationnel de la base de données, vous devez toujours vous soucier de la normalisation des données et de la structure de votre table. Abandonnez tout. Présentez simplement votre page Web. Disposez-les tous. Regardez-les maintenant. Vous y êtes déjà 2/3.
Si vous oubliez l'idée que la taille de la base de données est importante et que les données ne doivent pas être dupliquées, vous en êtes aux 3/4 et vous n'avez même pas eu à écrire de code! Laissez vos opinions dicter vos modèles. Vous n'avez plus besoin de prendre vos objets et de les rendre bidimensionnels comme dans le monde relationnel. Vous pouvez maintenant stocker des objets avec une forme.
Oui, c'est une explication simplifiée de l'épreuve, mais cela m'a aidé à oublier les bases de données et à faire une application. Jusqu'à présent, j'ai créé 4 applications App Engine en utilisant cette philosophie et il y en a d'autres à venir.
Je rigole toujours quand les gens sortent - ce n'est pas relationnel. J'ai écrit cellectr en Django et voici un extrait de mon modèle ci-dessous. Comme vous le verrez, j'ai des ligues gérées ou encadrées par des utilisateurs. Je peux d'une ligue obtenir toutes les managers, ou à partir d'un utilisateur donné, je peux rendre la ligue qu'elle entraîne ou manager.
Ce n'est pas parce qu'il n'y a pas de prise en charge de clé étrangère spécifique que vous ne pouvez pas avoir un modèle de base de données avec des relations.
Mes deux pence.
class League(BaseModel):
name = db.StringProperty()
managers = db.ListProperty(db.Key) #all the users who can view/edit this league
coaches = db.ListProperty(db.Key) #all the users who are able to view this league
def get_managers(self):
# This returns the models themselves, not just the keys that are stored in teams
return UserPrefs.get(self.managers)
def get_coaches(self):
# This returns the models themselves, not just the keys that are stored in teams
return UserPrefs.get(self.coaches)
def __str__(self):
return self.name
# Need to delete all the associated games, teams and players
def delete(self):
for player in self.leagues_players:
player.delete()
for game in self.leagues_games:
game.delete()
for team in self.leagues_teams:
team.delete()
super(League, self).delete()
class UserPrefs(db.Model):
user = db.UserProperty()
league_ref = db.ReferenceProperty(reference_class=League,
collection_name='users') #league the users are managing
def __str__(self):
return self.user.nickname
# many-to-many relationship, a user can coach many leagues, a league can be
# coached by many users
@property
def managing(self):
return League.gql('WHERE managers = :1', self.key())
@property
def coaching(self):
return League.gql('WHERE coaches = :1', self.key())
# remove all references to me when I'm deleted
def delete(self):
for manager in self.managing:
manager.managers.remove(self.key())
manager.put()
for coach in self.managing:
coach.coaches.remove(self.key())
coaches.put()
super(UserPrefs, self).delete()
Je suis venu du monde de la base de données relationnelle, puis j'ai trouvé cette chose Datastore. il a fallu plusieurs jours pour s'y accrocher. Eh bien, il y a certaines de mes conclusions.
Vous devez déjà savoir que Datastore est construit à l'échelle et c'est ce qui le sépare de RDMBS. pour mieux évoluer avec un grand ensemble de données, App Engine a effectué quelques modifications (certaines signifient beaucoup de modifications).
RDBMS VS DataStore
Structure
Dans la base de données, nous structurons généralement nos données dans des tables, des lignes qui se trouvent dans le magasin de données, elles deviennent types et entités .
Relations
Dans SGBDR, la plupart des gens suivent la relation un-à-un, plusieurs-à-un, plusieurs-à-plusieurs, dans Datastore, car il n'y a pas de "jointure" mais nous pouvons quand même atteindre notre normalisation en utilisant " ReferenceProperty" par exemple Exemple de relation un à un .
Index
Habituellement, dans RDMBS, nous créons des index comme la clé primaire, la clé étrangère, la clé unique et la clé d'index pour accélérer la recherche et améliorer les performances de notre base de données. Dans le magasin de données, vous devez créer au moins un index par type (il sera automatiquement générer que cela vous plaise ou non) car le magasin de données recherche votre entité sur la base de ces index et croyez-moi, c'est la meilleure partie , Dans le SGBDR, vous pouvez effectuer une recherche à l'aide d'un champ non indexé, mais cela prendra un certain temps, mais ce sera le cas. Dans Datastore, vous ne pouvez pas effectuer de recherche à l'aide d'une propriété non indexée.
Comptez
Dans RDMBS, il est beaucoup plus facile de compter (*) mais dans le magasin de données, veuillez ne pas le penser normalement (oui, il y a une fonction de comptage) car il a 1000 Limit et cela coûtera autant petite opération que l'entité qui n'est pas bonne mais nous avons toujours de bons choix, nous pouvons utiliser Shard Counters .
Contraintes uniques
Dans RDMBS, nous aimons cette fonctionnalité non? mais Datastore a sa propre façon. vous ne pouvez pas définir une propriété comme unique :(.
Requête
GAE Datatore fournit une meilleure fonctionnalité beaucoup COMME (Oh non! La banque de données n'a pas de mot-clé LIKE) SQL qui est GQL .
Insertion/mise à jour/suppression/sélection de données
. en termes de écriture, lecture, petites opérations (lecture Coûts des appels de magasin de données) et c'est là que la modélisation des données entre en action. vous devez minimiser ces opérations et faire fonctionner votre application. Pour réduire opération de lecture vous pouvez utiliser Memcache .
Jetez un œil à la documentation d'Objectify. Le premier commentaire au bas de la page dit:
"Bien, bien que vous ayez écrit ceci pour décrire Objectify, c'est aussi l'une des explications les plus concises du magasin de données Appengine lui-même que j'ai jamais lues. Merci."
Si vous avez l'habitude de penser aux entités mappées ORM, c'est essentiellement ainsi que fonctionne une banque de données basée sur une entité comme App Engine de Google. Pour quelque chose comme les jointures, vous pouvez regarder propriétés de référence . Vous n'avez pas vraiment besoin de vous soucier de savoir s'il utilise BigTable pour le backend ou autre chose car le backend est abstrait par les interfaces GQL et Datastore API.
La façon dont je regarde le magasin de données est, sorte identifie la table, en soi, et l'entité est une ligne individuelle dans la table. Si google devait sortir genre, c'est juste une grande table sans structure et vous pouvez vider tout ce que vous voulez dans une entité. En d'autres termes, si les entités ne sont pas liées à un type, vous pouvez à peu près avoir n'importe quelle structure à une entité et stocker dans un seul emplacement (sorte de gros fichier sans structure, chaque ligne a sa propre structure).
Maintenant, revenons au commentaire d'origine, google datastore et bigtable sont deux choses différentes, donc ne confondez pas google datastore avec le sens du stockage de données de la banque de données. Bigtable est plus cher que bigquery (principale raison pour laquelle nous n'y sommes pas allés). Bigquery a des jointures appropriées et un SGBDR comme le langage sql et son moins cher, pourquoi ne pas utiliser bigquery. Cela étant dit, bigquery a certaines limites, selon la taille de vos données que vous pourriez ou non rencontrer.
En outre, en termes de réflexion en termes de magasin de données, je pense que la déclaration appropriée aurait été "de penser en termes de bases de données NoSQL". Il y en a trop disponibles ces jours-ci, mais en ce qui concerne les produits Google, à l'exception de Google Cloud SQL (qui est mySQL), tout le reste est NoSQL.