Pro de bases de données comme BigTable, SimpleDB

Question

De nouveaux paradigmes de banques de données scolaires, tels que Google BigTable et Amazon SimpleDB, sont spécialement conçus pour l'évolutivité, entre autres. En gros, le refus des jointures et la dénormalisation sont les moyens utilisés pour y parvenir.

Dans ce sujet , toutefois, le consensus semble être que tous se rejoignent les tables ne doivent pas forcément être trop chères et la dénormalisation est "surestimée" dans une certaine mesure Pourquoi, alors, ces systèmes mentionnés ci-dessus interdisent-ils les jointures et regroupent-ils tout dans une seule table pour atteindre une évolutivité? Est-ce que ce sont les volumes de données qu'il faut stocker dans ces systèmes (plusieurs téraoctets)?
Les règles générales pour les bases de données ne s'appliquent-elles tout simplement pas à ces échelles? Est-ce parce que ces types de bases de données sont spécialement conçus pour stocker de nombreux objets similaires?
Ou me manque-t-il une plus grande image?

Answer 1

Les bases de données distribuées ne sont pas aussi naïves que le suppose Orion. il y a eu pas mal de travail sur l'optimisation de requêtes entièrement relationnelles sur des jeux de données distribués. Vous voudrez peut-être regarder ce que font des sociétés comme Teradata, Netezza, Greenplum, Vertica, AsterData, etc. (Oracle a enfin pris part au jeu avec son annonce récente; Microsoft a acheté sa solition au nom de la société appelée auparavant DataAllegro).

Cela étant dit, lorsque les données sont transposées en téraoctets, ces problèmes deviennent très simples. Si vous n'avez pas besoin des garanties strictes de transactionnalité et de cohérence que vous pouvez obtenir des RDBM, il est souvent beaucoup plus facile de dénormaliser et de ne pas faire de jointures. Surtout si vous n'avez pas besoin de faire beaucoup de références croisées. Surtout si vous ne faites pas d’analyse ad-hoc, mais que vous avez besoin d’un accès programmatique avec des transformations arbitraires.

La dénormalisation est surestimée. Ce n’est pas parce que c’est ce qui se passe avec 100 Tera que tous les développeurs qui n’ont jamais pris la peine de se renseigner sur les bases de données et qui ont des difficultés à interroger un ou deux millions de lignes à cause de problèmes de planification de schéma et d’optimisation des requêtes .

Mais si vous êtes dans la gamme des 100 Tera, absolument ...

Oh, l’autre raison pour laquelle ces technologies attirent l’attention: les gens découvrent que certaines choses n’ont jamais appartenu à la base de données, et se rendent compte qu’ils ne traitent pas de relations dans leur domaine particulier, mais avec paires clé-valeur de base. Pour les choses qui n'auraient pas dû être dans une base de données, il est tout à fait possible que la structure Map-Reduce, ou un système de stockage persistant, éventuellement cohérent, soit la solution.

À une échelle moins globale, je recommande fortement BerkeleyDB pour ce type de problèmes.

Answer 2

Je ne les connais pas trop (je ne lis que le même blog / nouvelles / exemples que tout le monde), mais j’ai le sentiment qu’ils ont choisi de sacrifier un grand nombre des fonctionnalités de base de données relationnelles normales dans le nom. d'évolutivité - je vais essayer d'expliquer.

Imaginez que votre table de données comporte 200 lignes.

Dans le centre de données de Google, 50 de ces lignes sont stockées sur le serveur A, 50 sur B et 100 sur le serveur C. De plus, le serveur D contient des copies redondantes des données des serveurs A et B, et le serveur E contient des copies redondantes des données sur serveur C.

(Dans la vraie vie, je ne sais pas combien de serveurs seraient utilisés, mais il est configuré pour gérer plusieurs millions de lignes, alors j'en imagine plusieurs).

Pour "sélectionner * où name = 'orion'", l'infrastructure peut envoyer cette requête à tous les serveurs et agréger les résultats obtenus. Cela leur permet de s’adapter à peu près linéairement sur autant de serveurs qu’ils le souhaitent (pour info, c’est à peu près ce que mapreduce est)

Cela signifie toutefois que vous avez besoin de faire certains compromis.

Si vous deviez créer une jointure relationnelle sur certaines données, où elles étaient réparties sur 5 serveurs, chacun de ces serveurs devrait extraire des données les uns des autres pour chaque ligne . Essayez de faire cela lorsque vous avez 2 millions de lignes réparties sur 10 serveurs.

Ceci conduit à un compromis # 1 - Aucune jointure.

De plus, en fonction de la latence du réseau, de la charge du serveur, etc., certaines de vos données peuvent être sauvegardées instantanément, mais d’autres peuvent prendre une seconde ou deux. Encore une fois, lorsque vous avez des dizaines de serveurs, cela devient de plus en plus long. L’approche normale selon laquelle «tout le monde attend que le gars le plus lent ait fini» n’est plus acceptable.

Cela conduit à un compromis # 2 - Vos données peuvent ne pas toujours être immédiatement visibles après leur écriture.

Je ne sais pas quels autres compromis il y a à faire, mais ce sont les deux principaux. 2.

Answer 3

Donc, ce que je comprends, c’est que l’ensemble "denormalize, no join" la philosophie existe, non pas parce que les jointures elles-mêmes ne s'adaptent pas aux grands systèmes, mais parce qu'elles sont pratiquement impossibles à implémenter dans des bases de données distribuées.

Cela semble assez raisonnable lorsque vous stockez des données largement invariantes d’un seul type (Google, par exemple). Suis-je sur la bonne voie ici?

Answer 4

Si vous parlez de données virtuellement en lecture seule, les règles changent. La dénormalisation est plus difficile dans les situations où les données changent, car le travail requis est accru et le verrouillage pose davantage de problèmes. Si les données changent à peine, la dénormalisation n’est plus un problème.

Answer 5

Novaday Vous devez rechercher davantage d’environnement interopérationnel pour les bases de données. Plus fréquemment, vous n'avez pas besoin uniquement de bases de données relationnelles, telles que MySQL ou MS SQL, mais également de batteries de données Big Data telles que Hadoop ou de bases de données non relationnelles telles que MongoDB. Dans certains cas, toutes ces bases de données seront utilisées dans une solution, de sorte que leurs performances doivent être aussi égales que possible à l'échelle macro. Cela signifie que vous ne pourrez plus utiliser Azure SQL en tant que base de données relationnelle et une machine virtuelle avec 2 cœurs et 3 Go de RAM pour MongoDB. Vous devez faire évoluer votre solution et utiliser DB en tant que service lorsque cela est possible (si ce n’est pas possible, créez votre propre cluster dans un nuage).