Berkeley DB Java Edition - réglage pour une grande quantité de données

Question

J'ai besoin de charger plus de 1 milliard de clés dans Berkley DB et donc je veux l'accorder à l'avance pour obtenir de meilleures performances. Avec une configuration standard, il me faut environ 15 minutes pour charger 1'000'000 clés, ce qui est trop lent. Existe-t-il une manière correcte d'accorder par exemple l'arbre B + de Berkley DB (taille de nœud etc ...)?

(Par comparaison, après avoir réglé le coffret tokyo, il charge 1 milliard de clés en 25 minutes).

P.S. Je suis à la recherche de conseils de réglage comme un code et pas de paramètres pour un système en cours d'exécution (comme jvm taille etc ...)

Answer 1

Je suis curieux, quand TokyoCabinet charge les touches 1B en 25 minutes quelles sont les tailles des clés/valeurs stockées? Quels sont les systèmes d'E/S et le système de stockage que vous utilisez? Utilisez-vous le terme «charger» pour signifier que les transactions transactionnelles 1B se font en stockage stable permanent? Ce serait ~ 666,666 insertions/seconde, ce qui est physiquement impossible compte tenu de tout système d'E/S dont je suis au courant. Multipliez ce nombre par la taille de la clé et de la valeur et vous êtes maintenant désespérément au-delà des limites physiques.

Jetez un coup d'œil au blog de Gustavo Duarte, lisez un peu plus sur les systèmes d'E/S et sur la façon dont les choses fonctionnent dans le matériel, puis passez en revue votre déclaration. Je suis très intéressé à découvrir ce que TokyoCabinet fait exactement et ce qu'il ne fait pas. Si je devais deviner je dirais que soit il s'engage à mettre en cache le système de fichiers dans le système d'exploitation, mais pas vider (fdsync() - ing) ces tampons sur le disque. Divulgation complète: Je suis un chef de produit chez Oracle pour Oracle Berkeley DB (un concurrent direct de TokyoCabinet), j'ai joué avec ces bases de données et le meilleur matériel autour pour eux pendant environ dix ans, donc je suis à la fois biaisé et sceptique. Berkeley DB a des drapeaux que vous pouvez définir sur la poignée de transaction, ce qui imite cela et d'autres similar methods de négociation de la durabilité (le "D" dans ACID) pour la vitesse.

En ce qui concerne la façon de rendre Berkeley DB Java Edition (BDB-JE) plus rapide, vous pouvez essayer ce qui suit:

• écrit différés: ce qui retarde l'écriture dans le journal des transactions aussi longtemps que possible (lorsque les tampons sont pleins, il débusque les données)
• Trier vos clés à l'avance: plus B-arbres (y compris la nôtre) faire beaucoup mieux avec insertions en ordre pour chargement rapide Times-
• L'augmentation de la taille du journal fichiers par défaut de 10MiB à quelque chose de plus, comme 100MiB, ce réduit E/S coûts

Il est très important d'être clair sur les demandes de performances des bases de données. Ils semblent simples, mais il s'avère très difficile de les corriger afin qu'ils ne corrompent jamais les données ou perdent des transactions validées.

J'espère que cela vous aide un peu.

Answer 2

Les encarts en gros sur BDB-JE sont d'un ordre de grandeur plus rapide si vous les regroupez en une seule transaction. La raison en est que chaque validation entraîne (par défaut) une synchronisation sur le disque pendant qu'une transaction est synchronisée sur la validation. Dans mon application, l'écriture de 100'000 petites touches en un seul commit prenait plus d'une minute alors que dans une transaction, il ne fallait que quelques secondes.