stratégie de persistance pour lit une faible latence et écrit

Question

Je construis une application qui inclut une fonctionnalité de tag en vrac des millions d'enregistrements, plus ou moins interactive. L'interaction de l'utilisateur est très similaire à Gmail où les utilisateurs peuvent marquer des e-mails individuels ou étiquette en vrac de grandes quantités d'e-mails. Je dois aussi un accès en lecture rapide à ces adhésions d'étiquettes ainsi, et où le motif de lecture est plus ou moins aléatoire.

À l'heure actuelle, nous utilisons Mysql et l'insertion d'une ligne pour chaque paire étiquette-document. L'écriture des millions de lignes à Mysql prend un certain temps (E / S élevée), même avec des insertions en vrac et l'optimisation lourde. Nous avons besoin que ce soit un processus interactif, pas un processus de traitement par lots.

Pour les données que nous le stockage et la lecture, la cohérence et la disponibilité des données ne sont pas aussi importantes que les performances et l'évolutivité. Ainsi, en cas de défaillance du système, tandis que les écritures se produisent, je peux faire face à une perte de données. Cependant, les données doivent absolument être persisté au stockage secondaire à un moment donné.

Donc, pour résumer, voici les exigences:

• faible masse de latence écrit de potentiellement des dizaines de millions d'enregistrements
• Les données doivent être persisté d'une certaine façon
• faible latence aléatoire lit
• écriture durable non nécessaire
• cohérence est correct eventuel

Voici quelques solutions que j'ai regardé:

• Ecrire derrière les caches (terre cuite, GigaSpaces, cohérence) où les dossiers sont écrits dans la mémoire et égouttés à la base de données de manière asynchrone. Ces me font peur un peu parce qu'ils semblent ajouter une certaine quantité de complexité à l'application que je veux éviter.
• magasins clé-valeur hautement évolutive, comme MongoDB, HBase, Tokyo Tyrant

Answer 1

Si vous avez le budget à utiliser la cohérence pour cela, je vous recommande vivement le faire. Il y a un soutien direct à l'écriture différée, le comportement de cohérence à terme en cohérence et il est très survivable à la fois une panne de base de données et des pannes de nœud de cluster cohérence (si vous utilisez> = 3 noeuds cohérence sur JVMs séparés, de préférence sur des hôtes séparés). Je l'ai mis en œuvre pour ce faire CRM à haut volume pour le site e-commerce d'une entreprise Fortune 100 et il fonctionne fantastiquement.

L'un des meilleurs aspects de cette architecture est que vous écrivez votre code d'application Java comme si aucun des comportements d'écriture derrière étaient en cours, puis branchez la topologie cohérence et de configuration qui fait se produire. Si vous avez besoin de changer le comportement ou la topologie de cohérence plus tard, aucun changement dans votre application est nécessaire. Je sais qu'il ya probablement une poignée de moyens raisonnables pour le faire, mais ce comportement est pris en charge directement dans la cohérence plutôt que d'avoir à inventer ou rouleau à la main une façon de le faire.

Pour faire un point très bien - votre inquiétude sur l'ajout de la complexité de l'application est un bon. Avec cohérence, vous écrivez simplement mises à jour du cache (ou si vous utilisez Hibernate, il peut être le fournisseur de cache L2). En fonction de votre configuration de la cohérence et de la topologie, vous avez la possibilité de déployer votre application à utiliser l'écriture derrière, distribués, caches. Ainsi, votre application est plus complexe (et, franchement pas au courant) en raison des caractéristiques du cache.

Enfin, je mis en œuvre la solution mentionnée ci-dessus de 2005-2007 lorsque la cohérence a été faite par Tangosol et ils avaient le meilleur soutien possible. Je ne sais pas comment les choses sont maintenant sous Oracle -., Espérons encore bon

Answer 2

Je travaille sur un grand projet qui a utilisé asyncrhonous écrit althoguh dans ce cas, il a été juste écrit à la main en utilisant des fils de fond. Vous pouvez également mettre en œuvre quelque chose comme ça en déchargeant le processus d'écriture db à une file d'attente JMS.

Une chose qui certainement accélérer db est écrit à les faire par lots. mises à jour batch JDBC peuvent être des ordres de grandeur plus rapide que les écritures individuelles, et si vous les faites de manière asynchrone, vous pouvez simplement les écrire 500 à la fois.

Answer 3

Selon la façon dont peut-être est l'organisation de vos données que vous pourrez utiliser sharding , si le temps d'attente de lecture n'est pas assez bas, vous pouvez aussi essayer d'ajouter la mise en cache. Memcache est une solution populaire.

Answer 4

Berkeley DB a une table de hachage sur disque très haute performance qui prend en charge les transactions, et intègre un environnement Java EE si vous avez besoin que. Si vous êtes en mesure de modéliser les données sous forme de paires clé / valeur, cela peut être une solution très évolutive.

http://www.oracle.com/technology /products/berkeley-db/je/index.html

(Note: Oracle a acheté environ 5-10 db berkeley il y a quelques années, le produit original a été autour depuis 15-20 ans).