Système de stockage hautement simultané

Imaginez que votre exigence est que vous ayez 3 énormes tables (données structurées) avec disons 30 milliards de lignes dans chacune (taille totale de 4 To) et vos nombreux utilisateurs simultanés (qui sont des threads OS parallèles sur des machines LAN distantes) devront lire une partie de les données via leurs requêtes SELELCT WHERE GROUPBY et hautement simultanées, par exemple 10 000 lectures simultanées en même temps et les utilisateurs doivent également insérer (pas de mise à jour) des données dans ces tables très simultanées également comme 2000 écrivains simultanés (partout sur le réseau LAN du centre de données) . Les utilisateurs voudraient lire et insérer le plus rapidement possible dans ce stockage où chaque lecture et écriture se produira dans une plage de ms à 1 seconde.

Quelles technologies recommandez-vous pour satisfaire une telle exigence? Y a-t-il un stockage de données ou un magasin de valeurs clés qui pourrait le faire? Le cloud n'est PAS une option.

Quelques clarifications:

Les utilisateurs n'ont PAS à voir les données immédiatement et la cohérence éventuelle est acceptable. Les données sont accessibles via n'importe quel pilote que le stockage peut fournir et les utilisateurs ne sont à nouveau que des threads exécutés sur des machines distantes du centre de données. Les requêtes sont principalement comme SELECT WHERE GROUPBY.

Les données sont au format tabulaire et chaque ligne fait environ 60 octets.

Aucune option cloud où je ne peux pas utiliser DynamoDB ou des solutions similaires. Je dois pouvoir l'héberger en interne dans le centre de données.

Toutes les données des tables peuvent être lues tout le temps et le modèle d'utilisation est imprévisible. Il n'y a pas de jointure ou de requête super longue. Aucun DR requis mais un HA raisonnable est requis mais cela n'a pas besoin d'être sophistiqué. Chaque lecteur reçoit un lot de lignes en fonction de sa clause where et les lignes ne sont pas vraiment liées. Nous pouvons probablement avoir une longueur fixe pour chaque ligne, mais j'espère que la couche de stockage s'en souciera.

De plus, ma plus grande préoccupation concerne toutes ces écritures simultanées qui se produisent avec des lectures simultanées.

Vos idées à ce sujet sont très appréciées.

Et plus encore, j'ai trois de ces tables avec chacune 30 milliards de lignes contenant différents types d'objets

Si la cohérence éventuelle est acceptable et que toutes vos requêtes sont des agrégats, alors un système OLAP à faible latence peut fonctionner pour vous. Votre exigence ressemble un peu à une plateforme de trading algorithmique. Ce type d'architecture est souvent utilisé dans les systèmes de salle des marchés qui doivent effectuer des calculs d'analyse statistique agrégés sur des données à jour.

Si vous pouvez partitionner vos données par date et que les anciennes lignes ne sont pas mises à jour, vous pouvez créer un système OLAP hybride à l'aide d'un serveur OLAP conventionnel tel que les services Microsoft Analysis soutenus par une plate-forme RDBMS ordinaire. Il devrait être possible de faire face à ~ 4 To de données et SQL Server et SSAS feront des clusters de disques partagés. Des systèmes OLAP similaires (par exemple Oracle / Hyperion Essbase) sont disponibles auprès d'autres fournisseurs.

Les serveurs OLAP fonctionnent en conservant les données dans un magasin natif, ainsi que les agrégats. La plupart prendront en charge les données partitionnées. En outre, la plupart fonctionnent également en mode ROLAP, où ils émettent des requêtes sur la base de données sous-jacente. La chose importante à noter est que la stratégie de stockage peut être gérée par partition, et vous pouvez basculer une partition de l'une à l'autre par programmation,

Dans ce modèle, les données historiques sont stockées dans des partitions MOLAP avec des agrégats des données également persistants. Si une requête peut être satisfaite à partir des agrégats, le serveur les utilisera. Les agrégats peuvent être ajustés pour répondre aux requêtes, et les agrégats corrects réduiront considérablement la quantité de calcul nécessaire pour résoudre la requête. Des requêtes agrégées très réactives sont possibles avec ce type de système.

Les données en temps réel peuvent être implémentées en maintenant une petite partition de tête - pour le mois, le jour ou même l'heure en cours si nécessaire. Le serveur OLAP émettra des requêtes sur la base de données; si cette partition est suffisamment petite, le SGBD pourra répondre rapidement. Un processus régulier crée de nouvelles partitions principales et convertit les périodes historiques fermées en MOLAP. Les anciennes partitions peuvent être fusionnées, ce qui permet de gérer les données historiques à n'importe quel grain souhaité.

Les clients qui écrivent dans la base de données écrivent simplement directement le SGBDR sous-jacent. Si les données historiques restent statiques, elles n'écriront que sur la partition principale. 4 To est un volume pratique pour utiliser des SSD si vous avez besoin de performances SGBD supplémentaires. Même les fournisseurs traditionnels ont des offres basées sur SSD avec des unités SLC plus rapides en option.