2014-05-05 4 views
1

J'applique une application qui génère des centaines de milliers de lignes dans 4 threads. Chaque thread ouvre une connexion séparée à Cassandra.cassandra - problèmes d'applications en lecture-écriture à accès simultané élevé

Chaque élément de la table possède un identifiant de hachage unique (String), mais la clé primaire est un uuid.

Le procédé de l'article persistant est la suivante:

1) L'article est créé et son hachage est calculée. 2) Ensuite, une recherche du hachage est en train d'être exécutée dans une seconde table, ce qui permet de hacher les hashs de l'élément. 3) Si une paire hash-uuid est trouvée, une recherche des items uuid est en cours d'exécution (1ère table) et puisque l'item doit exister (car une paire "hash-uuid" a été trouvée), l'item est chargé de cassandra à JPA et il est mis à jour après. Lorsqu'aucune paire "hash - uuid" n'est trouvée, un nouvel élément est créé dans la table correspondante et une nouvelle paire "hash - uuid" est également sauvegardée.

La génération de données comporte deux étapes. La première étape consiste à utiliser des tables vides et à générer les premiers jeux de données. Aucune erreur ne se produit, car dans l'étape nr. 3, une paire "hash - uuid" n'est jamais trouvée, donc aucune mise à jour ne se produit. Dans la deuxième étape, l'algorithme entier s'exécute à nouveau, mais déjà sur des tables de données remplies. Dans cette étape, des erreurs aléatoires se produisent lors de la lecture des éléments de données par leurs uuids correspondants (clés primaires) - parfois le serveur ne restaure pas les données textuelles complètes (les chaînes JSON appropriées sont stockées dans la table, mais les chaînes JSON incomplètes sont récupérées dans l'application). Je suis complètement sûr, que mon algorithme est correct, parce que le même algorithme a fonctionné avec hibernate et mysql, même avec postgresql (mais puisque j'ai besoin d'écritures plus rapides, je joue avec Cassandra).

J'utilise un macbook pro avec 16 Go de RAM, pour le travail avec cassandra j'utilise la bibliothèque Kundera (supporte JPA). En ce qui concerne cassandra, j'ai essayé la version datastax 2.0.4, et aussi la version 2.0.7 téléchargée directement depuis le site Apache. Il n'y a pas de cluster, une seule instance s'exécute localement sur ma machine, sur un disque SSD externe. Kundera utilise CQL v3.

Quelqu'un a une idée, comment ce problème pourrait se produire? Y a-t-il un bug dans le driver de Datastax Cassandra ou dans Kundera? Ou est-ce que j'utilise mal Cassandra et la base de données ne devrait pas être utilisée de cette façon? Ou y a-t-il des réglages de configuration que j'aurais pu oublier?

La seule chose que j'ai changé dans le fichier de configuration cassandra sont tous les temps morts, parce que je recevais trop de TimeoutExceptions avec les valeurs par défaut (les délais d'attente se sont produits au cours des recherches de clé primaire)

+0

si quelqu'un serait intéressé, voici une description plus détaillée sur le problème: https://github.com/impetus-opensource/Kundera/issues/587 – rastusik

Répondre

1

Je soupçonne que votre code n'est pas utiliser les connexions Cassandra d'une manière sûre pour les threads: il faut veiller à n'autoriser qu'un thread à accéder à une connexion à la fois. Je ne sais pas comment Kundera aborde cela, parce que JPA va générer des requêtes incroyablement inefficaces pour Cassandra et je ne le recommande pas. Voir le data modeling resources here, et utiliser le native CQL java driver.

+0

merci pour la réponse, c'est exactement ce que je soupçonne. Il n'y a aucun problème avec la génération de requêtes, car même avec JPA, les requêtes ne sont que des recherches de clés primaires basiques. Je soupçonne que le problème réside dans Kundera, je demandais juste d'être sûr, que je ne fais aucune manipulation de données qui n'est pas censée être manipulée par Cassandra de la façon dont je le fais. – rastusik

Questions connexes