Base de données pouvant gérer> 500 millions de lignes
Je recherche une base de données capable de gérer (créer un index sur une colonne dans un délai raisonnable et fournir des résultats pour sélectionner les requêtes en moins de 3 sec) plus de 500 millions de lignes. Postgresql ou Msql sur une machine bas de gamme (Core 2 CPU 6600, 4 Go, système 64 bits, Windows Vista) gérerait-il un si grand nombre de lignes?
Mise à jour: En posant cette question, je recherche des informations sur la base de données à utiliser sur une machine bas de gamme afin de fournir des résultats pour sélectionner des questions avec un ou deux champs spécifiés dans la clause where. Aucune jointure. J'ai besoin de créer des indices - cela ne peut pas prendre des années comme sur mysql - pour atteindre des performances suffisantes pour mes requêtes sélectionnées. Cette machine est un PC de test pour effectuer une expérience.
Le schéma de table:
create table mapper {
key VARCHAR(1000),
attr1 VARCHAR (100),
attr1 INT,
attr2 INT,
value VARCHAR (2000),
PRIMARY KEY (key),
INDEX (attr1),
INDEX (attr2)
}
MSSQL peut très bien gérer autant de lignes. Le temps de requête dépend complètement de beaucoup plus de facteurs que le simple nombre de lignes.
Par exemple, cela dépendra de:
- combien de jointures ces requêtes font
- la qualité de la configuration de vos index
- combien de bélier est dans la machine
- vitesse et nombre de processeurs
- type et vitesse de rotation des disques durs
- taille de la ligne/quantité de données retournées dans la requête
- Vitesse/latence de l'interface réseau
Il est très facile d'avoir une petite table (moins de 10 000 lignes) qui prendrait quelques minutes pour exécuter une requête. Par exemple, en utilisant beaucoup de jointures, de fonctions dans la clause where et d'index zéro sur un processeur Atom avec 512 Mo de RAM total;;)
Il faut un peu plus de travail pour vous assurer que tous vos index et relations de clé étrangère sont bons, que vos requêtes sont optimisées pour éliminer les appels de fonction inutiles et renvoyer uniquement les données dont vous avez réellement besoin. De plus, vous aurez besoin d'un matériel rapide.
Tout se résume à combien d'argent vous voulez dépenser, à la qualité de l'équipe de développement et à la taille des lignes de données avec lesquelles vous traitez.
UPDATE Mise à jour en raison de changements dans la question.
La quantité d'informations ici n'est pas encore suffisante pour donner une réponse réelle. Vous devrez simplement le tester et ajuster la conception et le matériel de votre base de données si nécessaire.
Par exemple, je pourrais très facilement avoir 1 milliard de lignes dans une table sur une machine avec ces spécifications et exécuter une requête "select top (1) id from tableA (nolock)" et obtenir une réponse en millisecondes. De la même manière, vous pouvez exécuter une requête "select * from tablea" et cela prend un certain temps car bien que la requête s'exécute rapidement, le transfert de toutes ces données sur le câble prend un certain temps.
Le fait est que vous devez tester. Ce qui signifie, configurer le serveur, créer certaines de vos tables et les remplir. Ensuite, vous devez passer par l'optimisation des performances pour obtenir vos requêtes et index corrects. Dans le cadre de l'optimisation des performances, vous allez découvrir non seulement comment les requêtes doivent être restructurées, mais aussi exactement quelles parties de la machine doivent être remplacées (par exemple: disque, plus de RAM, cpu, etc.) en fonction du verrouillage et les types d'attente.
Je vous recommande fortement de louer (ou de contracter) un ou deux DBA pour le faire pour vous.
La plupart des bases de données peuvent gérer cela, c'est ce que vous allez faire avec ces données et comment vous le faites. Beaucoup de RAM aidera.
Je commencerais par PostgreSQL, c'est gratuit et il n'y a pas de limites sur RAM (contrairement à SQL Server Express) et aucun problème potentiel avec les licences (trop de processeurs, etc.). Mais c'est aussi mon travail :)
Presque toutes les bases de données non stupides peuvent gérer facilement un milliard de lignes aujourd'hui. 500 millions sont réalisables même sur des systèmes 32 bits (bien que le 64 bits aide vraiment).
Le principal problème est:
- Vous devez avoir suffisamment de RAM. La quantité suffisante dépend de vos requêtes.
- Vous devez avoir un sous-système de disque suffisamment bon. Cela signifie à peu près si vous voulez faire de grands choix, alors un seul plateau pour tout est totalement hors de question. De nombreuses broches (ou un SSD) sont nécessaires pour gérer la charge IO.
Postgres et Mysql peuvent facilement gérer 500 millions de lignes. Sur le matériel approprié.
Ce que vous voulez regarder est la limite de taille de table imposée par le logiciel de base de données. Par exemple, au moment d'écrire ces lignes, MySQL InnoDB a une limite de 64 TB par table , tandis que PostgreSQL a une limite de 32 TB par table ; ni ne limite le nombre de lignes par table. S'ils sont correctement configurés, ces systèmes de base de données ne devraient pas avoir de difficulté à gérer des dizaines ou des centaines de milliards de lignes (si chaque ligne est suffisamment petite), laissez à lui seul 500 millions de lignes.
Pour de meilleures performances de gestion de très grandes quantités de données, vous devez disposer d'un espace disque suffisant et de bonnes performances de disque - qui peuvent être obtenues avec des disques dans un RAID approprié - et de grandes quantités de mémoire couplées à un ou des processeurs rapides (idéalement de qualité serveur). Processeurs Intel Xeon ou AMD Opteron). Inutile de dire que vous devrez également vous assurer que votre système de base de données est configuré pour des performances optimales et que vos tables sont indexées correctement.
L'article suivant décrit l'importation et l'utilisation d'une table de lignes 16 milliards dans Microsoft SQL. http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table .
De l'article:
Voici quelques conseils distillés de mon expérience:
Plus vous avez de données dans une table avec un index cluster défini, plus il devient lent d'y importer des enregistrements non triés. À un moment donné, cela devient trop lent pour être pratique. Si vous souhaitez exporter votre table dans le plus petit fichier possible, rendez-le au format natif. Cela fonctionne mieux avec les tableaux contenant principalement des colonnes numériques, car ils sont représentés de manière plus compacte dans les champs binaires que les données de caractères. Si toutes vos données sont alphanumériques, vous ne gagnerez pas grand-chose en les exportant au format natif. Ne pas autoriser les valeurs nulles dans les champs numériques peut encore compacter les données. Si vous autorisez un champ à être annulé, la représentation binaire du champ contiendra un préfixe de 1 octet indiquant le nombre d'octets de données qui suivront. Vous ne pouvez pas utiliser BCP pour plus de 2 147 483 647 enregistrements car la variable de compteur BCP est un entier de 4 octets. Je n'ai pu trouver aucune référence à cela sur MSDN ou sur Internet. Si votre table comprend plus de 2 147 483 647 enregistrements, vous devrez l'exporter par blocs ou écrire votre propre routine d'exportation. La définition d'un index cluster sur une table pré-remplie prend beaucoup d'espace disque. Dans mon test, mon journal a explosé à 10 fois la taille de la table d'origine avant la fin. Lors de l'importation d'un grand nombre d'enregistrements à l'aide de l'instruction BULK INSERT, incluez le paramètre BATCHSIZE et spécifiez le nombre d'enregistrements à valider à la fois. Si vous n'incluez pas ce paramètre, l'intégralité de votre fichier est importée en une seule transaction, ce qui nécessite beaucoup d'espace de journal. Le moyen le plus rapide d'obtenir des données dans une table avec un index cluster est de trier les données en premier. Vous pouvez ensuite l'importer à l'aide de l'instruction BULK INSERT avec le paramètre ORDER.
Même cela est petit par rapport à la base de données Nasdaq OMX à plusieurs pétaoctets, qui abrite des dizaines de pétaoctets (des milliers de téraoctets) et des milliards de lignes sur SQL Server.
Avez-vous vérifié Cassandra? http://cassandra.Apache.org/
Je n'ai pas beaucoup d'informations sur le meilleur système à utiliser, mais peut-être que cette astuce pourrait vous aider à obtenir la vitesse que vous recherchez.
Si vous voulez faire des correspondances exactes de longues chaînes varchar, en particulier celles qui sont plus longues que celles autorisées pour un index, vous pouvez faire une sorte de hachage pré-calculé:
CREATE TABLE BigStrings (
BigStringID int identity(1,1) NOT NULL PRIMARY KEY CLUSTERED,
Value varchar(6000) NOT NULL,
Chk AS (CHECKSUM(Value))
);
CREATE NONCLUSTERED INDEX IX_BigStrings_Chk ON BigStrings(Chk);
--Load 500 million rows in BigStrings
DECLARE @S varchar(6000);
SET @S = '6000-character-long string here';
-- nasty, slow table scan:
SELECT * FROM BigStrings WHERE Value = @S
-- super fast nonclustered seek followed by very fast clustered index range seek:
SELECT * FROM BigStrings WHERE Value = @S AND Chk = CHECKSUM(@S)
Cela ne vous aidera pas si vous ne faites pas de correspondances exactes, mais dans ce cas, vous pourriez vous pencher sur l'indexation de texte intégral. Cela va vraiment changer la vitesse des recherches sur une table de 500 millions de lignes.
J'ai besoin de créer des index (qui ne prennent pas beaucoup de temps comme sur mysql) pour obtenir des performances suffisantes pour mes requêtes sélectionnées
Je ne sais pas ce que vous entendez par "créer" des index. C'est normalement une chose unique. Maintenant, il est typique lors du chargement d'une énorme quantité de données comme vous le feriez, de supprimer les index, de charger vos données, puis de les rajouter, de sorte que le chargement des données est très rapide. Ensuite, lorsque vous apportez des modifications à la base de données, les index sont mis à jour, mais ils n'ont pas nécessairement besoin d'être créés à chaque exécution de votre requête.
Cela dit, les bases de données ont des moteurs d'optimisation des requêtes où elles analyseront votre requête et détermineront le meilleur plan pour récupérer les données, et voir comment rejoindre les tables (non pertinentes dans votre scénario), et quels index sont disponibles, évidemment vous veulent éviter une analyse complète de la table, donc l'optimisation des performances et la révision du plan de requête sont importantes, comme d'autres l'ont déjà souligné.
Le point ci-dessus à propos d'une somme de contrôle semble intéressant, et cela pourrait même être un indice sur attr1 dans le même tableau.
Comme mentionné, à peu près tous les DB d'aujourd'hui peuvent gérer cette situation - ce sur quoi vous voulez vous concentrer est votre sous-système d'E/S disque. Vous devez configurer une situation RAID 0 ou RAID 0 + 1 en jetant autant de broches que possible au problème. Divisez également vos unités logiques Log/Temp/Data pour les performances.
Par exemple, disons que vous avez 12 disques - dans votre contrôleur RAID, je créerais 3 partitions RAID 0 de 4 disques chacune. Sous Windows (disons) formatez chaque groupe comme un lecteur logique (G, H, I) - maintenant lors de la configuration de SQLServer (disons) affectez la tempdb à G, les fichiers journaux à H et les fichiers de données à I.