Comment penser dans les magasins de données au lieu des bases de données?

Question

À titre d'exemple, Google App Engine utilise Google Datastore, et non une base de données standard, pour stocker des données. Quelqu'un a-t-il des conseils pour utiliser Google Datastore au lieu de bases de données? Il semble que j'ai entraîné mon esprit à penser à 100% aux relations d'objet mappées directement aux structures de table, et maintenant il est difficile de voir quoi que ce soit autrement. Je peux comprendre certains des avantages de Google Datastore (performances et capacité de distribution des données, par exemple), mais certaines 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?

Answer 1

Il faut principalement s'habituer au magasin 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 () à une entité, cette dernière est stockée dans le magasin de données avec sa clé unique et tout élément contenant cette clé est écrasé. En gros, chaque type d’entité du magasin de données se comporte comme une énorme carte ou une liste triée.
• Comme vous l'avez dit, l'interrogation est beaucoup plus limitée. Pas de jointure, pour commencer.

La chose essentielle à réaliser - et la raison derrière ces deux différences - est que Bigtable agit fondamentalement comme un énorme dictionnaire ordonné. Ainsi, une opération de vente définit simplement la valeur d'une clé donnée - indépendamment de la valeur précédente de cette clé, et les opérations d'extraction sont limitées à l'extraction de clés simples ou de plages de clés contiguës. Des index plus sophistiqués sont possibles, ils ne sont en fait que des tables, ce qui vous permet d'implémenter des requêtes plus complexes en tant qu'analyses sur des plages contiguës.

Une fois que vous avez assimilé cette information, vous disposez des connaissances de base nécessaires pour comprendre les capacités et les limites du magasin de données. Les restrictions qui peuvent sembler arbitraires ont probablement plus de sens.

L’important, c’est que bien qu’il s’agisse de restrictions sur ce que vous pouvez faire dans une base de données relationnelle, c’est ce qui fait qu’il est pratique de s’adapter à la taille que Bigtable est conçue pour gérer. Vous ne pouvez tout simplement pas exécuter le type de requête qui semble bien sur le papier mais qui est atrocement lente dans une base de données SQL.

Pour ce qui est de changer 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 le magasin de données autant que possible. Si vous souhaitez sélectionner un enregistrement aléatoire, générez un nombre aléatoire et enregistrez-le avec chaque enregistrement. Il existe tout un livre de recettes de ce genre de trucs et astuces ici Modifier: La Le livre de cuisine n'existe plus.

Answer 2

La façon dont je me suis mis à changer d'avis 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. Fossé tout. Juste mettre en page votre page Web. Disposez-les tous. Maintenant regarde-les. Vous êtes déjà 2/3 là-bas.

Si vous oubliez l'idée que la taille de la base de données compte et que les données ne doivent pas être dupliquées, vous êtes alors 3/4 et vous n'avez même pas besoin d'écrire de code! Laissez vos vues dicter vos modèles. Vous n'êtes plus obligé de prendre vos objets et de les transformer en 2 dimensions 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 elle m’a aidé à oublier les bases de données et à juste faire une application. À ce jour, j'ai créé 4 applications App Engine en utilisant cette philosophie et il y en a d'autres à venir.

Answer 3

Je ris toujours lorsque les gens sortent - ce n’est pas relationnel. J'ai écrit cellectr dans django et voici un extrait de mon modèle ci-dessous. Comme vous le verrez, j'ai des ligues gérées ou dirigées par des utilisateurs. Je peux d'une ligue obtenir tous les gérants, ou d'un utilisateur donné je peux retourner la ligue qu'elle entraîne ou gérera.

Ce n’est pas parce qu’il n’ya pas de support spécifique pour les clés étrangères que vous ne pouvez pas avoir de modèle de base de données avec des relations.

Mes deux sous.

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()    

Answer 4

Je viens du monde de la base de données relationnelle, puis j’ai trouvé ce magasin de données. il a fallu plusieurs jours pour y arriver. Eh bien, il y a certaines de mes conclusions.

Vous devez déjà savoir que le magasin de données est construit à l’échelle et que c’est ce qui le sépare de RDMBS. Afin de mieux évoluer avec de grands ensembles de données, App Engine a apporté quelques modifications (certaines signifiant beaucoup de modifications).

Stock de données VS. RDBMS
Structure
Dans la base de données, nous structurons habituellement nos données dans Tables, les lignes qui se trouvent dans le magasin de données, qui devient Types et entités .

Relations
Dans le SGBDR, la plupart des gens suivent la relation un à un, plusieurs à plusieurs, plusieurs à plusieurs, dans le magasin de données, car elle n’a pas de "jointure". mais nous pouvons quand même atteindre notre normalisation en utilisant " ReferenceProperty ". par exemple. Relation one-to-one Exemple .

index
En règle générale, dans RDMBS, nous créons des index tels que clé primaire, clé étrangère, clé unique et 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 générer que cela vous plaise ou non) car le datastore cherche 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 de champs autres que des index, bien que cela prenne un certain temps mais que ce soit le cas. Dans le magasin de données, vous ne pouvez pas utiliser une propriété non indexée.

Count
Dans RDMBS, il est beaucoup plus facile de compter (*), mais dans le magasin de données, veuillez ne pas même le penser de manière normale (oui, il existe une fonction de comptage) car il a 1000 limites et le coût sera aussi élevé une petite opération comme entité qui n'est pas bonne, mais nous avons toujours de bons choix, nous pouvons utiliser Compteurs de fragments .

contraintes uniques
Dans RDMBS, nous aimons cette fonctionnalité, non? mais Datastore a sa propre manière. vous ne pouvez pas définir une propriété comme unique :(.

Requête
GAE Datatore fournit une meilleure fonctionnalité bien plus encore LIKE (Oh no! le magasin de données n'a pas de mot-clé LIKE) SQL, GQL .

Insertion de données / Mise à jour / Supprimer / Sélectionner
C'est ce qui nous intéresse tous. Comme dans RDMBS, nous avons besoin d'une requête pour insérer, mettre à jour, supprimer et sélectionner, comme le SGBDR, Datastore a mis, supprime, obtient (ne vous excitez pas trop) car Datastore a mis ou obtenu en termes de Écrire, lire, petites opérations (Lire Coûts pour les 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 garder votre application en marche. Pour réduire la opération de lecture , vous pouvez utiliser Memcache .

Answer 5

Consultez la documentation Objectify. Le premier commentaire au bas de la page dit:

"Nice, bien que vous ayez écrit cela pour décrire Objectify, c’est également l’une des explications les plus concises sur le magasin de données appengine que j’ai jamais lu. Merci. "

https://github.com/objectify/objectify/wiki/Concepts

Answer 6

Si vous avez l'habitude de penser aux entités mappées ORM, vous constaterez ainsi le fonctionnement d'un magasin de données basé sur des entités, comme Google App Engine. Pour les jointures, vous pouvez consulter propriétés de référence . Vous n'avez pas vraiment besoin de vous demander s'il utilise BigTable pour le backend ou autre chose puisque le backend est extrait par les interfaces GQL et Datastore API.

Answer 7

La façon dont je considère le magasin de données est la suivante: type identifie la table, en soi, et l'entité est une ligne individuelle dans la table. Si Google devait prendre la forme d'une table unique et sans structure, vous pouvez vider ce que vous voulez dans une entité. En d’autres termes, si les entités ne sont pas liées à un type, vous pouvez quasiment avoir une structure pour une entité et la stocker dans un emplacement (type 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 de stockage de données de datastore. Bigtable est plus cher que bigquery (raison principale pour laquelle nous ne l’avons pas fait). Bigquery a des jointures appropriées et SGBDR comme le langage SQL et son meilleur marché, pourquoi ne pas utiliser bigquery. Cela étant dit, bigquery a certaines limites, en fonction de la taille de vos données, que vous les rencontriez ou non.

De même, en termes de stockage de données, je pense qu'une déclaration appropriée aurait été "pensée en termes de bases de données NoSQL". Ils sont trop nombreux sur le marché ces jours-ci, mais en ce qui concerne les produits Google, à l'exception de Google Cloud SQL (MySQL), tout le reste est NoSQL.

Answer 8

Étant enraciné dans le monde des bases de données, un magasin de données serait un tableau géant (d'où le nom "bigtable"). BigTable est un mauvais exemple car il fait beaucoup d'autres choses qu'une base de données typique pourrait ne pas faire, et pourtant c'est toujours une base de données. Si vous savez que vous avez besoin de créer quelque chose comme "Bigtable" de Google, il y a de fortes chances que vous utilisiez une base de données standard. Ils en ont besoin car ils manipulent des quantités insensées de données et de systèmes, et aucun système disponible dans le commerce ne peut vraiment faire le travail de la manière exacte dont il peut démontrer qu’il a besoin du travail.

(référence bigtable: http://fr.wikipedia.org/wiki/BigTable )