¿Qué problemas de escalabilidad ha encontrado al usar un almacén de datos NoSQL? [cerrado]

NoSQL se refiere a los almacenes de datos no relacionales que rompen con el historial de bases de datos relacionales y las garantías de ACID. Los almacenes de datos NoSQL de código abierto populares incluyen:

• Cassandra (tabular, escrito en Java, utilizado por Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit y Twitter)
• CouchDB (documento, escrito en Erlang, utilizado por BBC y Engine Yard)
• Dynomite (valor-clave, escrito en Erlang, utilizado por Powerset)
• HBase (clave-valor, escrita en Java, utilizada por Bing)
• Hipertable (tabular, escrito en C ++, utilizado por Baidu)
• Kai (clave-valor, escrito en Erlang)
• MemcacheDB (clave-valor, escrito en C, utilizado por Reddit)
• MongoDB (documento, escrito en C ++, utilizado por Electronic Arts, Github, NY Times y Sourceforge)
• Neo4j (gráfico, escrito en Java, utilizado por algunas universidades suecas)
• Proyecto Voldemort (valor-clave, escrito en Java, utilizado por LinkedIn)
• Redis (valor-clave, escrito en C, utilizado por Craigslist, Engine Yard y Github)
• Riak (valor-clave, escrito en Erlang, utilizado por Comcast y Mochi Media)
• Ringo (valor-clave, escrito en Erlang, usado por Nokia)
• Scalaris (valor-clave, escrito en Erlang, utilizado por OnScale)
• Terrastore (documento, escrito en Java)
• ThruDB (documento, escrito en C ++, utilizado por JunkDepot.com)
• Gabinete de Tokio / Tirano de Tokio (valor-clave, escrito en C, utilizado por Mixi.jp (sitio de red social japonés))

Me gustaría saber sobre problemas específicos que usted, el lector SO, ha resuelto utilizando almacenes de datos y qué almacén de datos NoSQL utilizó.

Preguntas:

• ¿Qué problemas de escalabilidad ha utilizado para almacenar los almacenes de datos NoSQL?
• ¿Qué almacén de datos NoSQL usaste?
• ¿Qué base de datos usó antes de cambiar a un almacén de datos NoSQL?

Estoy buscando experiencias de primera mano, así que no responda a menos que tenga eso.

He cambiado un pequeño subproyecto de MySQL a CouchDB, para poder manejar la carga. El resultado fue asombroso.

Hace aproximadamente 2 años, lanzamos un software auto escrito en http://www.ubuntuusers.de/ (que es probablemente el sitio web más grande de la comunidad alemana de Linux). El sitio está escrito en Python y hemos agregado un middleware WSGI que pudo capturar todas las excepciones y enviarlas a otro pequeño sitio web con MySQL. Este pequeño sitio web utilizó un hash para determinar diferentes errores y almacenó la cantidad de ocurrencias y la última ocurrencia también.

Desafortunadamente, poco después del lanzamiento, el sitio web traceback-logger ya no respondía. Tuvimos algunos problemas de bloqueo con la base de datos de producción de nuestro sitio principal que arrojaba excepciones en casi todas las solicitudes, así como varios otros errores, que no hemos explorado durante la etapa de prueba. El clúster de servidores de nuestro sitio principal, llamado página de envío de seguimiento de registro varias veces por segundo. Y eso fue demasiado para el pequeño servidor que albergaba el registrador de rastreo (ya era un servidor antiguo, que solo se usaba para fines de desarrollo).

En este momento, CouchDB era bastante popular, así que decidí probarlo y escribir un pequeño registrador de rastreo con él. El nuevo registrador solo constaba de un único archivo de Python, que proporcionaba una lista de errores con opciones de clasificación y filtro y una página de envío. Y en el fondo comencé un proceso CouchDB. El nuevo software respondió extremadamente rápido a todas las solicitudes y pudimos ver la gran cantidad de informes automáticos de errores.

Una cosa interesante es que la solución anterior se ejecutaba en un antiguo servidor dedicado, donde el nuevo sitio basado en CouchDB, por otro lado, solo se ejecutaba en una instancia xen compartida con recursos muy limitados. Y ni siquiera he usado la fuerza de las tiendas de valores clave para escalar horizontalmente. La capacidad de CouchDB / Erlang OTP para manejar solicitudes concurrentes sin bloquear nada ya era suficiente para satisfacer las necesidades.

Ahora, el registrador CouchDB-traceback rápidamente escrito todavía se está ejecutando y es una forma útil de explorar errores en el sitio web principal. De todos modos, aproximadamente una vez al mes, la base de datos se vuelve demasiado grande y el proceso CouchDB se anula. Pero entonces, el comando compact-db de CouchDB reduce el tamaño de varios GB a algunos KB nuevamente y la base de datos está funcionando nuevamente (tal vez debería considerar agregar un cronjob allí ... 0o).

En resumen, CouchDB fue seguramente la mejor opción (o al menos una mejor opción que MySQL) para este subproyecto y hace bien su trabajo.

Mi proyecto actual en realidad.

Almacenar 18,000 objetos en una estructura normalizada: 90,000 filas en 8 tablas diferentes. Tomó 1 minuto para recuperarlos y asignarlos a nuestro modelo de objetos Java, eso es con todo correctamente indexado, etc.

Almacenándolos como pares clave / valor utilizando una representación de texto liviana: 1 tabla, 18,000 filas, 3 segundos para recuperarlos todos y reconstruir los objetos Java.

En términos comerciales: la primera opción no era factible. La segunda opción significa que nuestra aplicación funciona.

Detalles tecnológicos: ¡se ejecuta en MySQL para SQL y NoSQL! Seguir con MySQL para un buen soporte de transacciones, rendimiento y un historial probado para no corromper datos, escalar bastante bien, soporte para clustering, etc.

Nuestro modelo de datos en MySQL ahora es solo campos clave (enteros) y el gran campo de "valor": básicamente un gran campo de TEXTO.

No fuimos con ninguno de los nuevos jugadores (CouchDB, Cassandra, MongoDB, etc.) porque aunque cada uno ofrece excelentes características / rendimiento por derecho propio, siempre hubo inconvenientes para nuestras circunstancias (por ejemplo, falta de soporte de Java inmaduro).

Beneficio extra de (ab) uso de MySQL - los bits de nuestro modelo que hacen el trabajo relacional puede ser fácilmente vinculado a nuestros almacenar datos clave / valor.

Actualización: aquí hay un ejemplo de cómo representamos el contenido de texto, no nuestro dominio comercial real (no trabajamos con "productos") como mi jefe me disparó, pero transmite la idea, incluido el aspecto recursivo (una entidad, aquí un producto, "que contiene" otros). Con suerte, está claro cómo, en una estructura normalizada, esto podría ser un buen número de tablas, por ejemplo, unir un producto a su gama de sabores, qué otros productos están contenidos, etc.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Highscalability.com de Todd Hoff tiene una gran cobertura de NoSQL, incluidos algunos estudios de casos.

El DBMS columnar vertical de Vertica puede adaptarse a sus propósitos (aunque admite SQL): es muy rápido en comparación con los DBMS relacionales tradicionales para consultas analíticas. Vea el reciente artículo de CACM de Stonebraker, et al. Que contrasta Vertica con map-reduce.

Actualización: Y Cassandra seleccionó a Twitter sobre varios otros, incluidos HBase, Voldemort, MongoDB, MemcacheDB, Redis e HyperTable.

Actualización 2: Rick Cattell acaba de publicar una comparación de varios sistemas NoSQL en los almacenes de datos de alto rendimiento . Y la versión de highscalability.com sobre el papel de Rick está aquí .

Movimos parte de nuestros datos de mysql a mongodb, no tanto por la escalabilidad sino más porque es una mejor opción para archivos y datos no tabulares.

En producción actualmente almacenamos:

• 25 mil archivos (60 GB)
• 130 millones de otros "documentos" (350 GB)

con una facturación diaria de alrededor de 10 GB.

La base de datos se implementa en una configuración "emparejada" en dos nodos (6x450GB sas raid10) con clientes apache / wsgi / python que utilizan la api mongodb python (pymongo). La configuración del disco es probablemente exagerada, pero eso es lo que usamos para mysql.

Además de algunos problemas con los grupos de subprocesos de pymongo y la naturaleza de bloqueo del servidor mongodb, ha sido una buena experiencia.

Pido disculpas por ir en contra de su texto en negrita, ya que no tengo experiencia de primera mano, pero este conjunto de publicaciones de blog es un buen ejemplo de cómo resolver un problema con CouchDB.

CouchDB: un estudio de caso

Esencialmente, la aplicación textme usó CouchDB para lidiar con su problema de explosión de datos. Descubrieron que SQL era demasiado lento para manejar grandes cantidades de datos de archivo y lo trasladaron a CouchDB. Es una lectura excelente, y analiza todo el proceso de averiguar qué problemas podría resolver CouchDB y cómo terminaron resolviéndolos.

Hemos movido algunos de nuestros datos que solíamos almacenar en Postgresql y Memcached en Redis . Los almacenes de valores clave son mucho más adecuados para almacenar datos de objetos jerárquicos. Puede almacenar datos de blob mucho más rápido y con mucho menos tiempo y esfuerzo de desarrollo que usar un ORM para asignar su blob a un RDBMS.

Tengo un cliente de código abierto C # redis que le permite almacenar y recuperar cualquier objeto POCO con 1 línea:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Los almacenes de valores clave también son mucho más fáciles de 'escalar', ya que puede agregar un nuevo servidor y luego dividir su carga de manera uniforme para incluir el nuevo servidor. Es importante destacar que no hay un servidor central que limite su escalabilidad. (aunque aún necesitará una estrategia para el hash constante para distribuir sus solicitudes).

Considero que Redis es un 'archivo de texto administrado' con esteroides que proporciona acceso rápido, concurrente y atómico para múltiples clientes, por lo que todo lo que solía usar un archivo de texto o una base de datos incrustada ahora uso Redis. Por ejemplo, para obtener un registro de errores continuo combinado en tiempo real para todos nuestros servicios (que ha sido notoriamente una tarea difícil para nosotros), ahora se logra con solo un par de líneas simplemente anteponiendo el error a una lista secundaria del servidor Redis y luego recortar la lista para que solo se mantengan los últimos 1000, por ejemplo:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

No tengo experiencias de primera mano, pero esta entrada del blog me pareció bastante interesante.

Encuentro que el esfuerzo de asignar objetos de dominio de software (por ejemplo, aSalesOrder, aCustomer ...) a una base de datos relacional bidimensional (filas y columnas) requiere mucho código para guardar / actualizar y luego nuevamente para instanciar una instancia de objeto de dominio de múltiples tablas . Sin mencionar el éxito en el rendimiento de tener todas esas uniones, todas esas lecturas de disco ... solo para ver / manipular un objeto de dominio como un pedido de cliente o un registro de cliente.

Hemos cambiado a los sistemas de gestión de bases de datos de objetos (ODBMS). Están más allá de las capacidades de los sistemas noSQL enumerados. GemStone / S (para Smalltalk) es un ejemplo. Existen otras soluciones ODBMS que tienen controladores para muchos idiomas. Un beneficio clave para el desarrollador, su jerarquía de clases es automáticamente su esquema de base de datos, subclases y todo. Simplemente use su lenguaje orientado a objetos para hacer que los objetos sean persistentes en la base de datos. Los sistemas ODBMS proporcionan una integridad de transacción de nivel ACID, por lo que también funcionaría en sistemas financieros.

Cambié de MySQL (InnoDB) a cassandra para un sistema M2M, que básicamente almacena series temporales de sensores para cada dispositivo. Cada dato se indexa por (device_id, date) y (device_id, type_of_sensor, date). La versión de MySQL contenía 20 millones de filas.

MySQL:

• Configuración en sincronización maestro-maestro. Pocos problemas aparecieron en torno a la pérdida de sincronización . Fue estresante y especialmente al principio podría tomar horas arreglarlo.
• El tiempo de inserción no fue un problema, pero las consultas requerían más y más memoria a medida que crecían los datos. El problema es que los índices se consideran como un todo. En mi caso, solo estaba usando partes muy delgadas de los índices que eran necesarias para cargar en la memoria (solo un pequeño porcentaje de los dispositivos fueron monitoreados con frecuencia y estaba en los datos más recientes).
• Fue difícil hacer una copia de seguridad . Rsync no puede hacer copias de seguridad rápidas en grandes archivos de tabla InnoDB.
• Rápidamente se hizo evidente que no era posible actualizar el esquema de tablas pesadas , porque tomó demasiado tiempo (horas).
• Importar datos tomó horas (incluso cuando la indexación se realizó al final). El mejor plan de rescate era mantener siempre algunas copias de la base de datos (archivo de datos + registros).
• Pasar de una compañía de hosting a otra fue realmente un gran problema . La replicación tuvo que ser manejada con mucho cuidado.

Cassandra

• Incluso más fácil de instalar que MySQL.
• Requiere mucha RAM. Una instancia de 2GB no pudo hacerlo funcionar en las primeras versiones, ahora puede funcionar en una instancia de 1GB pero no es una idea (demasiados vaciamientos de datos). Darle 8 GB fue suficiente en nuestro caso.
• Una vez que comprenda cómo organiza sus datos, el almacenamiento es fácil. Solicitar es un poco más complejo. Pero una vez que lo superas, es realmente rápido (no puedes equivocarte a menos que realmente lo desees).
• Si el paso anterior se realizó correctamente, es y se mantiene súper rápido.
• Casi parece que los datos están organizados para ser respaldados. Todos los datos nuevos se agregan como archivos nuevos. Personalmente, pero no es algo bueno, borro los datos todas las noches y antes de cada apagado (generalmente para la actualización) para que la restauración lleve menos tiempo, porque tenemos menos registros para leer. No crea muchos archivos si están compactados.
• Importar datos es rápido como el infierno. Y cuantos más hosts tenga, más rápido. Exportar e importar gigabytes de datos ya no es un problema.
• No tener un esquema es algo muy interesante porque puedes hacer que tus datos evolucionen para seguir tus necesidades. Lo que podría significar tener diferentes versiones de sus datos al mismo tiempo en la misma familia de columnas.
• Agregar un host fue fácil (aunque no rápido), pero no lo hice en una configuración de múltiples centros de datos.

Nota: También he usado Elasticsearch (documento orientado basado en lucene) y creo que debería considerarse como una base de datos NoSQL. Se distribuye, es confiable y a menudo rápido (algunas consultas complejas pueden funcionar bastante mal).

Yo no. Me gustaría usar un almacén de valores clave simple y gratuito al que pueda llamar en el proceso, pero tal cosa no existe afaik en la plataforma Windows. Ahora uso Sqlite pero me gustaría usar algo como Tokyo Cabinet. BerkeleyDB tiene "problemas" de licencia.

Sin embargo, si desea utilizar el sistema operativo Windows, su elección de bases de datos NoSQL es limitada. Y no siempre hay un proveedor de C #

Intenté MongoDB y fue 40 veces más rápido que Sqlite, así que tal vez debería usarlo. Pero todavía espero una solución simple en el proceso.

Usé redis para almacenar mensajes de registro en máquinas. Fue muy fácil de implementar y muy útil. Redis realmente rocas

Reemplazamos una base de datos postgres con una base de datos de documentos CouchDB porque no tener un esquema fijo era una gran ventaja para nosotros. Cada documento tiene un número variable de índices utilizados para acceder a ese documento.

He usado Couchbase en el pasado y encontramos problemas de reequilibrio y muchos otros problemas. Actualmente estoy usando Redis en varios proyectos de producción. Estoy usando redislabs.com, que es un servicio administrado para Redis que se encarga de escalar sus clústeres de Redis. Publiqué un video sobre la persistencia de objetos en mi blog en http://thomasjaeger.wordpress.com que muestra cómo usar Redis en un modelo de proveedor y cómo almacenar sus objetos C # en Redis. Echar un vistazo.

Animaría a cualquiera que lea esto a probar Couchbase una vez más ahora que 3.0 está fuera de la puerta. Hay más de 200 nuevas características para principiantes. El rendimiento, la disponibilidad, la escalabilidad y las funciones de administración fáciles de Couchbase Server lo convierten en una base de datos extremadamente flexible y de alta disponibilidad. La IU de administración está integrada y las API descubren automáticamente los nodos del clúster, por lo que no es necesario un equilibrador de carga de la aplicación a la base de datos. Si bien no tenemos un servicio administrado en este momento, puede ejecutar couchbase en cosas como AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers como CloudSoft y mucho más. En cuanto al reequilibrio, depende de a qué se refiera específicamente, pero Couchbase no se reequilibra automáticamente después de una falla de nodo, como se diseñó, pero un administrador podría configurar la conmutación por error automática para la falla del primer nodo y, al usar nuestras API, también puede obtener acceso a los réplicas de vbuckets para leer antes de activarlos o usar el RestAPI. Este es un caso especial pero se puede hacer.

Tendemos a no reequilibrar en prácticamente ningún modo a menos que el nodo esté completamente fuera de línea y nunca regrese o un nuevo nodo esté listo para equilibrarse automáticamente. Aquí hay un par de guías para ayudar a cualquier persona interesada en ver de qué se trata una de las bases de datos NoSQL de mayor rendimiento.

1. Couchbase Server 3.0
2. Guía de administración
3. API REST
4. Guías para desarrolladores

Por último, también le recomendaría que consulte N1QL para consultas distribuidas:

1. Tutorial N1QL
2. Guía N1QL

¡Gracias por leer y avíseme a mí oa otros si necesita más ayuda!

Austin

He usado Vertica en el pasado. Se basa en la compresión en columna y acelera las lecturas de disco y reduce las necesidades de almacenamiento para aprovechar al máximo su hardware. Las cargas de datos más rápidas y la mayor concurrencia le permiten servir datos analíticos a más usuarios con una latencia mínima.

Anteriormente, estábamos consultando la base de datos de Oracle con miles de millones de registros y el rendimiento fue muy subóptimo. Las consultas tardaron entre 8 y 12 segundos en ejecutarse, incluso después de la optimización con SSD. Por lo tanto, sentimos la necesidad de utilizar una base de datos orientada al análisis, optimizada para una lectura más rápida. Con Vertica Clusters detrás de la capa de servicio optimizado, podríamos ejecutar API con un rendimiento inferior al segundo.

Vertica almacena datos en proyecciones en un formato que optimiza la ejecución de consultas. Al igual que las vistas materializadas, las proyecciones almacenan conjuntos de resultados en el disco O SSD en lugar de calcularlos cada vez que se usan en una consulta. Las proyecciones proporcionan los siguientes beneficios:

1. Comprima y codifique datos para reducir el espacio de almacenamiento.
2. Simplifique la distribución en el clúster de la base de datos.
3. Proporcionar alta disponibilidad y recuperación.

Vertica optimiza la base de datos mediante la distribución de datos a través del clúster utilizando la segmentación.

1. La segmentación coloca una porción de datos en un nodo.
2. Distribuye uniformemente los datos en todos los nodos. Por lo tanto, cada nodo realiza una parte del proceso de consulta.
3. La consulta se ejecuta en el clúster y cada nodo recibe el plan de consulta.
4. Los resultados de las consultas se agregan y se utilizan para crear la salida.

Para obtener más información, consulte la documentación de Vertica @ https://www.vertica.com/knowledgebase/