J'ai besoin d'un magasin de valeurs de clé basé sur un disque pouvant contenir des performances d'écriture élevées et de lecture pour les grands ensembles de données. Bon ordre, je sais.
J'essaie de la bibliothèque C Berkeleydb (5.1.25) de Java et je vois des problèmes de performance graves.
Je reçois un peu de documents / s de 14 000 solides pendant un court instant, mais dès que j'atteindra quelques centaines de milliers de documents, les performances tombent comme une roche, puis il récupère pendant un moment, puis tombe à nouveau, etc. Cela se produit plus et Plus fréquemment, jusqu'au point où la plupart du temps, je ne peux pas obtenir plus de 60 documents / s avec quelques pics isolés de 12 000 documents / s après 10 millions de documents. Mon type de choix de DB est Hash, mais j'ai aussi essayé Btree et c'est la même chose.
J'ai essayé d'utiliser une piscine de 10 dB et de hacher les docs parmi eux pour lisser les gouttes de performance; Cela a augmenté le débit d'écriture à 50k Docs / s mais n'a pas permis de gouttes de performances: les 10 DB ont ralenti à une rampe en même temps.
Je présume que les fichiers sont en cours de réorganisation et j'ai essayé de trouver un paramètre de configuration qui affecte lorsque cette réorganisation a lieu, chacune des DB regroupées se réorganiserait à un moment différent, mais je n'ai pas pu trouver quoi que ce soit . J'ai essayé différentes tailles de cache, réservant de l'espace à l'aide de l'option de configuration de Séthaashnumelements afin qu'elle ne dépense pas le temps de cultiver le fichier, mais chaque tweak a rendu beaucoup pire.
Je suis sur le point de donner Berkeleydb up et d'essayer des solutions beaucoup plus complexes comme Cassandra, mais je veux m'assurer que je ne fais pas quelque chose de mal à Berkeleydb avant de l'écrire.
Quelqu'un avec une expérience avec une expérience de réalisation de la performance d'écriture soutenue avec Berkeleydb?
EDIT 1 :
J'ai déjà essayé plusieurs choses:
En d'autres termes, même si j'impressions les données entrantes pour rester en dessous de la capacité matérielle et utilisez RAM pour contenir des éléments tandis que BerkeleyDB prend un certain temps pour s'adapter à la croissance, car cette période devient de plus en plus longue, les approches de performance 0.
Cela me surprend parce que j'ai vu affirmer qu'il peut gérer des téraoctets de données, mais mes tests montrent le contraire. J'espère toujours que je vais faire quelque chose de mal ...
EDIT 2 :
Après plus de réfléchir et avec les contributions de Peter, je comprends maintenant que, lorsque le fichier augmente, un lot d'écritures sera étendu plus loin et la probabilité d'entre eux tombe dans les mêmes chutes de cylindre de disque, jusqu'à ce qu'il atteigne finalement la recherche / deuxième limitation du disque.
Mais les réorganisations de fichiers périodiques de BerkeleyDB meurent des performances beaucoup plus tôt que cela, et d'une manière bien pire: elle arrête simplement de répondre plus longtemps et de plus longues périodes de temps pendant que cela dépasse des trucs. Utiliser des disques plus rapides ou la diffusion des fichiers de base de données entre différents disques n'aident pas. J'ai besoin de trouver un moyen de trouver ces trous de débit.
5 Réponses :
Ce que j'ai vu avec des taux élevés d'écrivies de disque, c'est que le cache du système se remplira (donnant des performances allumant jusqu'à ce point), mais une fois qu'elle remplit l'application, même l'ensemble du système peut ralentiellement, même s'arrêter.
Votre disque physique sous-jacent devrait soutenir au moins 100 écrit par seconde. Plus que c'est une illusion soutenue par la mise en cache plus claire. ;) Cependant, lorsque le système de mise en cache est épuisé, vous verrez un très mauvais comportement.
Je vous suggère de considérer un cache de contrôleur de disque. Sa batterie sauvegardée de la mémoire devra être à peu près la taille de vos données.
Une autre option consiste à utiliser des lecteurs SSD si les mises à jour sont éclateuses (elles peuvent faire 10 km + écrit par seconde, car elles n'ont pas de pièces mobiles) avec la mise en cache, cela devrait vous donner plus que nécessaire, mais SSD dispose d'un nombre limité d'écritures. .
Je vois une moyenne de 500 écrit / seconde sur un disque de 70 cherche / seconde (grâce au cache du contrôleur, non?). Je serais satisfait si je pouvais obtenir constamment 500 écrit / seconde, mais j'obtiens une grande variabilité que je veux éviter. J'ai essayé d'étrangler les écrits à 500 / s mais une fois qu'un certain nombre de documents a été écrit, des baisses de performance sont sans objet. SSD n'est pas une option.
@ user305175: Pour voir si le disque est le problème, vous pouvez essayer deux choses: surveiller les performances de votre disque Io à l'aide de Perfmon sous Windows ou VMSTAT sur Linux. Ou essayez d'utiliser un BerkeleyDB en mode RAM uniquement, si vous avez suffisamment de RAM.
@Zan: L'ensemble du point d'utilisation de BerkeleyDB est de décharger des trucs de la mémoire. La question est que BerkeleyDB ne semble pas être en mesure de fournir une performance d'écriture constante.
@Alex: Je parle de débogage. Si le débogage révèle un problème de disque IO, vous achetez des SSD ou autre chose.
Mon point est que votre matériel est susceptible d'être la cause première de la performance instable. Il n'y a que tant que le système d'exploitation / logiciel ne fait que travailler autour de vos limitations matérielles. Je suppose que vous voyez très peu de temps du processeur et que vous attendez principalement du disque. Ne vous prenez pas de moi. Un disque de 7200 tr / min a un temps d'accès typique de 8 ms, ce qui signifie que vous pouvez effectuer 125 écrit par seconde maintenus. (1000/8) Tomshardware.com/reviews/notebook-hdd -750 Go, 2832-7.htm
@Peter: Je sais que je peux obtenir 500 écrit par seconde du matériel. Le matériel n'est pas le problème. La performance n'est pas instable: il suit un motif. BerkeleyDB arrête périodiquement tout pour réorganiser le fichier et je ne peux pas écrire à la DB pendant cette période. Ces périodes sont plus longues et plus fréquentes car le nombre d'articles augmente. Je cherche une solution autour de cette question, par exemple écrire dans un autre fichier, mais je ne peux penser à aucun moyen de le faire de tel que je pourrai accéder à ces articles lorsque j'ai besoin de les lire.
@Alex, le comportement que vous décrivez est exactement le même que ce que j'ai vu écrire à un certain nombre de fichiers journaux, sans aucune réorganisation. Comment connaissez-vous Berkeley DB réorganise les fichiers?
@Peter: intéressant. Je ne vois pas ce genre de comportement lors de l'écriture pour se connecter. Ajout à un fichier, même lorsque la concurrence pour le disque avec d'autres processus ne semble pas ralentir avec la taille du fichier. Pourquoi serait-ce? Je ne sais pas savoir que le Berkeleydb est réorganisé, mais les modèles de chute de vitesse semblent l'indiquer et je ne peux penser à rien d'autre. La machine à tester ne fait rien d'autre et le disque est local. Je vais essayer de télécharger un graphique de la vitesse et de le lier dans le message d'origine. En outre, 8MS est la moyenne de la recherche moyenne, vous supposez que chaque écriture signifie une recherche, ce qui n'est pas le cas.
Si vous ajoutez des données à un HASHMAP persisté au disque, les écritures ne seront pas aléatoires. (Le hash est aléatoire) écriture de grandes quantités de données en continu sur le disque doit être très efficace. Les écrivies aléatoires auront l'air efficace jusqu'à un point, mais vous atteignez un point où le système se comporte dans le modèle que vous décrivez.
@Peter: En d'autres termes, BerkeleyDB est incapable de gérer plus de quelques millions de documents sans dégrader au-delà de la convivialité? Cela ne peut pas avoir raison.
Je l'ai utilisé pour stocker des dizaines de millions de "documents" (<1 kb chacun), mais je n'ai pas trouvé son rendement écritable impressionnant et dépendant plutôt du matériel. D'après ce que je me souviens, il y avait des moyens de faire des charges en vrac qui ont bien fonctionné en combinant des mises à jour. (Cela fait longtemps)
BerkeleyDB n'effectue pas de réorganisations de fichiers, sauf invoquer manuellement l'utilitaire de compactage. Il y a plusieurs causes du ralentissement:
Lorsque vous dites "Documents", voulez-vous dire que vous utilisez BDB pour stocker des enregistrements plus grands que quelques ko? Les pages de débordement BDB ont plus de frais généraux et vous devriez donc envisager d'utiliser une plus grande taille de page.
Nous avons utilisé BerkeleyDB (BDB) au travail et semblent avoir des tendances de performance similaires. Berkeleydb utilise un BTREE pour stocker ses paires de clé / valeur. Lorsque le nombre d'entrées continue d'augmenter, la profondeur de l'arborescence augmente. BerkeleyDB Caching fonctionne sur charger des arbres dans la RAM afin qu'un travertial d'arbre n'aboutit pas de fichier IO (lecture de disque).
Avez-vous essayé la partition de BDB? Je ne l'ai pas essayé moi-même et ne peut donc pas retourner ma suggestion avec des faits.
Berkeley DB utilise des arbres B +, pas des arbres B (malgré ce que BDB les appelle). Voir AOSABOOK.ORG/EN/BDB.HTML .
C'est une ancienne question et le problème est probablement parti, mais j'ai récemment eu des problèmes similaires (la vitesse d'insertion qui tombe considérablement après quelques centaines de milliers de disques) et ils ont été résolus en donnant plus de cache à la base de données (DB-> SET_CACHESIZE ). Avec 2 Go de cache, la vitesse d'insertion était très bonne et plus ou moins constante jusqu'à 10 millions d'enregistrements (je n'ai pas encore testé).
Cette réponse m'a beaucoup aidé! Le cache croissant de 8 Go m'a permis d'importer sans heurts de près de 100 millions d'enregistrements. Si quelqu'un est intéressé à définir la mise en cachesize à l'aide de la liaison Python3, voir Mon engagement ici . N'effectuez également pas d'importation dans deux bases de données à la fois!
J'ai besoin d'un magasin de valeurs de clé basé sur disque pouvant supporter des performances d'écriture élevées et de lecture pour les grands ensembles de données.
Carte de chronique est une solution moderne à cette tâche. C'est beaucoup plus rapide que BerkeleyDB sur les deux lectures et écrit, et est beaucoup plus évolutif en termes de accès simultané de plusieurs threads / processus.