J'ai entendu dire que les performances des bases de données relationnelles non partagées telles que MySQL ou PostgreSQL "dépassaient" les 10 To.
Je soupçonne que des limites existent en tant que telles car on ne proposerait pas Netezza, Greenplum, ou Vertica, etc., mais j'aimerais demander si quelqu'un a ici une référence à un document de recherche ou à des études de cas formelles où ces limites sont quantifiées.
Réponses:
Il n’ya pas de réponse simple à votre question, mais voici quelques points à prendre en compte.
Premièrement, l’échelle n’est pas la seule chose à craindre. Ce que vous faites avec vos données est. Si vous disposez de 500 tables pour 30 To de données et que vous utilisez un protocole OLTP simple avec très peu de rapports, je ne pense pas que vous aurez trop de problèmes. Il existe des bases de données de 32 To sur PostgreSQL. Cependant, dans le même temps, les performances vont se dégrader quelque peu car il faut tout toucher au disque. De même, si vous disposez de 50 To pour des données mais que vous avez un jeu d'environ 100 Go, vous pouvez créer un serveur avec suffisamment de RAM pour conserver cette partie de la base de données en mémoire d'or.
D'un autre côté, si vous essayez de supprimer le mode (valeur la plus courante) de 1 To de données, le système que vous utilisez n'a pas d'importance, cela va être pénible avec ou sans éclatement. (Edit: Éclatement peut, en fait, aggraver ce problème . )
Les problèmes majeurs que vous rencontrerez avec d'énormes bases de données sur MySQL et PostgreSQL concernent le fait que ni l'un ni l'autre ne prennent en charge le parallélisme intra-requête. En d'autres termes, une requête est exécutée sous la forme d'un bloc unique par un seul thread et ne peut pas être décomposée ni exécutée séparément. Cela pose souvent problème lors de l'exécution de requêtes analytiques volumineuses sur de grandes quantités de données. C'est ici que Postgres-XC et Green Plum viennent à la rescousse car ils séparent le stockage de l'exécution et peuvent le faire au niveau du coordinateur. Notez que Postgres-XC et Green Plum utilisent essentiellement le sharding en interne, mais les coordinateurs appliquent la cohérence de manière globale.
Avec le parallélisme intra-requête, vous pouvez diviser la requête, faire en sorte que différents processeurs / canaux d'E / S de disque exécutent certaines parties et générer des rapports sur les éléments du jeu de résultats à assembler et à renvoyer à l'application. Là encore, cela est généralement plus utile pour les charges de traitement analytique que de traitement de transaction.
Deuxièmement, certains systèmes, tels que Vertica ou Greenplum, stockent des colonnes d’informations ensemble. Cela rend le système plus difficile à utiliser du point de vue OLTP et y réduit les performances, mais augmente considérablement les performances pour les charges de travail analytiques importantes. Il s’agit donc d’un compromis spécifique à la charge de travail.
La réponse est donc que, une fois que vous avez dépassé la taille de 1 à 2 To, vous pouvez être confronté à un certain nombre de compromis entre les systèmes et les charges de travail. Encore une fois, ceci est spécifique aux bases de données, à la taille des ensembles de travail, etc. Cependant, à ce stade, vous devez vraiment utiliser des systèmes de flocon de neige, c'est-à-dire uniques et adaptés à votre charge de travail.
Cela signifie bien entendu que les limites ne sont généralement pas quantifiables.
Edit : J'ai maintenant travaillé avec une base de données de 9 To qui gère un mélange de charges de travail d'aide à la décision et de traitement transactionnel dans PostgreSQL. Le plus gros défi est que si vous avez des questions qui touchent une grande partie de l'ensemble de données, vous devrez attendre un moment pour obtenir la réponse.
Cependant, si vous portez une attention particulière aux principes fondamentaux (y compris les index, l'autovacuum, leur fonctionnement bas niveau, etc.) et des ressources informatiques suffisantes, ceux-ci sont tout à fait gérables (et j'estime qu'ils le seraient tout à fait dans la plage des 30 To en Pg).
Edit2 : Une fois que vous vous dirigerez vers 100 To, ce qui fonctionnera dépendra de votre ensemble de données. Je travaille actuellement sur un système qui ne sera pas adapté à cette plage car il atteindra d'abord la limite de 32 To par table dans PostgreSQL.