Cassandra Client Java API''s
hector astyanax (5)
Recientemente he comenzado a trabajar con la base de datos Cassandra. Ahora estoy en el proceso de evaluar qué Cassandra client
deberíamos seguir adelante.
He visto varias publicaciones en stackoverflow sobre qué cliente usar para Cassandra, pero ninguna tiene una respuesta definitiva.
Mi equipo me ha pedido que realice una investigación sobre este tema y pros and cons
ciertas pros and cons
para cada Cassandra Client API''s
en Java.
Como mencioné, recientemente me involucré con Cassandra
así que no tengo mucha idea de por qué ciertas personas eligen a los Pelops client
y por qué ciertas personas van con Astyanax
y otros clientes.
Sé cosas breves sobre cada uno de los clientes de Cassandra, por lo que quiero decir que puedo hacer que funcione y comenzar a leer y escribir en la base de datos de Cassandra.
A continuación se muestra la información que tengo hasta ahora.
CASSANDRA APIS
Héctor (listo para producción)
La API de Java más estable, lista para el prime-time.Astyanax (The Up and Comer)
Una API de Java limpia de Netflix. No es tan usado como Hector, pero es sólido.Kundera (El NoSQL ORM)
Compatible con JPA, esto es útil cuando desea interactuar con Cassandra a través de objetos.
Esto lo restringe un poco, ya que no podrá tener un número dinámico de columnas / nombres, etc. Pero le permite migrar a través de ORM o centralizar el almacenamiento en Cassandra para usos más tradicionales.Pelops
Sólo he usado Pelops brevemente. Era una API directa, pero no parecía tener el impulso por detrás.PlayORM (ORM sin las restricciones?)
Acabo de enterarme de esto. Parece que está tratando de resolver el desajuste de impedancia entre los ORM basados en JPA tradicionales y NoSQL mediante la introducción de JQL. Se ve prometedor.Thrift (¡Evítame!)
Esta es la API de "bajo nivel".
A continuación están nuestras prioridades para decidir a Cassandra Client
:
- Las primeras prioridades son: baja sobrecarga de latencia, API asíncrona y confiabilidad / estabilidad para el entorno de producción.
(Por ejemplo, una API más fácil de usar que se puede tener en el DAL que envuelve al cliente). - La agrupación de conexiones y el reconocimiento de particiones son otras buenas características que debe tener.
- Capaz de detectar cualquier nuevo nodo que se haya agregado.
- Buen apoyo también (como lo señala el decano más abajo)
¿Alguien puede dar algunos pensamientos sobre esto? Y también cualquier ventaja y desventaja para cada Cassandra Client
y también qué cliente puede cumplir mis requisitos también será de gran ayuda.
Creo que, principalmente, estaré girando en torno al Astyanax client or New Datastax client that uses Binary protocol
supongo Astyanax client or New Datastax client that uses Binary protocol
en mi investigación hasta ahora. Pero no tengo cierta información que respalde mi investigación y la presente a mi equipo.
Cualquier comparación entre el cliente de Astyanax y el cliente de New Datastax (que utiliza el nuevo protocolo binario) será de gran ayuda.
Me será de gran ayuda en mi investigación y obtendré muchos conocimientos sobre esto de diferentes personas que han usado diferentes clientes en el pasado.
He usado Hector, Astyanax y Thrift directamente. También he usado el cliente Python PyCassa.
Las características que me parecieron importantes y diferenciadoras fueron:
- Facilidad de uso de la API.
- Soporte de columna compuesta
- Agrupación de conexiones
- Estado latente
- Documentación
Uno de los principales problemas es obtener los tipos correctos. Desea poder pasar largos, cadenas, bytes [], etc. Tanto Hector como Astyanax resuelven esto utilizando objetos Serializer. En Astyanax, los especificas más arriba en la cadena, por lo que debes especificarlos con menos frecuencia. En Hector, la sintaxis es a menudo muy torpe y difícil de adaptar si cambias tu esquema.
Como Python tiene tipos dinámicos, es mucho más fácil lidiar con esto en PyCassa. Como no es una opción para ti, no diré mucho al respecto, pero me pareció más fácil de usar (por mucho) pero también bastante lento.
El soporte de columnas compuestas es muy confuso en Hector. Astyanax tiene anotaciones para simplificar enormemente esto.
Que yo sepa, la agrupación de conexiones es la misma para Hector y Astyanax. Ambos evitarán los hosts caídos y descubrirán nuevos agregados al anillo. Ambas características son cruciales para la confiabilidad y el mantenimiento. Pelops parece tener estas características, pero nunca lo he probado.
Una diferencia clave entre Astyanax y Hector son las optimizaciones de latencia. Astyanax tiene la capacidad de enrutar las solicitudes de lectura y escritura a un nodo de réplica, evitando potencialmente un salto de red adicional. Esto puede reducir la latencia en unos pocos milisegundos.
A última vista, Astyanax tenía poca documentación, pero ahora parece haber mejorado mucho.
La única ventaja de Hector que puedo ver hoy es que se usa mucho más, por lo que es probable que tenga menos buggy. Pero Astyanax tiene un mejor conjunto de características.
Recomendaría el controlador java Datastax para Cassandra http://www.datastax.com .
Para JPA como soporte prueba mi herramienta de mapeo. http://valchkou.com/cassandra-driver-mapping.html
Impulsado por anotaciones No hay archivos de mapeo, ni scripts, ni archivos de configuración. No hay necesidad de scripts DDL. Esquema sincronizado automáticamente con la definición de la entidad.
Muestra de uso
Entity entity = new Entity();
mappingSession.save(entity);
entity = mappingSession.get(Entity.class, id);
mappingSession.delete(entity);
disponible en maven central
<dependency>
<groupId>com.valchkou.datastax</groupId>
<artifactId>cassandra-driver-mapping</artifactId>
</dependency>
También me gustaría añadir un apoyo decente también. Publicamos respuestas a playORM todo el tiempo en el desbordamiento de pila;). También está a punto de comenzar a admitir mongodb (el trabajo está casi terminado), por lo que cualquier cliente puede ejecutar mongodb o cassandra. Tiene su propio lenguaje de consulta, por lo que este puerto funciona bien. Siempre tiene acceso a la interfaz de astyanax en bruto cuando realmente necesita la velocidad.
Además, su nota en asynch ... thrift anteriormente no era compatible con asynch, por lo que tampoco los clientes lo hicieron ya que generaron el código de ahorro. Dado que eso ha cambiado, no sé de un cliente que haya agregado las cosas asíncronas.
Sé que hbase tiene un cliente asíncrono sin embargo. De todos modos, solo pensé en agregar mis 2 centavos en caso de que ayude un poco.
EDITAR: Hace poco estuve en el código fuente generado por cassandra-thrift y no es una muy buena API para el desarrollo asíncrono con envío y un método recv () pero no sabe cuándo llamar al método recv. Aaron morton en la lista de usuarios de cassandra tiene un blog sobre cómo puedes hacerlo realmente, pero no está nada limpio ... tienes que tomar el selector desde el fondo y hacer algunas cosas para que sepas cuándo llamar al método recv. Cosas bastante desagradables.
despues decano
Tengo una recomendación similar a Valchkou. El controlador DataStax java CQL, es muy bueno. Probé el juego de astyanax, kundera y buffalosw. Astyanax es de muy bajo nivel y algo complejo. Kundara y Playorm son ORM genéricos para las bases de datos nosql, y son complejos de configurar y comenzar.
Las apis de Datastax son bastante similares a un controlador JDBC y tiene que incrustar sentencias CQL en su DAO y escribir varias líneas de código para cargar y guardar sus entidades. Para resolver este problema, escribí un mapeador de objetos java llamado cassandra-jom, construido alrededor del controlador datastax cql. Las anotaciones de Cassandra-jom son muy similares a las anotaciones JPA / Hibernate e incluso pueden crear / actualizar su esquema de familia de columnas a partir de su modelo de objetos. Es fácil de usar, confiable y se usa en mis otras aplicaciones web en vivo. Échale un vistazo a su página github.
Thrift es cada vez más una API heredada:
Primero, debe tener en cuenta que la API de Thrift no va a obtener nuevas características; Está ahí para la compatibilidad con versiones anteriores, y no se recomienda para nuevos proyectos.
- el paul
Así que evitaría las API basadas en Thrift (el ahorro solo se mantiene por compatibilidad con versiones anteriores).
Al decir que si necesitas usar una API basada en el ahorro, optaré por Astyanax. Astyanax es muy fácil de usar (en comparación con otras API de ahorro, pero mi experiencia personal es que el controlador de Datastax es aún más fácil).
¿Entonces deberías echar un vistazo a Datastax''s API Datastax''s ( y al repositorio de GitHub )? No estoy seguro de si hay versiones compiladas de la API para descargar, pero puede compilarlas fácilmente con Maven. Además, si echas un vistazo a los registros de confirmación del repositorio de GitHub, se someten a actualizaciones muy frecuentes.
El controlador funciona exclusivamente con CQL3 y es asíncrono, pero se advierte que Cassandra 1.2 es la primera versión compatible.
Actuación
Astyanax está basado en el ahorro y la unidad de Datastax es el protocolo binario. Aquí están los últimos benchmarks que pude encontrar entre thrift y CQL (tenga en cuenta que estos están definitivamente obsoletos). Pero para ser justos, la pequeña diferencia en el rendimiento que se muestra en estos puntos de referencia rara vez importa.
Soporte de asynch
El soporte asíncrono de Datastax''s es una ventaja definitiva sobre Astyanax (Netflix intentó implementarlo pero decidió no hacerlo).
Documentación
Realmente no puedo discutir contra la wiki de Netflix . La documentación es excelente y se actualiza con bastante frecuencia. Su wiki incluye ejemplos de código, y puedes encontrar pruebas en el código fuente si necesitas ver el código en funcionamiento. Luché para encontrar cualquier documentación del controlador Datastax; sin embargo, las pruebas se proporcionan en el repositorio de GitHub, por lo que es un punto de partida.
También eche un vistazo a esta respuesta (bueno, de todas formas no es la mía). Se observan algunas ventajas / desventajas de Thrift y CQL.