Stratégie de persistance pour les lectures et les écritures à faible latence

Question

Je suis en train de créer une application qui inclut une fonctionnalité permettant de marquer en bloc des millions d'enregistrements, de manière plus ou moins interactive. L'interaction de l'utilisateur est très similaire à celle de Gmail, où les utilisateurs peuvent étiqueter des courriels individuels ou marquer de grandes quantités d'e-mails. J'ai également besoin d'un accès rapide en lecture à ces abonnements, et où le modèle de lecture est plus ou moins aléatoire.

Actuellement, nous utilisons Mysql et insérons une ligne pour chaque paire de document-étiquette. L'écriture de millions de lignes dans Mysql prend un certain temps (E/S élevées), même avec des insertions en masse et une optimisation lourde. Nous avons besoin que ce soit un processus interactif, pas un processus par lots.

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

Donc, pour résumer, voici les exigences:

• écrit à faible masse de latence de potentiellement des dizaines de millions d'enregistrements
• Les données doivent être persisté d'une certaine façon
• lectures aléatoires à faible latence
• durables écrit non nécessaire
• est correct cohérence dans le temps

Voici quelques solutions que j'ai regardé:

• derrière des caches écrire (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. Ceux-ci me font un peu peur parce qu'ils semblent ajouter une certaine quantité de complexité à l'application que je voudrais éviter.
• magasins clé-valeur hautement évolutive, comme MongoDB, HBase, Tokyo Tyrant

Answer 1

Si vous avez le budget pour utiliser Coherence pour cela, je recommande fortement de le faire. Il existe une prise en charge directe du comportement de cohérence à écriture nulle dans Coherence et il est très possible de survivre à une panne de base de données et à des interruptions de nœud de cluster Coherence (si vous utilisez> = 3 nœuds de cohérence). Je l'ai mis en œuvre pour faire du CRM à haut volume pour le site de commerce électronique d'une entreprise Fortune 100 et cela fonctionne de manière fantastique.L'un des meilleurs aspects de cette architecture est que vous écrivez votre code d'application Java comme si aucun comportement d'écriture différée ne se produisait, puis vous branchez la topologie Coherence et la configuration qui le permet. Si vous devez modifier le comportement ou la topologie de Coherence ultérieurement, aucune modification de votre application n'est requise. Je sais qu'il y a probablement une poignée de moyens raisonnables de le faire, mais ce comportement est directement pris en charge dans Coherence plutôt que d'avoir à inventer ou à rouler à la main une façon de le faire.

Pour vous faire une idée très précise, vous ne vous souciez pas d'ajouter de la complexité aux applications. Avec Coherence, vous écrivez simplement des mises à jour dans le cache (ou si vous utilisez Hibernate, il peut s'agir du fournisseur de cache L2). En fonction de la configuration et de la topologie de Coherence, vous avez la possibilité de déployer votre application pour utiliser des caches distribués en différé. Ainsi, votre application n'est pas plus complexe (et franchement pas consciente) en raison des fonctionnalités du cache.

Enfin, j'ai mis en œuvre la solution mentionnée ci-dessus de 2005 à 2007 lorsque Coherence a été faite par Tangosol et qu'ils avaient le meilleur support possible. Je ne suis pas sûr de la façon dont les choses sont maintenant sous Oracle - je l'espère encore bien.

Answer 2

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

Answer 3

J'ai travaillé sur un grand projet qui utilisait des écritures asynchrones althoguh dans ce cas, il était juste écrit à la main en utilisant des threads d'arrière-plan. Vous pouvez également implémenter quelque chose comme ça en déchargeant le processus d'écriture db dans une file d'attente JMS.

Une chose qui va certainement accélérer les écritures db est de les faire par lots. Les mises à jour par lots JDBC peuvent être plus rapides que les écritures individuelles, et si vous les exécutez de manière asynchrone, vous pouvez les écrire 500 à la fois.

Answer 4

Berkeley DB dispose d'une table de hachage sur disque très performante qui prend en charge les transactions et s'intègre à un environnement Java EE si vous en avez besoin. Si vous êtes en mesure de modéliser les données en tant que 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é il y a berkeley db environ 5-10 ans, le produit original a été autour depuis 15-20 ans).