mysql - una - Alternativas a las bases de datos relacionales tradicionales para flujos de actividad

para que sirve una base de datos relacional (6)

Me pregunto si alguna otra base de datos no relacional sería una buena opción para las secuencias de actividades, algo así como lo que ves en Facebook, Flickr ( http://www.flickr.com/activity ), etc. Ahora mismo, Estoy usando MySQL pero es bastante agotador (tengo decenas de millones de registros de actividad) y como básicamente se escriben solo una vez y se ven cronológicamente, pensé que un DB alternativo podría funcionar bien.

Las actividades son cosas como:

6 p.m.: John favoreció el tocino
5:30 PM: Jane comentó sobre Snow Crash
5:15 PM: Jane agregó una foto de Bacon a su álbum

El problema es que, a diferencia de Twitter y algunos otros sistemas, no puedo simplemente agregar actividades a las listas de cada usuario que esté interesado en la actividad; si pudiera, parece que Redis sería una buena opción (con sus operaciones de lista).

Necesito poder hacer lo siguiente:

Tire de las actividades para un conjunto o subconjunto de personas a las que está siguiendo ("John" y "Jane"), en el orden de fecha inverso
Tire de las actividades de una cosa (como "Bacon") en orden de fecha inverso
Filtrar por tipo de actividad ("favorito", "comentario")
Almacenar al menos 30 millones de actividades.
Lo ideal es que si agrega o elimina a una persona a la que sigue, su flujo de actividad reflejaría el cambio.

He estado haciendo esto con MySQL. Mi tabla de "actividades" es tan compacta como podría hacerlo, las claves son lo más pequeñas posibles y están indexadas apropiadamente. Funciona, pero se siente como la herramienta incorrecta para este trabajo.

¿Alguien está haciendo algo como esto fuera de un RDBMS tradicional?

Actualización de noviembre de 2009 : es muy temprano para responder a mi propia pregunta, pero mi solución actual es seguir con MySQL, pero aumentar con Redis para un acceso rápido a los nuevos datos de flujo de actividad. Más información en mi respuesta aquí: Cómo implementar el flujo de actividad en una red social ...

Actualización de agosto de 2014 : años después, sigo usando MySQL como el sistema de registro y usando Redis para un acceso muy rápido a las actividades más recientes para cada usuario. Tratar con los cambios de esquema en una tabla masiva de MySQL se ha convertido en un problema debido a pt-online-schema-change

Me parece que lo que quiere hacer (consultar un gran conjunto de datos de varias maneras diferentes y ordenar los resultados) es exactamente y precisamente para lo que se diseñó RDBMeS.

Dudo que encuentre otro almacén de datos que haga esto, así como un DBMS comercial moderno (Oracle, SQLServer, DB2, etc.) o cualquier otra herramienta de código fuente que logre esto mejor que MySql.

Podría echarle un vistazo a Googles BigTable, que en realidad es una base de datos relacional, pero puede presentar una personalidad ''objetiva'' a su programa. Es excepcionalmente bueno para búsquedas de texto en formato libre y predicados complejos. Como todo (al menos la versión que puedes descargar) está implementado en Python, dudo que supere a MySql en una maratón de consultas.

Para un proyecto, una vez necesité una base de datos simple que fuera rápida para hacer búsquedas y que hiciera muchas búsquedas y solo una escritura ocasional. Acabo de terminar escribiendo mi propio formato de archivo.

Si bien también puede hacer esto, es bastante complejo, especialmente si necesita admitirlo desde un servidor web. Con un servidor web, al menos necesitaría proteger cada escritura en el archivo y asegurarse de que pueda leerse desde varios subprocesos. El diseño de este formato de archivo es algo que debe hacer lo mejor posible con un montón de pruebas y experimentos. Un error menor podría resultar fatal para un proyecto web en este estilo, pero si lo haces funcionar, puede funcionar muy bien y extremadamente rápido.

Pero para el 99,999% de todas las situaciones, no desea una solución tan personalizada. Es más fácil simplemente actualizar el hardware, pasar a Oracle, SQL Server o InterBase, usar un servidor de base de datos dedicado, usar discos duros más rápidos, instalar más memoria, actualizar a un sistema de 64 bits. Esos son los trucos más genéricos para mejorar el rendimiento con el menor esfuerzo.

Realmente, realmente, sugeriría quedarme con MySQL (o un RDBMS) hasta que entienda completamente la situación.

No tengo idea de cuánto rendimiento o cantidad de datos planea utilizar, pero las filas de 30 M no son muchas.

Si necesita optimizar ciertas exploraciones de rango, puede hacer esto con (por ejemplo) InnoDB seleccionando una clave principal (agrupada implícitamente) de manera juiciosa, y / o desnormalizando cuando sea necesario.

Pero como la mayoría de las cosas, haga que funcione primero, luego solucione los problemas de rendimiento que detecte en su laboratorio de pruebas de rendimiento en hardware de grado de producción.

EDIT: Algunos otros puntos:

La base de datos de claves / valores, como Cassandra, Voldermort, etc., generalmente no admite índices secundarios.
Por lo tanto, no puedes hacer un INDICE CREAR
La mayoría de ellos tampoco realizan escaneos de rango (incluso en el índice principal) porque utilizan el hash para implementar la partición (que en su mayoría hacen).
Por lo tanto, tampoco hacen caducidad de rango (BORRAR DE tbl DONDE TS <AHORA () - INTERVALO 30 DÍAS)
Su aplicación debe hacer TODO esto por sí mismo o gestionar sin él; Los índices secundarios son realmente el asesino
ALTER TABLE ... ADD INDEX lleva bastante tiempo en, por ejemplo, MySQL con una tabla grande, pero al menos no tiene que escribir mucho código para hacerlo. En una base de datos "nosql", también tomará mucho tiempo PERO también tendrá que escribir montones y montones de código para mantener el nuevo índice secundario, caducarlo correctamente, Y modificar sus consultas para usarlo.

En resumen ... no puede usar una base de datos clave / valor como acceso directo para evitar ALTER TABLE.

Recomiendo aprender sobre la tecnología de la cola de mensajes . Hay varias opciones de código abierto disponibles, y también productos comerciales robustos que servirían el volumen que usted describe como un pequeño refrigerio.

También estoy planeando alejarme de SQL. He estado mirando CouchDB , que parece prometedor. Teniendo en cuenta sus requisitos, creo que todo se puede hacer con las vistas de CouchDB y la lista de api.

CouchDB está libre de esquemas y es bastante sencillo recuperar una gran cantidad de datos rápidamente, porque está trabajando solo con índices. No está "consultando" la base de datos cada vez, está recuperando solo las claves coincidentes (que están pre-ordenadas por lo que es aún más rápido).

Las "vistas" se vuelven a indexar cada vez que se ingresan nuevos datos en la base de datos, pero esto se realiza de manera transparente para el usuario, por lo que si bien puede haber un retraso potencial en la generación de una vista actualizada, casi nunca habrá ningún retraso en la recuperación de los resultados.

Acabo de comenzar a explorar la creación de una solución de "flujo de actividad" utilizando CouchDB, y como el paradigma es diferente, mi pensamiento sobre el proceso tuvo que cambiar desde el pensamiento de SQL.

En lugar de averiguar cómo consultar los datos que deseo y luego procesarlos en la página, en cambio, genero una vista que identifica todos los documentos por fecha, por lo que puedo crear fácilmente múltiples grupos de datos, simplemente utilizando la clave de fecha apropiada, esencialmente ejecutando varias consultas simultáneamente, pero sin degradación en el rendimiento.

Esto es ideal para flujos de actividad, y puedo aislar todo por fecha o, junto con el aislamiento de fecha, puedo filtrar aún más los resultados de un subtipo en particular, etc., creando una vista según sea necesario y porque la vista en sí misma solo usa javascript y todo. Los datos en CouchDB son JSON, prácticamente todo puede hacerse del lado del cliente para representar su página.