Ruby On Rails / Merb como interfaz para una aplicación de miles de millones de registros

Question

Estoy buscando una solución back-end para una aplicación escrita en Ruby on Rails o Merb para manejar datos con varios miles de millones de registros. Tengo la sensación de que se supone que debo ir con un modelo distribuido y en este momento miré

HBase con Hadoop

Couchdb

Problemas con la solución de HBase tal como la veo: el soporte de ruby ??no es muy fuerte y Couchdb aún no alcanzó la versión 1.0.

¿Tiene alguna sugerencia sobre qué usaría para una cantidad de datos tan grande?

Los datos requerirán importaciones bastante rápidas a veces de 30-40Mb a la vez, pero las importaciones vendrán en trozos. Entonces ~ 95% del tiempo los datos serán de solo lectura.

Answer 1

Dependiendo de su uso real de datos, MySQL o Postgres deberían poder manejar un par de miles de millones de registros en el hardware correcto. Si tiene un gran volumen particular de solicitudes, ambas bases de datos se pueden replicar en varios servidores (y la replicación de lectura es bastante fácil de configurar (en comparación con la replicación maestra / escritura múltiple).

La gran ventaja de utilizar un RDBMS con Rails o Merb es que obtiene acceso a todo el excelente soporte de herramientas para acceder a este tipo de bases de datos.

Mi consejo es realmente perfilar sus datos en un par de estos sistemas y tomarlos desde allí.

Answer 2

Hay varias soluciones diferentes que la gente ha usado. En mi experiencia, realmente depende más de sus patrones de uso relacionados con esos datos y no de la gran cantidad de filas por tabla.

Por ejemplo, " Cuántas inserciones / actualizaciones están ocurriendo por segundo. " Preguntas como estas influirán en su decisión de qué solución de base de datos de fondo elegirá.

Tomemos como ejemplo a Google: en realidad no existía una solución de almacenamiento / búsqueda que satisficiera sus necesidades, por lo que crearon la suya basada en un modelo de Mapa / Reducir.

Answer 3

Una palabra de advertencia sobre HBase y otros proyectos de esa naturaleza (no sé nada sobre CouchDB: creo que creo no es realmente un DB, solo una tienda de valores clave):

1. Hbase no está sintonizado para la velocidad; Está ajustado para la escalabilidad. Si la velocidad de respuesta es un problema, ejecute algunas pruebas de concepto antes de comprometerse con esta ruta.
2. Hbase no admite combinaciones. Si está utilizando ActiveRecord y tiene más de una relación ... bueno, puede ver a dónde va esto.

El proyecto Hive, también construido sobre Hadoop, admite uniones; también lo hace Pig (pero no es realmente sql). El punto 1 se aplica a ambos. Están destinados a tareas de procesamiento de datos pesados, no al tipo de procesamiento que probablemente realice con Rails.

Si desea escalabilidad para una aplicación web, básicamente la única estrategia que funciona es particionar sus datos y hacer todo lo posible para garantizar que las particiones estén aisladas (no es necesario que se comuniquen entre sí). Esto es un poco complicado con Rails, ya que asume por defecto que hay una base de datos central. Es posible que haya habido mejoras en ese frente desde que examiné el problema hace aproximadamente un año y medio. Si puede particionar sus datos, puede escalar horizontalmente bastante ancho. Una sola máquina MySQL puede manejar unos pocos millones de filas (PostgreSQL probablemente puede escalar a un mayor número de filas, pero podría funcionar un poco más lento).

Otra estrategia que funciona es tener un maestro-esclavo configurado, donde todas las escrituras son realizadas por el maestro, y las lecturas se comparten entre los esclavos (y posiblemente el maestro). ¡Obviamente esto tiene que hacerse con bastante cuidado! Suponiendo una alta relación lectura / escritura, esto puede escalar bastante bien.

Si su organización tiene mucho dinero, vea lo que Vertica, AsterData y Greenplum tienen para ofrecer.

Answer 4

El backend dependerá de los datos y de cómo se accederá a ellos.

Pero para el ORM, lo más probable es que use DataMapper y escriba un adaptador de DataObjects personalizado para llegar al backend que elija.

Answer 5

No estoy seguro de qué CouchDB no está en 1.0 tiene que ver con eso. Recomiendo hacer algunas pruebas con él (solo generar un billón de documentos aleatorios) y ver si se mantiene. Yo diría que lo hará, a pesar de no tener un número de versión específico.

CouchDB lo ayudará mucho cuando se trata de particionar / fragmentar sus datos y parece que podría encajar con su proyecto, especialmente si su formato de datos puede cambiar en el futuro (agregar o eliminar campos) desde las bases de datos CouchDB no tiene esquema.

También hay muchas optimizaciones en CouchDB para aplicaciones con mucha lectura y, según mi experiencia con él, es donde realmente brilla.