Consultas NoSQL y AdHoc - Millones de Filas

Question

Actualmente administro un sitio web basado en MySQL donde los usuarios promocionan anuncios y obtienen ingresos cada vez que alguien completa uno. Nos registramos cada vez que alguien ve un anuncio ("impresión"), cada vez que un usuario hace clic en un complemento ("clic") y cada vez que alguien completa un anuncio ("lead").

Como recibimos tanto tráfico, tenemos millones de registros en cada una de estas tablas respectivas. Luego tenemos que consultar estas tablas para que los usuarios vean cuánto se han ganado, por lo que terminamos realizando múltiples consultas en tablas con millones y millones de filas varias veces en una solicitud, cientos de veces al mismo tiempo.

Estamos buscando alejarnos de MySQL y llegar a una tienda clave-valor o algo parecido. Necesitamos algo que nos permita almacenar todos estos millones de filas, consultarlas en milisegundos y, lo que es más importante, utilizar consultas adhoc donde podamos consultar cualquier columna individual, para que podamos hacer cosas como:

FROM leads DONDE country = 'nosotros' y user_id = 501 (el equivalente NoSQL, obviamente)

DE DONDE clics ad_id = 1952 y user_id = 200 Y = país 'GB'

etc.

¿alguien tiene alguna sugerencia buena ? Estaba considerando MongoDB o CouchDB pero no estoy seguro de si pueden manejar la consulta de millones de registros varias veces por segundo y el tipo de consultas adhoc que necesitamos.

Gracias!

Answer 1

Si su conjunto de trabajo puede caber en la memoria e indexa los campos correctos en el documento, estaría todo listo. Su pregunta no es algo muy típico y estoy seguro de que con el hardware adecuado, el diseño correcto de la colección (¡desnormalización!) Y la indexación deberían estar listos. Lea sobre consultas de Mongo y use explain() para probar las consultas. Manténgase alejado de las cláusulas IN y NOT IN que serían mi sugerencia.

Answer 2

Con esos requisitos, es mejor que se quede con SQL y establezca la replicación/clustering si se encuentra con problemas de carga. Puede configurar la indexación en una base de datos de documentos para que esas consultas sean posibles, pero realmente no gana nada con respecto a su sistema actual.

Los sistemas NoSQL generalmente mejoran el rendimiento al omitir algunas de las características más complejas de los sistemas relacionales. Esto significa que solo ayudarán si su escenario no requiere esas características. Ejecutar consultas ad hoc en datos tabulares es exactamente para lo que SQL fue diseñado.

Answer 3

El mapa/reducción de CouchDB es incremental lo que significa que solo procesa un documento una vez y almacena los resultados.

Supongamos, por un momento, que CouchDB es la base de datos más lenta del mundo. Su primera consulta con millones de filas lleva, tal vez, 20 horas. Eso suena horrible. Sin embargo, su segunda consulta, su tercera consulta, su cuarta consulta y su centésima consulta demorarán 50 milisegundos, tal vez 100, incluyendo HTTP y latencia de red.

Se podría decir que CouchDB falla los puntos de referencia, pero obtiene honores en la escuela de los golpes duros.

No me preocuparía el rendimiento, sino más bien si CouchDB puede satisfacer sus requisitos de consulta ad-hoc. CouchDB quiere saber qué consultas ocurrirán, por lo que puede hacer el trabajo duro por adelantado antes de que llegue la consulta. Cuando llega la consulta, la respuesta ya está preparada y ¡listo!

Todos sus ejemplos son posibles con CouchDB. Un llamado merge-join (muchas condiciones de igualdad) no es un problema. Sin embargo, CouchDB no puede soportar múltiples consultas de desigualdad simultáneamente. No puede solicitar CouchDB, en una sola consulta, para usuarios entre 18 y 40 años que también hicieron clic menos de 10 veces.

Lo bueno de la interfaz HTTP y Javascript de CouchDB es que es fácil hacer un estudio de viabilidad rápido. ¡Te sugiero que lo pruebes!

Answer 4

Realmente depende de sus conjuntos de datos. La regla número uno para el diseño NoSQL es definir primero sus escenarios de consulta. Una vez que realmente comprenda cómo desea consultar los datos, entonces puede buscar en las diversas soluciones NoSQL que existen. La unidad de distribución predeterminada es la clave. Por lo tanto, debe recordar que necesita poder dividir sus datos entre las máquinas de su nodo de manera efectiva, de lo contrario terminará con un sistema escalable horizontalmente con todo el trabajo que todavía se está haciendo en un nodo (aunque con mejores consultas según el caso).

También debe pensar en el teorema CAP, la mayoría de las bases de datos NoSQL son finalmente consistentes (CP o AP) mientras que los DBMS relacionales tradicionales son CA. Esto afectará la forma en que manejas los datos y la creación de ciertas cosas, por ejemplo, la generación de claves puede ser engañosa.

Recuerde también que, en algunos sistemas como HBase, no existe un concepto de indexación. La lógica de la aplicación deberá generar todos sus índices y las actualizaciones y eliminaciones deberán administrarse como tales. Con Mongo puedes crear índices en los campos y consultarlos de manera relativamente rápida, también existe la posibilidad de integrar Solr con Mongo. No solo necesita consultar por ID en Mongo como lo hace en HBase, que es una familia de columnas (también conocida como la base de datos de estilo Google BigTable) en la que esencialmente tiene pares clave-valor anidados.

Así que una vez más se trata de sus datos, lo que desea almacenar, cómo va a almacenarlo y, lo más importante, cómo quiere acceder a él. El proyecto de Lily parece muy prometedor. El trabajo en el que estoy involucrado nos lleva una gran cantidad de datos de la web y lo almacenamos, lo analizamos, lo desglosamos, lo analizamos, lo transmitimos, lo actualizamos, etc. No usamos solo un sistema, sino muchos que son los más adecuados para el trabajo en cuestión. Para este proceso, utilizamos diferentes sistemas en diferentes etapas, ya que nos brinda un acceso rápido donde lo necesitamos, brinda la capacidad de transmitir y analizar datos en tiempo real y, lo que es más importante, realiza un seguimiento de todo a medida que avanzamos (como pérdida de datos en un el sistema es un gran problema). Estoy usando Hadoop, HBase, Hive, MongoDB, Solr, MySQL e incluso buenos archivos de texto antiguos. Recuerde que para producir un sistema que use estas tecnologías es un poco más difícil que instalar MySQL en un servidor, algunas versiones no son tan estables y realmente necesita hacer las pruebas primero. Al final del día, realmente depende del nivel de resistencia del negocio y de la naturaleza de misión crítica de su sistema.

Otra ruta que nadie hasta ahora ha mencionado es NewSQL, es decir, RDBMS escalables horizontalmente ... Hay algunos como el clúster MySQL (creo) y VoltDB que pueden adaptarse a su causa.

De nuevo se trata de comprender sus datos y los patrones de acceso, los sistemas NoSQL también son no rel, es decir, no relacionales y están ahí para adaptarse mejor a los conjuntos de datos no relacionales. Si sus datos son intrínsecamente relacionales y necesita algunas características de consulta SQL que realmente necesiten hacer cosas como productos cartesianos (alias uniones), entonces es mejor que se quede con Oracle e invierta algún tiempo en la indexación, fragmentación y ajuste del rendimiento.

Mi consejo sería jugar con algunos sistemas diferentes.Sin embargo, para su caso de uso creo que una base de datos de Column Family puede ser la mejor, creo que hay algunos lugares que han implementado soluciones similares a problemas muy similares (creo que NYTimes usa HBase para monitorear los clics de la página de usuario). Otro gran ejemplo es Facebook y me gusta, están usando HBase para esto. Aquí hay un artículo realmente bueno que puede ayudarlo a lo largo de su camino y explicar algunos puntos más arriba. http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html

El punto final sería que los sistemas NoSQL no son el todo y el final. Poner sus datos en una base de datos NoSQL no significa que vaya a funcionar mejor que MySQL, Oracle o incluso archivos de texto ... Por ejemplo, vea esta publicación en el blog: http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html

Me gustaría echarle un vistazo;

MongoDB - Documento - CP

CouchDB - Documento - AP

Redis - En memoria de la llave-valor (familia no columna) - CP

Cassandra - Familia de columnas: disponible & Tolerante a la partición (AP)

HBase - Columna Familia - Consistente & partición Tolerante (CP)

Hadoop/colmena - También echar un vistazo a Hadoop en streaming ...

Hypertable - Otra CF CP DB.

VoltDB - Un producto de aspecto muy bueno, una base de datos relación que se distribuye y se podría trabajar para su caso (puede ser una mudanza más fácil). También parecen proporcionar soporte empresarial que puede ser más adecuado para un entorno de producción (es decir, dar a los usuarios de negocios una sensación de seguridad).

De cualquier forma esa es mi 2c. Jugar con los sistemas es realmente la única forma en que vas a descubrir lo que realmente funciona para tu caso.

Answer 5

La mayoría de las personas probablemente recomendaría MongoDB para un sistema de seguimiento/analítico como este, por buenas razones. Debe leer el capítulo „MongoDB for Real-Time Analytics” del libro "Guía Definitiva de MongoDB". Según el tamaño de sus datos y las necesidades de escalado, puede obtener todo el rendimiento, el almacenamiento sin esquema y las funciones de consulta ad-hoc. Tendrá que decidir por sí mismo si los problemas de durabilidad e imprevisibilidad del sistema son riesgosos para usted o no.

Para un sistema de seguimiento más simple, Redis sería una muy buena opción, que ofrece una gran funcionalidad, velocidad increíble y durabilidad real. Para tener una idea de cómo se implementaría dicho sistema en Redis, consulte this gist. La desventaja es que necesitaría definir todos los "índices" usted mismo, no obtenerlos para "gratis", como es el caso de MongoDB. Sin embargo, no hay almuerzo gratis, y los índices MongoDB definitivamente no son un almuerzo gratis.

creo que usted debe tener una mirada en cómo Elasticsearch le permitiría:

• velocidad de vértigo
• -Esquema de almacenamiento gratuito
• sharding y arquitectura distribuida
• potentes primitivas analíticas en el forma de facets
• Fácil implementación de "ventana deslizante" tipo de almacenamiento de datos con índice ali ases

Es en el corazón un "motor de búsqueda de texto completo", pero no te confundas con eso. Lea el artículo „Data Visualization with ElasticSearch and Protovis“ para el caso de uso del mundo real de ElasticSearch como motor de minería de datos.

Eche un vistazo a these slides para el caso de uso del mundo real para el escenario de "ventana deslizante".

Hay muchas bibliotecas de clientes para ElasticSearch disponibles, como Tire para Ruby, por lo que es fácil despegar rápidamente con un prototipo.

Para el registro (con todo el debido respeto a @jhs :), de acuerdo con mi experiencia, no puedo imaginar una implementación donde Couchdb es una opción viable y útil. Sin embargo, sería un impresionante almacenamiento de respaldo para sus datos.