Le meilleur magasin de données pour des milliards de lignes
J'ai besoin d'être en mesure de stocker de petits morceaux de données (environ 50 à 75 octets) pour des milliards d'enregistrements (~3 milliards d'euros/mois pendant un an).
La seule exigence est rapide inserts et rapide des recherches pour tous les enregistrements avec le même GUID et la possibilité d'accéder à la banque de données à partir .net.
Je suis un SQL server gars et je pense que SQL Server peut ce faire, mais avec tous les discours sur BigTable, CouchDB, et d'autres les solutions nosql, il sonne de plus en plus comme une alternative à la traditionnelle RDB peut-être mieux, en raison des optimisations pour les requêtes distribuées et mise à l'échelle. J'ai essayé de cassandra et de la .net les bibliothèques ne sont pas actuellement compiler ou sont tous les sujets à changement (avec cassandra elle-même).
J'ai regardé dans de nombreux magasins de données nosql disponibles, mais ne peut pas trouver celle qui répond à mes besoins en tant que robuste de production de la plate-forme.
Si vous avez eu pour stocker 36 milliards de petits, à plat des dossiers afin qu'ils soient accessibles depuis .net, ce qui choisiriez-vous et pourquoi?
- Ouais, mes chiffres sont corrects. Actuellement, nous avons autant de données à entrer dans le système, mais nous collectons et conservons uniquement les totaux si nous perdons le nombre d'enregistrements de données et de maintenir des horaires des sommes de données. En raison des exigences de l'entreprise, nous voulons maintenir chaque enregistrement qu'il avait d'abord eu lieu et c'est 3Bil lignes/mois.
- Vous avez soulevé quelques bonnes questions. Les réponses sont: 95% du temps est assez - les données est déjà en retard d'un montant variable, donc je vais avoir besoin de synchroniser jusqu'après le fait, de toute façon, donc vers le bas pour un court laps de temps n'est pas un briseur d'affaire. Perdre des inserts ou même des milliers de plaquettes ne sont pas la fin du monde. La perte d'un jour de données serait assez mauvais cependant. La cohérence n'est pas important non plus. Fondamentalement, après l'insertion 30Mil lignes en une journée, j'ai besoin de récupérer toutes les lignes avec le même GUID (peut-être 20 lignes) et d'être raisonnablement sûr que j'avais tous les ramener.
- Avez-vous dump 30M lignes un jour quotidiennes/horaire prévu les travaux en lots, ou ils viennent dans un flux constant, un à un?
- Les données arrivent à partir d'un site FTP... fichiers viennent en permanence et j'ai un processus qui analyse les fichiers et actuellement, il génère les données agrégées et insère les valeurs agrégées (peut-être 1000 lignes) comme une transaction. Le nouveau processus sera nécessaire d'insérer des centaines de milliers de lignes de chaque fichier qui arrive, probablement à l'aide de l'instruction bulk insert serait le moyen le plus efficace de le faire.
- Qui sonne comme un travail ETL pour SSIS et SQL Server. Ils ne détiennent un record du monde pour ETL, à plus de 2 TO/heure de vitesse de téléchargement: blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx
- J'ai un tableau avec 16 colonnes en MSSQL base de données contenant de 1,5 crore dossiers et je l'insère 3.25 Lac moyenne pas. de lignes sur une base quotidienne. Avant d'insérer chaque nouveau single lignes, je suis en vérifiant avec 5 valeurs de colonnes dans le tableau. Si aucune ligne trouvée, basée sur 5 colonnes de valeurs peut alors insérer une nouvelle ligne uniquement. Merci de me suggérer comment puis-je le faire de manière efficace? Merci d'avance
Vous devez vous connecter pour publier un commentaire.
Stockage de ~3,5 to de données et l'insertion d'environ 1K/s 24x7, et aussi de l'interrogation, à un taux qui n'est pas spécifié, il est possible avec SQL Server, mais il y a plus de questions:
Si vous avez besoin de toutes ces exigences, je l'ai souligné, la charge que vous proposez va coûter des millions de dollars dans le matériel et les licences sur un système relationnel, tout système, peu importe ce que les gimmicks vous essayez (sharding, partitionnement, etc). Un nosql système, de par leur définition même, de ne pas répondre à tous ces exigences.
Alors, évidemment, vous avez déjà assoupli certaines de ces exigences. Il y a une belle visual guide de comparaison de la nosql offres basées sur le "pick 2 de 3" paradigme à Guide visuel pour les Systèmes NoSQL:
Après l'OP commentaire de mise à jour
Avec SQL Server, cette e et directe de la mise en œuvre:
De partitionnement et de compression de page chaque nécessitent une Édition Enterprise de SQL Server, ils ne fonctionnent pas sur l'Édition Standard et les deux sont très important pour répondre aux exigences.
Comme une note de côté, si les enregistrements proviennent d'un front-end Web, les serveurs de la ferme, je mettrais Exprimer sur chaque serveur web et au lieu de l'INSÉRER sur le back-end, je
ENVOYERl'info à l'extrémité arrière, à l'aide d'une connexion locale/transaction sur l'Express co-localisé avec le serveur web. Cela donne un beaucoup beaucoup mieux la disponibilité de l'histoire de la solution.Donc, c'est comment j'allais le faire en SQL Server. La bonne nouvelle, c'est que les problèmes que vous devrez faire face sont bien compris et que les solutions sont connues. cela ne veut pas forcément dire que c'est mieux que ce que vous pourriez réaliser avec Cassandra, BigTable ou Dynamo. Je vais laisser quelqu'un de plus knowleageable dans les choses non-sql-ish à l'argument de leur cas.
Noter que je n'ai jamais mentionné le modèle de programmation .Net de soutien et de ces. Honnêtement, je pense qu'ils sont hors de propos dans les déploiements à grande échelle. Ils faire une énorme différence dans le processus de développement, mais une fois déployée, elle n'a pas d'importance à quelle vitesse le développement a été, si l'ORM généraux tue performance 🙂
Contrairement à la croyance populaire, le NoSQL n'est pas sur les performances, ou encore l'évolutivité. C'est principalement au sujet de minimiser les soi-disant Objet-Relationnelles, d'adaptation d'impédance, mais aussi la horizontale évolutivité vs le plus typique verticale évolutivité d'un SGBDR.
Pour la simple exigence de jeûnes inserts et rapide des recherches, presque n'importe quel produit de base de données ne pourra le faire. Si vous souhaitez ajouter des données relationnelles, ou des jointures, ou ont aucun complexe transactionnelle de la logique ou des contraintes que vous avez besoin de mettre en place, alors vous voulez une base de données relationnelle. Pas de NoSQL produit peut comparer.
Si vous avez besoin d'schemaless de données, vous voulez aller avec un document de base de données orientée comme MongoDB ou CouchDB. Le lâche schéma est l'attraction principale de ces; personnellement, j'aime MongoDB et de l'utiliser dans quelques personnalisé des systèmes de reporting. Je trouve qu'il est très utile lorsque les exigences en matière de données sont en constante évolution.
Les autres principaux NoSQL option est distribué Clé-Valeur dans les Magasins comme BigTable ou Cassandra. Ils sont particulièrement utiles si vous souhaitez mettre à l'échelle votre base de données à travers de nombreuses machines de course matériel de base. Ils fonctionnent très bien sur les serveurs aussi, évidemment, mais ne prenez pas avantage de matériel haut de gamme ainsi que SQL Server ou Oracle ou autre base de données conçu pour verticale de mise à l'échelle, et, évidemment, ils ne sont pas relationnelles et ne sont pas bons pour l'application de la normalisation ou de contraintes. Aussi, comme vous l'avez remarqué, .NET support tend à être totalement négligée.
Tous relationnel de la base de données produits prennent en charge le partitionnement limité de la sorte. Ils ne sont pas aussi flexibles que BigTable ou d'autres DKVS systèmes, ils n'ont pas de partition facilement à travers les des centaines de serveurs, mais il n'a vraiment pas l'air comme c'est ce que vous cherchez. Ils sont assez bien à la manipulation nombre d'enregistrements dans la des milliards, aussi longtemps que vous index et de normaliser les données correctement, exécutez la base de données sur les puissants du matériel (en particulier les Ssd si vous avez les moyens), et la partition sur 2 ou 3 ou 5 disques physiques si nécessaire.
Si vous répondez aux critères ci-dessus, si vous travaillez dans un environnement d'entreprise et avez de l'argent à dépenser sur le matériel décent et optimisation de bases de données, je collerais avec SQL Server pour l'instant. Si vous pincer pennies et besoin pour exécuter ce sur bas de gamme cloud Amazon EC2 matériel informatique, vous auriez probablement souhaitez opter pour Cassandra ou Voldemort à la place (en supposant que vous pouvez obtenir pour travailler avec .NET).
Très peu de personnes travaillent à la multi-milliard de lignes taille de l'ensemble, et la plupart des fois que je vois une demande de ce genre sur un débordement de pile, les données ne sont pas où près de la taille, il est rapporté que.
36 milliards, 3 milliards de dollars par mois, c'est environ 100 millions de dollars par jour, de 4,16 millions de dollars, une heure, ~70k lignes par minute, 1.1 k lignes d'une seconde à entrer dans le système, de manière continue pendant 12 mois, si aucun temps d'arrêt.
Ces chiffres ne sont pas impossibles par une longue marge, j'ai fait de grands systèmes, mais vous voulez vérifier que c'est vraiment les quantités que vous voulez dire - très peu d'applications ont vraiment cette quantité.
En termes de stockage /récupération et de tout un aspect critique vous n'avez pas mentionné, c'est le vieillissement de données les plus anciens - la suppression n'est pas libre.
La normale de la technologie est de regarder à l'est de partitionnement, cependant, la recherche ou l'extraction d'être basés sur GUID seraient le résultat d'une mauvaise performance, en supposant que vous avez pour obtenir tous les correspondants de la valeur dans l'ensemble de la période de 12 mois. Vous pouvez placer un index cluster sur la colonne GUID obtiendrez vos données associées clusterd pour lire /écrire, mais à ceux des quantités et de la vitesse d'insertion, la fragmentation sera beaucoup trop élevée à l'appui, et il va tomber sur le sol.
Je dirais aussi que vous allez avoir besoin d'un très décent budget matériel si c'est une candidature sérieuse avec OLTP type de réponse de la vitesse, qui est par certains approximative devine, en supposant que très peu de frais généraux de l'indexation sage, environ 2,7 to de données.
Dans SQL Server camp, la seule chose que vous voulez regarder, c'est le nouveau parallèle de l'entrepôt de données de l'édition (madison) qui est conçu plus pour la fragmentation des données et de l'exécution en parallèle des requêtes pour fournir une haute vitesse contre les grandes datamarts.
"J'ai besoin d'être en mesure de stocker de petits morceaux de données (environ 50 à 75 octets) pour des milliards d'enregistrements (~3 milliards d'euros/mois pendant un an).
La seule exigence est rapide inserts et rapide des recherches pour tous les enregistrements avec le même GUID et la possibilité d'accéder à la banque de données à partir .net."
Je peux vous dire par expérience que c'est possible dans SQL Server, parce que je l'ai fait au début de 2009 ... et il est encore en fonctionnement à ce jour et assez rapide.
La table est partitionnée en 256 partitions, gardez à l'esprit, c'était en 2005 de SQL version ... et nous avons fait exactement ce que tu dis, et c'est pour stocker des bits de l'info par le GUID et de récupérer par GUID rapidement.
Quand j'ai quitté nous avons eu autour de 2 à 3 milliards de dossiers, et la récupération des données est encore en assez bon état (1 à 2 secondes si obtenir par le biais de l'INTERFACE utilisateur, ou moins si sur SGBDR), même si la politique de conservation des données est sur le point d'être instancié.
Donc, longue histoire courte, j'ai pris les 8 char (c'est à dire quelque part dans le moyen-ish) de la chaîne GUID et SHA1 haché et jeté comme de minuscules int (0 à 255) et stockées dans la partition appropriée et utilisés de la même appel de fonction lors de l'obtention des données de retour.
ping-moi si vous avez besoin de plus d'infos...
L'article suivant traite de l'importation et de l'utilisation d'un 16 milliards ligne de la table dans Microsoft SQL.
http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table.
De l'article:
Il est un fait inhabituelle qui semble négligé.
"Essentiellement après l'insertion 30Mil lignes en une journée, j'ai besoin de récupérer toutes les lignes avec le même GUID (peut-être 20 lignes) et d'être raisonnablement sûr que j'avais tous les ramener à la"
Nécessitant seulement 20 colonnes, un index non ordonné en clusters sur le GUID fonctionnent très bien. Vous pourriez cluster sur une autre colonne pour les données de la dispersion à travers des partitions.
J'ai une question concernant l'insertion de données: Comment est-il inséré?
Je pense que ces le besoin d'être répondu pour aider à comprendre une partie de l'équation.
Amazon Redshift est un grand service. Il n'était pas disponible lorsque la question a été posté en 2010, mais il est aujourd'hui un acteur majeur en 2017. C'est une colonne de base de données, fourche de Postgres, de sorte que le standard SQL et Postgresql connecteur bibliothèques de travailler avec elle.
Il est préférable de l'utiliser à des fins de reporting, en particulier de l'agrégation. Les données d'une seule table est stockée sur des serveurs différents dans Amazon cloud, distribué par sur la table définie distkeys, de sorte que vous compter sur distribués de puissance CPU.
Donc Sélectionne et surtout agrégées Sélectionne rapides comme l'éclair. Chargement de données de grande taille doit être fait de préférence avec la commande de COPIE à partir d'Amazon S3 fichiers csv. Les inconvénients sont que les Suppressions et Mises à jour sont plus lents que d'habitude, mais c'est pourquoi Redshift dans pas principalement une base de données transnationale, mais plus d'un entrepôt de données de la plateforme.
Vous pouvez essayer d'utiliser Cassandra ou HBase, si vous auriez besoin de lire sur la façon de concevoir la famille de la colonne selon votre cas d'utilisation.
Cassandra dispose de son propre langage de requête, mais vous avez besoin d'utiliser des Api Java de HBase pour accéder aux données directement.
Si vous avez besoin d'utiliser Hbase alors je vous recommande d'interrogation des données avec Apache de Forage à partir de la Carte-R qui est un projet Open Source. Percer le langage de requête SQL est Conforme(mots-clés foret, ont le même sens, ils auraient en SQL).
Stocker les enregistrements dans la plaine des fichiers binaires, un fichier par GUID, ne pas faire plus vite que ça.
Vous pouvez utiliser MongoDB et utiliser le guid de la fragmentation de la clé, cela signifie que vous pouvez distribuer vos données sur plusieurs machines, mais les données que vous souhaitez sélectionner n'est que sur une machine parce que vous choisissez par la fragmentation de la clé.
Sharding dans MongoDb n'est pas encore prêt pour la production.