D'après votre expérience, quelle est la limite supérieure du nombre de lignes dans une table MyISAM que MySQL peut traiter efficacement sur un serveur équipé d'un processeur Q9650 (4 cœurs, 3.0G) et de 8G de RAM.
Je dispose actuellement d'un tableau de 15 millions de lignes. C'est assez rapide. Si l'échelle passe à 1 milliard de lignes, dois-je la partitionner en 10 tables de 100 millions de lignes chacune ?
Je ne m'inquiéterais pas des performances de l'application avec 1 milliard de lignes sur une machine qui peut garder les index en mémoire. Si vous voulez sérieusement atteindre le milliard de lignes, vous devez d'abord faire quelques calculs :
Ensuite, passez aux exigences de disponibilité de vos applications.
Je m'inquiéterais davantage du cycle de vie des données et de la gestion des données d'un fichier de table de plusieurs gigaoctets de cette ampleur avant de me préoccuper des performances. Avec la réplication, vous pouvez compenser une grande partie des performances. Garder les données en bon état et les restaurer même après de petits désastres (comme la corruption induite par une mauvaise mémoire RAM) est plus susceptible de vous inquiéter en premier.
Je vous encourage également à prendre le tableau que vous avez -- et à y ajouter 1B lignes de données de test. C'est extrêmement utile pour observer ce qui se passe dans votre système. Exécutez quelques EXPLAINs sur vos requêtes par rapport à ce nouvel énorme ensemble de données. Mesurez le temps nécessaire à la sauvegarde et à la restauration. Vous devrez peut-être ajuster certaines exigences.
Il s'agit d'un article intéressant environ 1 milliard de lignes dans mysql.
Juste pour ajouter à certains des commentaires ci-dessus, j'ai déjà fait des milliards de tables de rangée sur des quad-xeons, mais avec 32 Go de RAM, et pas seulement 8.
Pour s'assurer que nos performances sont bonnes, les tables sont simplifiées et normalisées autant que possible pour qu'elles restent légères, puis elles ne comportent que quelques index. L'objectif principal de ces tables, les très grandes, pour moi, était juste d'écrire des données de séries chronologiques. Beaucoup d'écritures, toutes dans l'ordre, et très peu de lectures. Les lectures qui étaient nécessaires recherchaient toujours des moments spécifiques par rapport à une ou deux autres colonnes, et l'index pouvait s'en charger.
Les tables conservées sur le SAN étaient sauvegardées automatiquement par SRDF et, lorsque les choses se passaient mal (disque plein, etc.), il fallait environ 4 heures pour les réparer.
Ce qui renforce mon propos - cela dépend beaucoup de la façon dont ces données sont utilisées et structurées :-)
Dépend de votre matériel, de vos données, des requêtes que vous exécutez et de ce que vous considérez comme rapide. pour une requête simple ( "select * from table where foo='bla'" ), le calcul est simple : si votre requête utilise un index et que cet index tient dans le tampon du système de fichiers de votre système d'exploitation, elle sera rapide. S'il ne tient pas, la requête s'exécute plus lentement (le degré de ralentissement dépend de la quantité de données que mysql doit lire et de la vitesse de vos disques).
Cependant, j'utiliserais une base de données compatible ACID comme postgres avec de telles tables, vous ne voulez pas réparer une table avec un milliard de lignes.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Question : pourquoi MyISAM tout d'un coup ? Prévoyez-vous d'utiliser l'indexation en texte intégral ?
1 votes
ISAM est idéal pour les données non relationnelles très massives. Et avec un milliard de lignes, chaque milliseconde compte.