Alternative ou succesor à Gdbm

Question

Nous avons un GDBM base de données clé-valeur comme backend à une application tournée vers la toile à charge équilibrée qui est implémenté en C ++. Les données desservies par l'application a connu une croissance très importante, nos admins ont déplacé les fichiers GDBM du stockage « local » (sur les serveurs Web, ou très proche) à une grande, partagée, à distance, système de fichiers NFS monté.

Cela a affecté la performance. Nos tests de performance (dans un environnement de test) montrent les temps de chargement de page saut de centaines de millisecondes (pour le disque local) à plusieurs secondes (sur NFS, réseau local), et parfois obtenir jusqu'à 30 secondes. Je crois qu'une grande partie du problème est que l'application fait beaucoup de lectures aléatoires à partir des fichiers GDBM, et que ceux-ci sont lents sur NFS, et ce sera encore pire dans la production (où le front-end et back-end ont même plus de matériel de réseau entre eux) et que notre base de données devient encore plus importante.

Bien que ce n'est pas une application critique, je voudrais améliorer les performances, et ont des ressources disponibles, y compris le temps de développement d'applications et admins Unix. Ma principale contrainte est temps que les ressources ont pendant quelques semaines.

Comme je le vois, mes options sont:

1. Améliorer les performances NFS par des paramètres de réglage. Mon instinct est que nous obtenons beaucoup l'habitude de cela, mais je l'ai eu tort avant, et je ne sais pas vraiment beaucoup sur le réglage NFS.

2. Déplacer vers une autre base de données clé-valeur, tels que memcachedb ou Tokyo Cabinet

3. Remplacer NFS avec un autre protocole (iSCSI a été mentionné, mais je ne suis pas familier avec elle).

Comment dois-je aborder ce problème?

Answer 1

Ne pas trop accroché sur la comparaison « relationnelle versus non-relationnel ». Il semble hors de propos pour cette question.

La ligne votre demande a franchi une autre: à partir d'une petite base de données sur le stockage de fichiers local rapide, à une grande base de données accessible via le réseau . En traversant cette ligne signifie que vous êtes mieux maintenant desservis par un dédié, le réseau desservi, système de gestion de base de données. Que le serveur de gestion gère les bases de données relationnelles ne sont pas pertinentes pour cet aspect.

Pour l'obtenir rapidement opérationnel, MariaDB (le successeur de MySQL) est probablement votre meilleur pari. Si vous prévoyez grandir bien au-delà où il est maintenant, vous pourriez aussi bien le mettre dans PostgreSQL puisque c'est là il devra aller de toute façon par la suite: -)

Answer 2

Cela semble ne pas être ce que vous voulez entendre, mais honnêtement, si je vous je vomissais dans une table MySQL. Ce n'est pas comme si elle est significative plus difficile de travailler avec, et vous obtenez beaucoup d'avantages avec elle, notamment un protocole d'accès à distance qui est effectivement destiné à votre situation, contrairement à GDBM-over-NFS.

Answer 3

Si vous voulez coller aux bases de données non relationnelles, vous pouvez essayer BDB ou DJB de PEH. Je l'ai utilisé à la fois à ce jour et je pense que quand il se résume à la performance, ils surclassent GDBM.

Mais gardez la réponse bignose à l'esprit que moi aussi, je pense que votre goulot d'étranglement pourrait ne pas être la structure de données (GDBM) que vous utilisez, mais votre infrastructure.

Answer 4

Système de fichiers i / o des fichiers à plat sur un réseau n'est pas une bonne idée, mais vous devriez envisager d'écrire un serveur tcp multi-thread qui fait i / o, requête, etc. sur cette machine, vous renvoie les résultats de retour. Transfert de petits morceaux de données ne sont pas des fichiers entiers db ..

Je suis la conception d'un mécanisme cache-persévérance pour surmonter une problem.I haute disponibilité va coder, en python.