database - exito - ¿Qué problemas de escalabilidad encontró con un almacén de datos NoSQL?

nosql ejemplos (14)

Animo a todos los que lean esto a que prueben Couchbase una vez más ahora que 3.0 está fuera de la pantalla. Hay más de 200 nuevas características para principiantes. Las características de rendimiento, disponibilidad, escalabilidad y administración sencilla de Couchbase Server lo convierten en una base de datos extremadamente flexible y altamente disponible. La UI de administración está incorporada y las API descubren automáticamente los nodos del clúster, por lo que no es necesario un equilibrador de carga desde la aplicación al DB. 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 refiere específicamente, pero Couchbase no se reequilibra automáticamente después de una falla de nodo, tal como está diseñado, pero un administrador puede configurar la failover automática para la falla del primer nodo y al usar nuestras API también puede obtener acceso al réplica de vbuckets para leer antes de activarlos o utilizar RestAPI, puede aplicar una conmutación por error mediante una herramienta de supervisión. Este es un caso especial, pero es posible hacerlo.

Tendemos a no reequilibrar en casi cualquier modo a menos que el nodo esté completamente desconectado 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.

Por último, también le recomiendo que consulte N1QL para consultas distribuidas:

¡Gracias por leer y dejarnos a mí u otros saber si necesita más ayuda!

Austin

NoSQL se refiere a los almacenes de datos no relacionales que rompen con el historial de las bases de datos relacionales y las garantías de ACID. Los populares almacenes de datos NoSQL de código abierto 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 (clave-valor, escrito en Erlang, utilizado por Powerset)
HBase (clave-valor, escrito en Java, utilizado por Bing)
Hypertable (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 (clave-valor, escrito en Java, utilizado por LinkedIn)
Redis (clave-valor, escrito en C, utilizado por Craigslist, Engine Yard y Github)
Riak (clave-valor, escrito en Erlang, utilizado por Comcast y Mochi Media)
Ringo (clave-valor, escrito en Erlang, usado por Nokia)
Scalaris (clave-valor, escrito en Erlang, utilizado por OnScale)
Terrastore (documento, escrito en Java)
ThruDB (documento, escrito en C ++, utilizado por JunkDepot.com)
Tokyo Cabinet / Tokyo Tyrant (clave-valor, escrito en C, utilizado por Mixi.jp (sitio de redes sociales japonés))

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

Preguntas:

¿Qué problemas de escalabilidad ha usado para almacenar los almacenes de datos NoSQL?
¿Qué almacén de datos NoSQL usaste?
¿Qué base de datos usó antes de cambiar a una tienda de datos NoSQL?

Estoy buscando experiencias de primera mano, así que no respondas a menos que tengas eso.

Cambié de MySQL (InnoDB) a cassandra por un sistema M2M, que básicamente almacena series temporales de sensores para cada dispositivo. Cada dato está indexado 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 la 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 era 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 una parte muy delgada de los índices que era necesario cargar en la memoria (solo un pequeño porcentaje de los dispositivos se monitoreaba 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 quedó claro que no era posible actualizar el esquema de tablas pesadas , ya que tomaba demasiado tiempo (horas).
La importación de datos tomó horas (incluso cuando la indexación se realizó al final). El mejor plan de rescate era mantener siempre unas pocas copias de la base de datos (archivo de datos + registros).
Pasar de una empresa de hosting a otra fue realmente un gran problema . La replicación debe manejarse con mucho cuidado.

Cassandra:

Aún más fácil de instalar que MySQL.
Requiere mucha RAM Una instancia de 2 GB no podría hacer que se ejecutara en las primeras versiones, ahora puede funcionar en una instancia de 1GB pero no es idea (demasiadas descargas de datos). Darle 8 GB fue suficiente en nuestro caso.
Una vez que comprenda cómo organiza sus datos, almacenarlos es fácil. Solicitar es un poco más complejo. Pero una vez que lo haces, es realmente rápido (no puedes equivocarte a menos que realmente quieras).
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. Cada nuevo dato se agrega como nuevos archivos. Personalmente, pero no es algo bueno, limpie los datos todas las noches y antes de cada cierre (por lo general, para la actualización), de modo que la restauración lleva 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 tengas, más rápido. La exportación e importación de gigabytes de datos ya no es un problema.
No tener un esquema es algo muy interesante porque puede hacer que sus datos evolucionen para satisfacer sus 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 centro de datos múltiple.

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 tener un rendimiento bastante malo).

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

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

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

En este momento CouchDB era bastante popular, así que decidí probarlo y escribir un pequeño registrador de seguimiento con él. El nuevo registrador solo consistía en un único archivo python, que proporcionaba una lista de errores con las 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ó muy rápidamente a todas las solicitudes y pudimos ver la cantidad masiva de informes de errores automáticos.

Una cosa interesante es que la solución anterior se ejecutaba en un antiguo servidor dedicado, donde el nuevo sitio basado en CouchDB solo se ejecutaba en una instancia xen compartida con recursos muy limitados. Y ni siquiera he usado la fortaleza 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 aún 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 de CouchDB es asesinado. Pero entonces, el comando compact-db de CouchDB reduce el tamaño de varios GB a algunos KBs nuevamente y la base de datos está funcionando nuevamente (tal vez debería considerar agregar un cronjob allí ... 0o).

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

Hemos trasladado algunos de nuestros datos que solíamos almacenar en Postgresql y Memcached en Redis . Las tiendas de valores clave son mucho más adecuadas para almacenar datos de objetos jerárquicos. Puede almacenar datos de blobs 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 c. Redis de código abierto 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" });

Las tiendas 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 existe un servidor central que limitará su escalabilidad. (aunque aún necesitará una estrategia de hash consistente para distribuir sus solicitudes).

Considero que Redis es un "archivo de texto administrado" con esteroides que proporciona un acceso rápido, concurrente y atómico para múltiples clientes, así que todo lo que utilicé para usar un archivo de texto o una base de datos integrada ahora uso Redis. Por ejemplo, para obtener un registro de errores de rodadura combinado en tiempo real para todos nuestros servicios (lo que ha sido una tarea difícil para nosotros), ahora se logra con solo un par de líneas simplemente antes de que se produzca el error en una lista del lado del servidor de Redis y luego recorte la lista para que solo se guarden 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);

Me disculpo por ir en contra de su texto en negrita, ya que no tengo ninguna 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

Básicamente, la aplicación de texto usó CouchDB para lidiar con su problema de explosión de datos. Descubrieron que SQL era demasiado lento para tratar con grandes cantidades de datos de archivo y lo movieron a CouchDB. Es una excelente lectura, y él analiza todo el proceso de descifrar qué problemas podría resolver CouchDB y cómo terminaron resolviéndolos.

Me parece que el esfuerzo de mapear objetos de dominio de software (p. Ej., ASalesOrder, aCustomer ...) a una base de datos relacional bidimensional (filas y columnas) requiere una gran cantidad de código para guardar / actualizar y luego instanciar una instancia de objeto de dominio a partir de varias tablas . Sin mencionar el impacto 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.

Cambiamos a sistemas de gestión de bases de datos de objetos (ODBMS). Están más allá de las capacidades de los sistemas noSQL enumerados. El GemStone / S (para Smalltalk) es un ejemplo. Hay otras soluciones ODBMS que tienen controladores para muchos idiomas. Un beneficio clave para el desarrollador, su jerarquía de clase 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 integridad de transacción a nivel ACID, por lo que también funcionaría en los sistemas financieros.

Mi proyecto actual en realidad.

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

Guárdelos como pares clave / valor usando una representación de texto liviano: 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 de la tecnología: ¡ejecutarse en MySQL para SQL y NoSQL! Seguir con MySQL para un buen soporte de transacciones, rendimiento y un historial comprobado 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 características / rendimiento excelentes por sí mismos, siempre hubo inconvenientes para nuestras circunstancias (por ejemplo, compatibilidad con Java faltante o inmaduro).

Beneficio adicional de (ab) el uso de MySQL: los bits de nuestro modelo que sí funcionan de manera relacional se pueden vincular fácilmente a los datos de nuestra tienda 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") ya que mi jefe me pegaría un tiro, pero transmite la idea, incluido el aspecto recursivo (una entidad, aquí un producto, que "contiene" a otros). Es de esperar que 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} ]

No tengo experiencias de primera mano, pero encontré this entrada en el blog bastante interesante.

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 una cantidad variable de índices utilizados para acceder a ese documento.

Todd Hoff''s highscalability.com tiene una gran cobertura de NoSQL, incluidos algunos estudios de casos.

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

Actualización: Y la Casandra seleccionada de Twitter sobre varias otras, incluyendo HBase, Voldemort, MongoDB, MemcacheDB, Redis e HyperTable.

Actualización 2: Rick Cattell acaba de publicar una comparación de varios sistemas NoSQL en tiendas de datos de alto rendimiento . Y la visión de highscalability.com del artículo de Rick está here .

Trasladamos parte de nuestros datos de mysql a mongodb, no tanto por la escalabilidad, sino porque se ajusta mejor a 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 utilizando mongodb python api (pymongo). La configuración del disco probablemente sea 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 de mongodb, ha sido una buena experiencia.

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

Utilicé Couchbase en el pasado y encontramos problemas de reequilibrio y 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 ocupa de escalar sus clústeres de Redis. Publiqué un video sobre 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 tus objetos C # en Redis. Echar un vistazo.

Yo no. Me gustaría utilizar un almacén de valores-clave simple y gratuito al que pueda llamar en proceso, pero tal cosa no existe en la plataforma de 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 #

Probé 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.