Alternativas a las bases de datos relacionales tradicionales para las corrientes de actividades

Question

Me pregunto si alguna otra base de datos no relacional sería adecuada para las secuencias de actividad, algo así como lo que ve en Facebook, Flickr (http://www.flickr.com/activity), etc. En este momento, Estoy usando MySQL, pero es bastante agotador (tengo decenas de millones de registros de actividad) y dado que son básicamente de solo lectura, una vez escritos y siempre vistos cronológicamente, pensé que una base de datos alternativa podría funcionar bien.

Las actividades son cosas como:

• 6 PM: John favorited tocino
• 17:30: Jane comentado en Snow Crash
• 17:15: Jane añadido una foto de Bacon su álbum

el problema es que a diferencia de Twitter y algunos otros sistemas, no puedo simplemente agregar actividades a las listas para cada usuario que esté interesado en la actividad - si pudiera parece que Redis would be a good fit (con su lista de operaciones).

tengo que ser capaz de hacer los siguientes:

• actividades y jalar para un conjunto o un subconjunto de personas que se están siguiendo ("Juan" y "Jane"), en orden cronológico inverso
• actividades de atracción para una cosa (como "tocino") en orden cronológico inverso
• Filtrar por tipo de actividad ("favorito", "comentario") en
• tienda menos 30 millones de actividades
• Idealmente, si agrega o elimina a una persona a la que está siguiendo, su flujo de actividad reflejará el cambio.

He estado haciendo esto con MySQL. Mi tabla de "actividades" es tan compacta como pude, las claves son lo más pequeñas posibles y está indexada de forma adecuada. 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 demasiado pronto para responder a mi propia pregunta, pero mi solución actual es seguir con MySQL, sino aumentar con Redis para un acceso rápido a los datos de flujo de actividad frescas. Más información en mi respuesta aquí: How to implement the activity stream in a social network ...

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

Answer 1

También estoy planeando alejarme de SQL. He estado mirando CouchDB, que parece prometedor. En cuanto a sus requisitos, creo que todo se puede hacer con vistas de CouchDB y la API de la lista.

Answer 2

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

Si bien puede hacer esto también, es bastante complejo, especialmente si necesita soportarlo desde un servidor web. Con un servidor web, al menos necesitaría proteger cada escritura en el archivo y asegurarse de que se pueda leer desde múltiples hilos. El diseño de este formato de archivo es algo que debes resolver lo mejor posible con muchas pruebas y experimentos. Un error menor podría ser fatal para un proyecto web con 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 mínimo esfuerzo.

Answer 3

Realmente, realmente, le sugiero que se quede con MySQL (o un RDBMS) hasta que comprenda completamente la situación.

No tengo idea de cuánto rendimiento o mucha información planeas usar, pero 30M filas no son muchas.

Si necesita optimizar ciertos escaneos de rango, puede hacerlo con (por ejemplo) InnoDB eligiendo juiciosamente una clave primaria (clúster implícita) y/o denormalizando cuando sea necesario.

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

---

EDIT: Algunos otros puntos:

• base de datos clave/valor como Cassandra, Voldemort, etc, por lo general no soportan índices secundarios
• Por lo tanto, no se puede hacer un CREATE INDEX
• La mayoría de ellos tampoco hacen escaneos de rango (incluso en el índice principal) porque están usando hashing para implementar particiones (lo que hacen principalmente).
• Por lo tanto, también no hacer caducidad gama (CANCELACIÓN de TBL Donde AI < NOW() - INTERVALO DE 30 DÍAS)
• La aplicación debe hacer todo esto en sí o es propietario sin ella; los índices secundarios son realmente el asesino
• ALTER TABLE ... ADD INDEX tarda bastante tiempo en, por ej. MySQL con una tabla grande, pero al menos no tienes que escribir mucho código para hacerlo. En una base de datos "nosql", también llevará mucho tiempo PERO también debe 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 clave/base de datos de valores como atajo para evitar ALTER TABLE.

Answer 4

Yo recomendaría aprender acerca de la tecnología message queue. 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.

Answer 5

Me parece que lo que quiere hacer - Consultar un gran conjunto de datos de diferentes maneras y ordenar los resultados - es exactamente y para qué se diseñaron los RDBMeS.

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

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

Answer 6

CouchDB es un esquema, 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, solo está recuperando claves coincidentes (que están preordenadas, lo que lo hace aún más rápido).

Las "vistas" se vuelven a indexar cada vez que se ingresan datos nuevos en la base de datos, pero esto se lleva a cabo de forma transparente para el usuario, por lo que es probable que haya un retraso potencial en la generación de una vista actualizada. recuperando resultados.

Acabo de comenzar a explorar la construcció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 SQL.

En lugar de averiguar cómo consultar los datos que quiero y luego procesarlos en la página, en su lugar genero una vista que claves todos los documentos por fecha, para que pueda crear fácilmente múltiples grupos de datos, solo usando el Clave de fecha, esencialmente ejecutando varias consultas simultáneamente, pero sin degradación en el rendimiento.

Esto es ideal para secuencias de actividad, y puedo aislar todo por fecha, o junto con el aislamiento de fecha puedo filtrar los resultados de un subtipo en particular, etc. - creando una vista según sea necesario, y porque la vista en sí misma el uso de javascript y todos los datos en CouchDB son JSON, prácticamente todo se puede hacer desde el lado del cliente para renderizar su página.