Parition d'une table sur plusieurs nœuds physiques

Question

Je travaille donc actuellement sur un projet qui implique la collecte et le stockage d'énormes jeux de données (pour ce que j'ai l'habitude de faire). Les données sont essentiellement constituées de méta-informations, puis de valeurs réelles (où les valeurs sont orientées dans le temps). La méta-information elle-même est relativement grande, mais rien d'énorme, je dirais probablement qu'elle va augmenter la taille de la ligne 10-50 millions au cours des deux prochaines années. Cela me semble gérable, et un seul SQL Server costaud devrait suffire pour fournir un accès rapide à ces données s'il est indexé correctement (et les données sont très faciles à indexer, avec des limites très définies) ...

Cependant , les données de tendance est une histoire complètement différente. En un an, nous allons TRES facilement tirer 40-50 millions de lignes chaque jour, et cela pourrait raisonnablement doubler chaque année pour les 3 ou 4 prochaines années.

Ces données de tendance ont également des limites très définies qui les diviseraient en beaucoup plus gros blocs de taille gérable. J'espère pouvoir mettre en place un mécanisme de partitionnement qui répartirait ces données sur plusieurs nœuds de base de données physiques. Les données sont essentiellement toutes contenues dans une seule table. J'ai regardé dans le partitionnement de table de SQL Server, mais n'a pas pu trouver un moyen de répartir les données sur plusieurs serveurs.

Ma question est de savoir s'il existe une façon «relativement simple» d'implémenter le partitionnement de table sur plusieurs nœuds physiques. J'ai aussi passé un peu de temps à regarder Sql Server PDW, mais il est difficile de trouver des informations en ligne, et je ne veux pas poursuivre jusqu'à ce que j'ai établi qu'il n'y a pas de moyen simple de mettre en œuvre ce type de solution dans SQL Server.

Tout conseil serait grandement apprécié ...

Answer 1

Je ne suis pas expert en la matière, mais je crois que ce que vous cherchez peut-être est la base de données « sharding ». Il y a une analyse intéressante des problèmes et des avantages de sharding here. En fin de compte, la mise en œuvre d'une conception «fragmentée» risque d'être très coûteuse, mais si vos données ne peuvent pas être gérées dans une seule base de données, cela pourrait être une bonne solution.

Il y a aussi une petite quantité d'informations sur la page Wikipedia qui comprend une liste de logiciels qui prend en charge les tessons (par exemple, la mise en veille prolongée ORM)