java - usar - sentencias de nosql
¿Qué implementación de NoSQL es la más adecuada? (5)
Soy nuevo en NoSQL, y me estoy rascando la cabeza tratando de descubrir la implementación de NoSQL más apropiada para la aplicación que estoy tratando de construir.
Mi aplicación Java necesita tener un hashmap en memoria que contenga de millones a miles de millones de entradas, ya que modela una red neuronal de una sola capa. En este momento estamos usando Trove para poder usar primitivas como claves y valores para reducir el tamaño del mapa y aumentar la velocidad de acceso. El mapa es un mapa de mapas donde las claves del mapa exterior son largas y los mapas interiores tienen clave / valores largos / flotantes.
Necesitamos poder leer el estado guardado del disco en el mapa de mapas cuando se inicia la aplicación. Los cambios en el mapa de los mapas también deben guardarse en el disco de forma continua o según un intervalo programado.
Al principio me sentí atraído hacia OrientDB debido a su documento y objetos DB, aunque todavía no estoy seguro en este punto, qué sería mejor. Luego me encontré con Redis , que es un almacén de valores clave y trabaja con un conjunto de datos en memoria que se puede volcar en el disco, incluida la replicación maestro-esclavo. Sin embargo, no parece que los valores del mapa puedan ser otros que Strings.
¿Estoy buscando en los lugares correctos una solución a mis necesidades? En este momento, me gusta el aspecto en memoria y maestro-esclavo de Redis, pero me gustan las capacidades de objetos / documentos de OrientDB ya que mis estructuras de datos son más complicadas que las cadenas simples y puedo usar Trove con los tipos de clave / valor primitivos es muy ventajoso Sería mejor si leer fuera barato y escribir fuera caro, y no al revés.
¿Pensamientos?
Si desea usar Redis para esto, probablemente sea más adecuado usar ZSET o HASH como estructuras subyacentes (Redis admite estructuras, no solo valores de cadena). A menos que necesite recuperar las partes de sus mapas en función de los valores / orden ordenado de los valores, HASH probablemente sea el mejor (en términos de memoria y velocidad).
Entonces, probablemente quieras usar un largo -> {largo: flotar, ...}. Es decir, anhela la asignación a mapas largos / flotantes. A continuación, puede buscar entradas individuales en el mapa con HGET, múltiples entradas con HMGET o el mapa completo con HGETALL. Puede ver la referencia del comando http://redis.io/commands
En lo que respecta al ahorro de espacio, dependiendo del tamaño esperado de sus HASH, es posible que pueda sintonizarlos para usar menos espacio con un efecto limitado / sin efectos negativos en el rendimiento.
En lo que respecta a la persistencia, puede ejecutar Redis con instantáneas o usar el almacenamiento incremental con archivos de solo anexar. Puede ver la documentación de persistencia aquí: http://redis.io/topics/persistence
Si desea hacer más preguntas específicas, debe dirigirse a la lista de correo https://groups.google.com/forum/?fromgroups=#!topic/redis-db/33ZYReULius
¿Por qué no simplemente serializar las estructuras de datos de Trove directamente en el disco? Parece que hay algún tipo de apoyo para eso a juzgar por la documentación ( http://trove4j.sourceforge.net/javadocs/serialized-form.html ), pero es difícil de decir porque es todo cruft autogenerado en lugar de amorosamente- tutoriales hechos Aún así, para su caso de uso no es obvio por qué necesita una base de datos adecuada, por lo que quizás se aplique KISS.
OrientDB tiene el motor más flexible con índices, gráficos, transacciones y documentos complejos como JSON. Por qué no?
Echa un vistazo a Java-Chronicle . Es una biblioteca de persistencia de baja latencia. Creo que puede encontrar que ofrece un excelente rendimiento para este tipo de datos.
Redis admite estructuras de datos más complejas que cadenas simples como listas, conjuntos (ordenados) o hashes que pueden ser útiles para su modelo de dominio. Por otro lado, su red neuronal puede aprovechar las ricas capacidades de gráfico de OrientDB dependiendo de su estructura.