Apparemment, la raison de la bigtable architecture a trait à la difficulté à mettre en œuvre des bases de données relationnelles lorsque vous traitez avec le nombre massif de serveurs que Google doit traiter.
mais techniquement parlant ce qui rend exactement difficile pour des bases de données relationnelles à l'échelle?
Dans les centres de données d'entreprise de grandes entreprises, ils semblent être capables de le faire avec succès, donc je me demande pourquoi il n'est pas possible de simplement le faire dans un ordre de grandeur plus grand afin de pouvoir augmenter sur les serveurs de Google. < / p>
3 Réponses :
Lorsque vous effectuez une requête qui implique des relations physiquement distribuées, vous devez tirer ces données pour chaque relation dans un endroit central. Qui ne fera évidemment pas bien à bien les volumes de données.
Un serveur RDBMS de puits de puits effectuera la majorité de ses requêtes sur des pages à chaud dans la RAM, avec peu de disque physique ou d'E / S réseau.
Si vous êtes contraint par le réseau E / S, les avantages des données relationnelles deviennent diminués.
La principale raison telle que indiquée est l'emplacement physique et le réseau IO. De plus, même les grandes entreprises gèrent une fraction des données qui traitent.
Pensez à l'index sur une base de données standard, peut-être quelques fribes ... Les moteurs de recherche ont besoin de recherches de texte rapides, sur les grands champs de texte.
En plus de la réponse de Mitch, il y a une autre facette: WebApps sont généralement mal adaptés à des bases de données relationnelles. Les bases de données relationnelles mettent l'accent sur la normalisation - essentiellement, ce qui facilite les écritures, mais se lit plus difficile (en termes de travail effectué, pas nécessairement pour vous). Cela fonctionne très bien pour OLAP, les situations de type de requête ad-hoc, mais pas si bien pour les webapps, qui sont généralement massivement pondérés en faveur des lectures sur les écrivies.
La stratégie prise par des bases de données non relationnelles telles que BigTable est l'inverse: dénormaliser, faire des lectures beaucoup plus faciles, au coût de fabrication d'écrires plus cher.
Je conviens que la plupart des applications Web impliquent plus de lecture que la saisie de l'utilisateur ou la mise à jour de l'application des données. Mais je ne comprends pas ce que vous voulez dire lorsque vous dites que les écritures sont "plus faciles (en termes de travail effectué)" dans un SGDBD normalisé? Je pense que le magasin de données d'applications du moteur est plus facile en termes de travail effectué car une clé unique identifie toutes les entités et une mise à jour équivaut à un insert en raison du caractère de type dictionnaire du magasin de données. Mettre et récupérer à partir d'un dictionnaire est aussi facile que possible autant que le travail fait, je penserais.
@Pacman: vous oubliez tout le travail réellement fait. L'index est le grand roi du magasin de données. Lorsque vous ajoutez une entité au magasin de données, il effectue une énorme quantité de données de réplication de travail afin que si vous souhaitez obtenir une propriété, vous pouvez le faire rapidement. Il écrit fondamentalement des index pour chaque propriété, sur chaque entité, deux fois (ASC et DESC), pour toutes les données que vous stockez (peut-être pas les nouveaux Big Blobs, pas sûr). C'est ce qui prend si longtemps pour les écrit, mais permet également de lire des lectures rapides sur une balance d'hébergement en tête. Je suggérerais d'obtenir un bon livre Appengine, car il est important lors de la conception de GAE.