La clave para tener éxito en las iniciativas de big data es ser capaz de gestionar la velocidad, la escala y la estructura a una velocidad inferior al milisegundo.
Big Data es un gran término. Abarca conceptos sobre tipos de datos, docenas de tecnologías diferentes para gestionar esos tipos de datos y el ecosistema en torno a todas esas tecnologías. ¡Y todo en él se mueve rápido!
Los macrodatos evolucionan rápidamente. Un clásico solución big datala arquitectura tecnológica de big data más común en la actualidad, se basa en la importación y exportación de datos (normalmente a Hadoop) mediante procesos por lotes. Aunque esto ha dado enormes resultados empresariales en forma de una mejor visión del cliente y análisis predictivo, no es una solución en tiempo real. Es lenta.
A medida que la tecnología avanza a un ritmo cada vez mayor, también lo hacen las mejores prácticas para las soluciones de big data: una solución moderna de big data se basa en el procesamiento de datos en tiempo real a través del procesamiento de flujos. Una solución moderna de big data aprovecha la integración con Elasticsearch, Storm y otros. Permite el análisis y la búsqueda en tiempo real al tiempo que cumple los requisitos operativos. Para permitir el análisis y la búsqueda en tiempo real, una solución de big data moderna requiere un alto rendimiento. Base de datos NoSQL que sea escalable. La base de datos NoSQL debe cumplir los requisitos operativos al tiempo que satisface los requisitos de rendimiento necesarios para permitir el análisis y la búsqueda en tiempo real.
Una solución moderna de big data es tan rápida como su componente más lento. Esto nos lleva al reciente anuncio de Mongo y Cloudera. Si bien aplaudimos todos los esfuerzos para ayudar a los clientes a comprender las mejores prácticas para la arquitectura de big data, también debemos abordar qué solución NoSQL es la pieza correcta para permitir una arquitectura de big data verdaderamente rápida. Una base de datos NoSQL escalable y de alto rendimiento garantiza que la base de datos operativa no será el componente más lento. Una base de datos NoSQL que sea difícil de escalar y que imponga bloqueos pesados en su tráfico de lectura y escritura no aprovechará el potencial de una solución moderna de big data. Esta es la diferencia entre MongoDB y Couchbase Server. Claro, MongoDB puede ser parte de soluciones clásicas de big data: éstas no fueron diseñadas para analítica en tiempo real y no necesitan la velocidad que requiere una solución moderna de big data. Couchbase Server puede formar parte tanto de soluciones de big data clásicas como de soluciones de big data modernas.
Una solución clásica de big data, que hemos mencionado antes, se utiliza hoy en día en muchas organizaciones. Normalmente se basa en la integración con Hadoop. Couchbase Server se integra con Hadoop a través de un conector Sqoop certificado por Cloudera (enlace).
Matt Asay citó un caso clásico de uso de big data en el que Hadoop analiza la multitud y una base de datos NoSQL interactúa con los individuos. Las interacciones individuales se envían a Hadoop y el análisis de la multitud se envía a la base de datos NoSQL. Para Couchbase, esto no es sólo un caso de uso. Es una referencia de cliente. AOL aprovecha Hadoop y Couchbase Server en una solución clásica de big data para hacer posible la publicidad inteligente (enlace).
LivePerson aprovecha Hadoop, Storm y Couchbase Server en su moderna solución de big data. La arquitectura de LivePerson aprovecha tanto el procesamiento por lotes como el procesamiento en tiempo real. LivePerson consideró bases de datos NoSQL de Couchbase, MongoDB y DataStax. Sin embargo, sólo Couchbase Server fue capaz de satisfacer sus requisitos de alto rendimiento.
Más información
Big Data Central es un lugar para que la comunidad de big data explore casos de uso, tecnologías y arquitecturas. Descubre cómo clientes de Couchbase como LivePerson, AOL y PayPal están aprovechando NoSQL y Hadoop en soluciones de big data, clásicas y modernas.
Leí este post esperando ver algún tipo de análisis inteligente. En lugar de eso, lo que veo es propaganda e insinuaciones.
Tal vez deberías hablar de índices construidos por trabajos Map Reduce que devuelven datos obsoletos después de las actualizaciones hasta que se ejecuta el trabajo por lotes. ¿O qué tal un motor de almacenamiento de sólo append? ¿De verdad? Las actualizaciones de gran volumen en documentos grandes aplastan a Couchbase.
Si quieres ver un colapso del servidor simplemente empieza a martillear un servidor Couchbase con actualizaciones. Entonces podrás disfrutar del hecho de que todas tus lecturas son ahora inconsistentes con la realidad y el almacenamiento del servidor se calienta lo suficiente como para freír huevos.
Hola Rick,
Gracias por su comentario. Intentaré responder a sus inquietudes.
Deuda técnica:
Se trata de una pieza de alto nivel, pero subraya la importancia de la escalabilidad y el rendimiento. Por eso hemos demostrado nuestra capacidad de escalabilidad y rendimiento con benchmarks. Por cierto, sé que MongoDB sentó las bases para futuras mejoras de rendimiento con su última versión. Tengo grandes expectativas para su próxima versión.
Índices secundarios (vistas) y coherencia:
Por defecto, las vistas son incrementales y, por tanto, consistentes. Sin embargo, los clientes pueden usar la bandera stale (stale=false) para asegurarse de que son consistentes. Creo que MongoDB impone la consistencia de los datos de una manera similar a través de las preocupaciones de escritura. Es eventualmente consistente por defecto (reconocido), pero "majority" es una alternativa.
Archivos de sólo apéndice:
Sí, usamos archivos append-only. Creo que es seguro decir que las bases de datos modernas se están alejando de la actualización in situ. Esto incluye bases de datos de sólo lectura, bases de datos columnares y Google Dremel / Cloudera Impala + Parquet. Estas son algunas de las razones.
Rendimiento constante. Es predecible, mientras que la actualización in situ no lo es.
Resistencia a la corrupción. La capacidad de restaurar a una versión anterior.
Unidades de estado sólido. Son de "lectura-modificación-escritura". No se actualizan in situ.
Fragmentación baja. No es un problema cuando el tamaño de actualización > el tamaño original.
Actualizaciones:
No estoy seguro de por qué crees que las actualizaciones son un problema. Con un archivo append-only, una escritura es una escritura. Te animo a que eches un vistazo a los benchmarks. Si conoces algún benchmark avalado por MongoBD, sería genial que lo compartieras. Me encantaría echarles un vistazo.
Puntos de referencia
http://www.couchbase.com/sites…
MongoDB y los problemas de escritura
http://aphyr.com/posts/284-cal…
Actualizar in situ frente a añadir sólo
http://blogs.justonedatabase.c…
Todas las plataformas NoSQL tienen mucho camino por recorrer. Algunas están más adelantadas que otras y una base de datos es mucho más que rendimiento bruto. Las plataformas relacionales tradicionales son las preferidas para la mayoría de las aplicaciones empresariales, tanto por la profundidad de la funcionalidad que ofrecen como por su rendimiento.
Es en el ámbito de la profundidad funcional donde estamos empezando a ver la separación en el mercado entre plataformas NoSQL a medida que los primeros actores mayoritarios empiezan a hacer sus apuestas.
Estoy seguro de que Couchbase evolucionará como plataforma, al igual que MongoDB. Mi comentario inicial tenía la intención de señalar que el sorteo de la entrada del blog infiere un artículo de opinión muy informado, como mínimo, sin embargo, el contenido se quedó muy corto. Tu comentario de seguimiento estaba probablemente más en línea con lo que esperaba leer en primer lugar, pero los enlaces a antiguas entradas de blog que probablemente no son tan relevantes como lo fueron cuando fueron escritas es una sustitución bastante interesante.