Cassandra Client Java API
J'ai récemment commencé à travailler avec la base de données Cassandra. Maintenant, je suis en train d'évaluer quelle Cassandra client nous devrions aller de l'avant avec.
J'ai vu divers articles sur stackoverflow sur le client à utiliser pour Cassandra mais aucun n'a de réponse très définitive.
Mon équipe m'a demandé de faire des recherches à ce sujet et de trouver certains pros and cons pour chaque Cassandra Client API’s en Java.
Comme je l'ai mentionné, je me suis récemment impliqué dans Cassandra alors je n'ai pas vraiment idée pourquoi certaines personnes choisissent Pelops client et pourquoi certaines personnes choisissent Astyanax et d'autres clients.
Je connais de brèves informations sur chacun des clients Cassandra, ce qui veut dire que je suis capable de faire fonctionner cela et de commencer à lire et à écrire dans la base de données Cassandra.
Voici les informations que j'ai à ce jour.
CASSANDRA APIS
Hector (prêt pour la production)
La plus stable des API Java, prête pour les heures de grande écoute.Astyanax (The Up and Comer)
Une API propre Java de Netflix. Elle n'est pas aussi largement utilisée que Hector, mais elle est solide.Kundera (L'ORM NoSQL)
Conforme à JPA, c'est pratique lorsque vous voulez interagir avec Cassandra via des objets.
Cela vous contraint quelque peu dans la mesure où vous ne pourrez pas avoir un nombre dynamique de colonnes/noms, etc. Mais cela vous permet de porter sur des ORM, ou de centraliser le stockage sur Cassandra pour des utilisations plus traditionnelles.Pelops
Je n'ai utilisé que Pelops brièvement. C'était une API simple, mais ne semblait pas avoir l'élan derrière.PlayORM (ORM sans les contraintes?)
Je viens d'en entendre parler. Il semble qu'il essaie de résoudre le décalage d'impédance entre les ORM traditionnels basés sur JPA et NoSQL en introduisant JQL. Cela semble prometteur.Thrift (Evitez-moi!)
Il s'agit de l'API "bas niveau".
Voici nos priorités pour décider Cassandra Client-
- Les premières priorités sont: la surcharge de faible latence, l'API Asynch et la fiabilité/stabilité pour l'environnement de production.
(par exemple, une API plus conviviale qui peut être présente dans le DAL qui enveloppe le client). - La mise en commun des connexions et la connaissance des partitions sont d'autres bonnes fonctionnalités à avoir.
- Capable de détecter tous les nouveaux nœuds ajoutés.
- Bon support également (comme indiqué par le doyen ci-dessous)
Quelqu'un peut-il donner son avis à ce sujet? Et aussi tous les avantages et inconvénients de chaque Cassandra Client et aussi quel client peut répondre à mes exigences sera également d'une grande aide.
Je crois que je vais principalement tourner autour de Astyanax client or New Datastax client that uses Binary protocol Je suppose que sur la base de mes recherches jusqu'à présent. Mais je n'ai pas certaines informations pour soutenir mes recherches et les présenter à mon équipe.
Toute comparaison entre le client Astyanax et le nouveau client Datastax (qui utilise le nouveau protocole binaire) sera d'une grande aide.
Cela me sera d'une grande aide dans mes recherches et me permettra d'acquérir beaucoup de connaissances à ce sujet de différentes personnes qui ont utilisé différents clients dans le passé.
Thrift devient de plus en plus une API héritée:
Tout d'abord, vous devez savoir que l'API Thrift n'obtiendra pas de nouvelles fonctionnalités; il est là pour la compatibilité descendante, et n'est pas recommandé pour les nouveaux projets.
- ( le paul
J'éviterais donc les API basées sur Thrift (l'épargne n'est conservée que pour la compatibilité descendante).
En disant que si vous avez besoin d'utiliser une API basée sur l'épargne, j'opterais pour Astyanax. Astyanax est très facile à utiliser (par rapport à d'autres API d'épargne, mais mon expérience personnelle est que le pilote de Datastax est encore plus facile).
Donc, vous devriez jeter un œil à Datastax's API ( et repo GitHub )? Je ne sais pas s'il existe des versions compilées de l'API à télécharger, mais vous pouvez facilement le construire avec Maven. De plus, si vous jetez un œil aux journaux de validation du dépôt GitHub, il subit des mises à jour très fréquentes.
Le pilote fonctionne exclusivement avec CQL3 et est asynchrone, mais sachez que Cassandra 1.2 est la première version prise en charge.
Performances
Astyanax est basé sur l'épargne et le lecteur de Datastax est le protocole binaire. Voici les derniers benchmarks que j'ai pu trouver entre l'épargne et le CQL (notez qu'ils sont définitivement obsolètes). Mais en toute honnêteté, la petite différence de performances indiquée dans ces benchmarks importera rarement.
Prise en charge d'Asynch
La prise en charge de Datastax asynch est un avantage certain sur Astyanax (Netflix mise en œuvre tentée mais a décidé de ne pas le faire).
Documentation
Je ne peux pas vraiment m'opposer à wiki de Netflix . La documentation est excellente et est mise à jour assez fréquemment. Leur wiki inclut des exemples de code, et vous pouvez trouver des tests dans le code source si vous avez besoin de voir le code à l'œuvre. J'ai eu du mal à trouver une documentation sur le pilote Datastax, mais les tests sont fournis dans le référentiel GitHub, donc c'est un point de départ.
Jetez également un oeil à cette réponse (enfin .. pas la mienne de toute façon) Il examine certains avantages/inconvénients de Thrift et CQL.
Je recommanderais Datastax Java pour Cassandra http://www.datastax.com .
Pour le support JPA, essayez mon outil de cartographie. http://valchkou.com/cassandra-driver-mapping.html
Axé sur les annotations Aucun fichier de mappage, aucun script, aucun fichier de configuration. Pas besoin de scripts DDL. Schéma automatiquement synchronisé avec la définition d'entité.
Exemple d'utilisation:
Entity entity = new Entity();
mappingSession.save(entity);
entity = mappingSession.get(Entity.class, id);
mappingSession.delete(entity);
disponible sur maven central
<dependency>
<groupId>com.valchkou.datastax</groupId>
<artifactId>cassandra-driver-mapping</artifactId>
</dependency>
J'ajouterais également un soutien décent. Nous publions des réponses à playORM tout le temps en cas de débordement de pile;). Il est également sur le point de commencer à prendre en charge mongodb (le travail est presque terminé) afin que tous les clients puissent fonctionner sur mongodb ou cassandra. Il a son propre langage de requête de sorte que ce port fonctionne très bien. Vous avez également toujours accès à l'interface astyanax brute lorsque vous avez vraiment besoin de la vitesse.
De plus, votre note sur asynch ... thrift auparavant ne prenait pas en charge asynch donc aucun client ne l'a fait non plus car ils ont généré le code thrift. Depuis que cela a changé, je ne connais pas de client qui a ajouté le truc asynchrone.
Je sais que hbase a un client asynchrone cependant. Quoi qu'il en soit, je pensais simplement ajouter mes 2 cents au cas où cela aiderait un peu.
EDIT: J'étais récemment dans le code source généré par cassandra-thrift et ce n'est pas une très bonne api pour le développement asynchrone avec send et une méthode recv () mais vous ne savez pas quand appeler la méthode recv. Aaron morton sur cassandra a un blog sur la façon dont vous pouvez vraiment le faire mais ce n'est pas du tout propre ... devez saisir le sélecteur de l'épargne au fond et faire des choses savoir quand appeler la méthode recv ... des trucs assez méchants.
plus tard, Dean
J'ai utilisé Hector, Astyanax et Thrift directement. J'ai également utilisé le client Python PyCassa.
Les caractéristiques que j'ai trouvées importantes et différenciantes étaient:
- Facilité d'utilisation de l'API
- Support de colonne composite
- Mise en commun des connexions
- Latence
- Documentation
L'un des problèmes majeurs est d'obtenir les types corrects. Vous voulez pouvoir passer en longs, Strings, byte [], etc. Hector et Astyanax résolvent cela en utilisant des objets Serializer. Dans Astyanax, vous les spécifiez plus haut dans la chaîne, vous devez donc les spécifier moins souvent. Dans Hector, la syntaxe est souvent très maladroite et difficile à adapter si vous modifiez votre schéma.
Étant donné que Python a des types dynamiques, il est beaucoup plus facile de traiter cela dans PyCassa. Comme ce n'est pas une option pour vous, je n'en dirai pas beaucoup, mais je l'ai trouvé plus facile à utiliser ( de loin) mais aussi assez lent.
Le support des colonnes composites est très déroutant dans Hector. Astyanax a des annotations pour simplifier grandement cela.
Pour autant que je sache, la mise en commun des connexions est la même pour Hector et Astyanax. Les deux éviteront les hôtes abattus et en découvriront de nouveaux ajoutés à l'anneau. Ces deux caractéristiques sont cruciales pour la fiabilité et la maintenabilité. Pelops semble avoir ces fonctionnalités mais je ne l'ai jamais essayé.
Une différence clé entre Astyanax et Hector est les optimisations de latence. Astyanax a la capacité d'acheminer les demandes de lecture et d'écriture vers un nœud de réplique, évitant potentiellement un saut de réseau supplémentaire. Cela peut réduire la latence de quelques millisecondes.
Au dernier regard, Astyanax avait une documentation médiocre, mais elle semble bien améliorée maintenant.
Le seul avantage d'Hector que je peux voir aujourd'hui est qu'il est beaucoup plus largement utilisé donc probablement moins buggy. Mais Astyanax a un meilleur ensemble de fonctionnalités.
J'ai une recommandation similaire à Valchkou. DataStax Java CQL driver, is very good. J'ai essayé astyanax, kundera et buffalosw's playorm. Astyanax est de très bas niveau et quelque peu complexe. Kundara et playorm sont des ORM génériques pour les bases de données nosql, et sont complexes pour configurer et commencer.
Les API Datastax sont assez similaires à un pilote JDBC et vous devez incorporer des instructions CQL dans votre DAO et écrire plusieurs lignes de code pour charger et enregistrer vos entités. Pour résoudre ce problème, j'ai écrit un Java mappeur d'objets appelé cassandra-jom, construit autour du pilote cql de datastax. Les annotations Cassandra-jom sont très similaires aux annotations JPA/Hibernate et peuvent même créer/mettre à jour votre schéma de famille de colonnes à partir de votre modèle d'objet. Il est facile à utiliser et fiable et utilisé dans mes autres applications Web en direct. Consultez-le sur sa page github.