erlang - relacionales - nosql tutorial

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

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

Tengo un servidor de chat de Erlang hecho, ya estoy usando MySQL para almacenar la lista de amigos, y "ÚNASE información necesaria".

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 mi lista de 3 opciones, supongo:

Hbase
Riak
Cassandra

Sé que su modelo es diferente, uno usa clave / valor y el otro usa 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 Cassandra con Thrift, pero parece no ser muy estable con Erlang (no obtuve buenos resultados al respecto)

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

Entonces, esto es lo que necesito hacer:

Almacene 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.
eliminar todos los mensajes de un usuario a la vez.
eliminar todos los mensajes que son anteriores a X meses

En este momento, soy realmente nuevo en esos NoSQL DB, siempre he sido un fanático de MySQL, por eso le hago esta pregunta, como un novato, alguien que tenga más experiencia de la que podría ayudarme a elegir cuál es mejor , y me dejaría hacer todo lo que quiero sin mucha molestia ...

Gracias !

No puedo hablar con Riak en absoluto, pero cuestionaría tu 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 tus 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.

Recomiendo usar claves distribuidas / tiendas de valores como Riak o Couchbase y mantener todo el registro de mensajes para cada usuario serializado (en términos de erlang binarios o JSON / BSON) como un valor.

Entonces, con sus cajas de uso se verá así:

Almacene de 1 a X mensajes por usuario registrado : cuando el usuario entra en línea genera un gen_server con estado, que obtiene del almacenamiento y deserializa todo el registro de mensajes al 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, deserialice, cuente; o tal vez el recuento de la tienda al costado en un par de k / v por separado.
recupera todos los mensajes de un usuario a la vez - solo sácalo del almacenamiento.
borre todos los mensajes de un usuario a la vez - simplemente elimine el valor del almacenamiento.
elimine todos los mensajes que tienen más de X meses : obtener, filtrar y volver a enviar .

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

Si decide almacenar cada mensaje individualmente, requerirá que la base de datos distribuida los ordene 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.

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 compañías y redes sociales usarlo para un propósito 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):

Conjuntos CRDT . Si su tamaño de recopilació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 un tipo de datos de conjunto CRDT .
Riak Search . 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 una búsqueda, agregación y estadísticas bastante increíbles, capacidades geoespaciales, etc.
Índices secundarios . Puede ejecutar Riak encima de un servidor de almacenamiento eLevelDB y habilitar la funcionalidad de índice secundario (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 cubo 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 requeridas (y el registro de mensajes no tiene que caber en la memoria):

Almacenar de 1 a X mensajes por usuario registrado : una vez que crea un objeto de usuario y obtiene una clave de usuario, almacenar una cantidad arbitraria de mensajes por usuario es fácil, sería escribir directamente en el depósito de mensajes, cada mensaje almacenando la clave de usuario adecuada como un í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 (a través de 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 artículo anterior. Obtenga la lista de las claves de todos los mensajes que pertenecen al usuario (a través de Buscar, 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 capacidad de multiFetch , lado del cliente).
eliminar 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.
eliminar todos los mensajes anteriores a X meses : puede agregar un índice en Fecha. Luego, recupere todas las claves de mensaje anteriores a X meses (a través de Buscar o 2i) y envíe las Eliminaciones del lado del cliente.