¿Qué BD noSQL agrupada para un propósito de almacenamiento de mensajes?

Question

Otra pregunta más sobre qué NoSQL elegir. Sin embargo, aún no he encontrado a alguien que me solicite este tipo de propósito, almacenando mensajes ...

Tengo un servidor de chat Erlang, ya estoy usando MySQL para almacenar mi lista de amigos, y "ÚNASE necesario" informaciones

Me gustaría almacenar Mensajes (Ese usuario no ha recibido porque no estaba conectado ...) y recuperarlos.

He hecho una preselección de NoSQL, no puedo usar cosas como MongoDB debido a su paradigma orientado a RAM, y no puedo agruparme como otros. tengo por mi lista de 3 opciones supongo:

• hbase
• Riak
• Cassandra

Sé que su modelo se dejó diferente, utilizando la clave/valor, el otro usando SuperColumns y co.

Hasta ahora tenía una preferencia por Riak debido a que es una biblioteca cliente estable para Erlang.

sé que puedo usar con Cassandra Thrift, pero no parece muy estable con Erlang (no he conseguido un buen rendimiento en ello)

Realmente no sé nada de HBase en este momento, justo Sé que existe y está basado en Dynamo como Cassandra y Riak.

Así que esto es lo que tiene que hacer:

• tienda de 1 a X mensajes por usuario registrado.
• Obtenga la cantidad de mensajes almacenados por usuario.
• recuperar todos los mensajes de un usuario a la vez.
• borra todos los mensajes de un usuario a la vez.
• eliminar todos los mensajes que son más de X meses

En este momento, estoy realmente nuevo a los NoSQL DB, siempre he estado un aficionados MySQL, Esto es por lo que te haga esta pregunta, como un novato , alguien que tenga más experiencia que yo podría ayudarme a elegir cuál es mejor, y me dejaría hacer todo lo que quiero sin mucha molestia ...

¡Gracias!

Answer 1

No puedo hablar por Cassandra o Hbase, pero déjame abordar la parte de Riak.

Sí, Riak sería apropiado para su escenario (y he visto varias empresas y redes sociales usarlo para un fin similar).

Para implementar esto, necesitaría las operaciones sencillas de Riak Key/Value, más algún tipo de motor de indexación. Sus opciones son (en orden aproximado de preferencia):

1. CRDT Establece. Si el tamaño de su colección 1-N es de un tamaño razonable (digamos que hay menos de 50 mensajes por usuario o lo que sea), puede almacenar las claves de la colección secundaria en CRDT Set Data Type.

2. Riak Buscar. Si el tamaño de su colección es grande, y especialmente si necesita buscar sus objetos en campos arbitrarios, puede usar Riak Search. Hace girar Apache Solr en segundo plano e indexa tus objetos de acuerdo con un esquema que defines. Tiene búsquedas, agregaciones y estadísticas bastante increíbles, capacidades geoespaciales, etc.

3. Índices secundarios. Puede ejecutar Riak encima de eLevelDB storage back end y habilitar la funcionalidad Secondary Index (2i).

Ejecute algunas pruebas de rendimiento, para elegir el enfoque más rápido.

En cuanto al esquema, recomendaría usar dos cubos (para la configuración que describe): un depósito de usuario y un depósito de mensajes.

Indexe el depósito de mensajes. (Al asociar un índice de búsqueda con él o al almacenar una clave de usuario a través de 2i). Esto le permite hacer todas las operaciones necesarias (y el registro de mensajes no tiene que caber en la memoria):

• tienda de 1 a X mensajes por usuario registrado - Una vez que se crea un objeto de usuario y obtener una la clave de usuario, almacenar una cantidad arbitraria de mensajes por usuario es fácil; se escribirían directamente en el depósito de Mensajes, cada mensaje almacenando la clave de usuario apropiada como índice secundario.
• Obtenga la cantidad de mensajes almacenados por usuario - No hay problema. Obtenga la lista de claves de mensajes que pertenecen a un usuario (mediante una consulta de búsqueda, recuperando el objeto Set donde guarda las claves, o mediante una consulta 2i en user_key). Esto le permite contar el lado del cliente.
• recuperar todos los mensajes de un usuario a la vez - Ver el artículo anterior. Obtenga la lista de claves de todos los mensajes que pertenecen al usuario (a través de Búsqueda, Conjuntos o 2i) y luego busque los mensajes reales para esas teclas mediante la función de búsqueda múltiple de los valores de cada clave (todos los clientes oficiales de Riak tienen una capacidad de multiFetch, lado del cliente).
• borrar todos los mensajes de un usuario a la vez - Muy similar. Obtenga una lista de claves de mensaje para el usuario, emite Deleciones en el lado del cliente.
• borrar todos los mensajes anteriores a X meses - Puede agregar un índice en Fecha. A continuación, recupere todas las claves de mensaje anteriores a X meses (a través de Buscar o 2i) y emita las Eliminaciones del lado del cliente.

Answer 2

No puedo hablar con Riak en absoluto, pero cuestionaría su elección para descartar a Mongo. Es bastante bueno siempre y cuando deje el diario apagado y no lo mate por completo para RAM.

Sé mucho sobre HBase, y parece que satisfaría sus necesidades fácilmente. Podría ser excesivo según la cantidad de usuarios que tenga. Es trivialmente compatible con cosas como almacenar muchos mensajes por usuario y tiene funcionalidad para la caducidad automática de las escrituras. Dependiendo de cómo diseñe su esquema, puede ser o no atómico, pero eso no debería importar para su caso de uso.

Las desventajas son que hay una gran cantidad de sobrecarga para configurarlo correctamente.Necesitas saber Hadoop, ejecutar HDFS, asegurarte de que tu namenode sea confiable, etc. antes de levantarte de HBase.

Answer 3

Recomendaría usar clave distribuida/tienda de valores como Riak o Couchbase y mantener todo el registro de mensajes para cada usuario serializado (en términos erlang binarios o JSON/BSON) como un valor.

Así que con sus casos de uso que se verá así:

• tienda de 1 a X mensajes por usuario registrado - cuando el usuario se conecta generar un stateful gen_server, que recibe de almacenamiento y deserializa el mensaje entero inicie sesión en el inicio, recibe nuevos mensajes, los agrega a su copia de registro, al final de la sesión finaliza, serializa el registro modificado y lo envía al almacenamiento.
• Obtenga la cantidad de mensajes almacenados por usuario - obtenga el cierre de sesión, deserialize, count; o tal vez el recuento de la tienda al costado en un par de k/v por separado.
• recuperar todos los mensajes de un usuario a la vez - simplemente sáquelo del almacenamiento.
• borre todos los mensajes de un usuario a la vez - simplemente elimine el valor del almacenamiento.
• borrar todos los mensajes anteriores a X meses - obtener, filtrar, volver a colocar.

La limitación obvia: el registro de mensajes debe caber en la memoria.

Si decide almacenar cada mensaje individualmente, necesitará una base de datos distribuida para ordenarlos después de la recuperación si desea que estén en orden cronológico, por lo que difícilmente será útil manejar conjuntos de datos más grandes que la memoria. Si es necesario, de todos modos terminará con un esquema más complicado.