Comparación de bases de datos NoSQL para Java

Question

Quiero obtener más información sobre las bases de datos/data-stores NoSQL disponibles para su uso desde Java, y hasta ahora probé Project Voldemort. Excepto por el nombre terriblemente elegido, parece estar bien hasta ahora.

Me gustaría obtener más información acerca de otros sistemas de bases de datos similares. Ahora, en wikipedia article hay una lista de algunos de ellos, y hay algo de documentación en sus páginas de proyectos.

Sin embargo, en lugar de comparar las especificaciones técnicas y tutoriales proporcionados por autores, lo que me gustaría saber es:

¿Cuáles son sus experiencias con el trabajo con estas bibliotecas en proyectos reales? ¿Cuál recomendaría para usar en función de esa experiencia, cuál no y por qué?

Sé que solo las personas que pueden responder esta pregunta son las que realmente usaron más de una de esas bases de datos, pero espero que alguien lo haya hecho.

EDIT:

Por "proyecto real" que significa ante todo un proyecto en producción (pero en ausencia de éstos nada más grande que una tarea o tutorial terminado aplica).

Trabajé con una base de datos relacional que tenía una enorme cantidad de datos, la mayoría concentrada en una sola tabla, que de todos modos se desnormalizó para el rendimiento. Pero, debido a todo el lío con restricciones, etc., la creación de un clúster utilizable había arrojado resultados horribles tanto en la estabilidad como en el rendimiento.

Ahora, estoy bastante seguro de que probablemente cualquiera de estos sistemas NoSQL sería una mejor opción que la que tenía a disposición. Pero, tiene que haber una diferencia entre ellos, también. Ya sea en documentación, estabilidad entre versiones, comunidad, facilidad de uso, lo que sea ... Y hay muchos gigantes. ¿Qué hombros elegir? : D

Answer 1

Es muy difícil elegir una buena opción sin saber exactamente cuál es su caso de uso. Gran parte depende del tipo de modelo de datos con el que se sienta cómodo y se ajuste a sus necesidades. Tiene almacenes de clave-valor, orientados a documentos, orientados a columnas, etc. Otro gran factor es la escala de escala de productos y la forma en que eligen lidiar con las compensaciones de disponibilidad/consistencia.

Me gusta MongoDB. Me gusta cómo admite consultas y me gustan los modelos de datos orientados a documentos. Encaja en muchos problemas con los que parece toparse. Hay una gran comunidad (con capital G) como se vio en el reciente evento de MongoSV.

Lo mejor que puedes hacer es elegir 3 productos diferentes y evaluarlos. También vería si puede encontrar algunas compañías que han presentado en conferencias y contar sus historias de cómo tuvieron éxito. Los videos de MongoSV estarán disponibles pronto.

Answer 2

Hemos estado trabajando con HBase para nuestros proyectos. Nuestra experiencia es -

• La comunidad es muy dinámico y extremadamente útil
• El procedimiento de instalación para los desarrolladores es muy fácil, ya sea en la pseudo distribuida o modo autónomo
• Hemos estado utilizando para la prueba de integración, como las pruebas unitarias
• La instalación de un clúster también es fácil, pero la comparación de algunos otros NoSQL tiene más componentes para instalar que otros.
• Administración: todavía está en curso, por lo que no puedo decir mucho que decir al respecto.
• No lo utilice para SQL como consultas SELECT, para los que estamos utilizando Apache Solr
• Para hacer que el desarrollo y la prueba más fácil que hemos llegado con un simple objeto mapper - https://github.com/smart-it/smart-dao
• La razón por la que elegí es HBase, al igual que otros NoSQL, resuelve la fragmentación, escalando por diseño haciéndolo más fácil a largo plazo y que parece mantenerse bien.

Answer 3

Quizás la más destacada de las soluciones Java NoSQL es Cassandra. Tiene algunas características más allá de Voldemort (partícipe de preservación de pedidos que permite consultas de rango, estructura de estilo de BigTable); y le faltan otros (sin backends de almacenamiento alternativos o relojes de versión para el control de versiones). Su rendimiento es más óptimo para escrituras rápidas, pero su mayor fortaleza es probablemente la facilidad con la que se puede escalar horizontalmente al agregar nuevos nodos (algo donde V es un poco más estático). Comparado con, digamos, MongoDB, su modelo de datos es bastante simple y a menudo no tiene sentido usar mucho más que abstracción de clave/valor (es decir, manejar la asignación de datos en el cliente, almacenar objetos serializados). Tiene replicación y distribución completas, a diferencia de algunas tiendas k/v (couchdb, por lo que entiendo).