MongoDB o CouchDB: ¿aptos para la producción? [cerrado]

Me preguntaba si alguien puede decirme si MongoDB o CouchDB están listos para un entorno de producción .

Ahora estoy mirando estas soluciones de almacenamiento (estoy a favor de MongoDB en este momento), sin embargo, estos proyectos son bastante jóvenes y preveo que tendré que trabajar bastante para convencer a mi gerente de que debemos adoptar esto. nueva tecnología.

Lo que me gustaría saber es:

1. ¿Quién usa MongoDB o CouchDB hoy en un entorno de producción?

2. ¿Cómo estás usando MongoDB / CouchDB?

3. ¿Qué problemas (si alguno) encontró cuando adoptó este nuevo mecanismo de almacenamiento (y cómo los superó)?

4. ¿Cómo manejó los problemas de migración que tuvo que enfrentar?

5. ¿Tiene alguna buena / mala experiencia con cualquiera de estas soluciones que le gustaría compartir?

Soy el CTO de 10gen (desarrolladores de MongoDB), así que estoy un poco sesgado, pero también administro algunos sitios que usan MongoDB en producción.

Business Insider ha estado usando Mongo en producción durante más de un año. Lo están utilizando para todo, desde usuarios y publicaciones de blog, hasta cada imagen en el sitio.

shopwiki está utilizando para algunas cosas, incluyendo análisis en tiempo real y una capa de almacenamiento en caché. Están haciendo más de 1000 escrituras por segundo en una base de datos bastante grande.

Si va a la página de Implementaciones de producción de mongodb , verá algunas personas que están usando mongo en la producción.

Si tiene alguna pregunta sobre la escala o el alcance de las implementaciones de producción, publique en nuestra lista de usuarios y estaremos encantados de ayudarlo.

La BBC y meebo.com usan CouchDB en producción y también uno de mis clientes. Aquí hay una lista de otras personas que usan Couch: CouchDB en la naturaleza

El mayor desafío es saber cómo organizar sus documentos y dejar de pensar en términos de datos relacionales.

SourceForge usa MongoDB. Vea esta presentación o lea aquí .

Estamos ejecutando CouchDB como reemplazo de MySQL para nuestras tiendas (70.0000 artículos / tienda, un total de 4 millones de atributos de todos los artículos, conexiones cruzadas entre artículos).

Nuestros objetivos fueron:

1. Fácil replicación de un master-db a varios clientes con diferentes documentos.

2. Datos precalculados rápidos como "cuántas partes tengo con este atributo y ese filtro, que se ajustan a esas condiciones"

hechos:

1. Nuestras tiendas ahora están funcionando mucho más rápido que con MySQL (y la base de datos mysql necesitó adicionalmente 1-3 días de pre-cálculo (por lo que la actualización fue dos veces al mes), preparando los datos para el recuento y filtrado de productos, CouchDB necesita 5 horas, por lo que podríamos actualizar los datos del producto todas las noches)
2. Configurar la distribución de datos (filtrados) y las copias de seguridad en los nodos de la tienda es rápido y fácil

pero también:

1. Comprender el mapa / reducir y los límites de no tener uniones es bastante difícil
2. Ninguna operación en datos como "eliminar dónde" o "actualizar dónde" sin programas externos
3. La replicación funciona bien, a menos que haya un problema; entonces es realmente difícil descubrir cuál fue la razón (para principiantes)
4. La instalación de CouchDB sin binarios (sí, hay algunos en la naturaleza, pero no para cada sistema operativo / versión) podría ser difícil, si no eres un geek de Linux. Pero la Comunidad CouchDB es útil (#couchdb), y afortunadamente hay empresas (cloudant, iriscouch) que ofrecen servicios gratuitos para grandes empresas.
5. CouchDB está avanzando, por lo que hay muchos cambios (mejoras) que podrían cambiar su forma de trabajar. Pero las cosas básicas permanecen estables.

Como resultado: MySQL como base de datos para la creación y el mantenimiento de datos es confiable y fácil de entender y manejar. Creo que no cambiaremos esto. Pero tampoco quiero perderme el poder de las vistas CouchDB y la facilidad de configuración de replicación.

Los sofás de producción a veces causaron problemas después de meses de trabajo debido a una configuración incorrecta y rotaciones olvidadas (la construcción de la vista tarda demasiado o se bloquea, la replicación se detiene), pero nunca perdió datos y siempre se pudo restablecer fácilmente.

Estoy usando CouchDB en producción. Actualmente almacena todos esos campos 'opcionales' que no estaban en el esquema original de la base de datos. Y en este momento estoy pensando en mover todos los datos a CouchDB.

Es un paso bastante arriesgado, lo admito. En primer lugar, porque todavía no es v1.0. Y en segundo lugar, porque está hambriento de espacio en el disco. Según mis cálculos, el archivo CouchDB (con índices) es ~ 30 veces más grande que la base de datos MySQL con las mismas filas. Pero estoy bastante seguro de que funcionará bien.

CouchDB 0.11 (lanzado a finales de marzo) es una versión de congelación de características para 1.0. Esto significa que mantendremos la compatibilidad con la API actual para 1.0, por lo que ahora es un buen momento para echar otro vistazo a CouchDB si no lo ha hecho en un tiempo.

El lanzamiento del código fuente CouchDB 0.11 está disponible aquí. Hay instaladores binarios y otras cosas vinculadas aquí.

No sé nada sobre MongoDB, pero de las preguntas frecuentes de CouchDB :

¿Está CouchDB listo para la producción?

Sí, consulte InTheWild para obtener una lista parcial de proyectos que utilizan CouchDB. Otra buena visión general son los estudios de caso de CouchDB

Además, algunos enlaces:

• Re: Estado actual de CouchDB?
• SimpleDB, CouchDB y otros almacenes de datos "NUEVOS" - Comentarios

Usamos couchdb en producción y lo hemos hecho justo antes del proyecto bajo el paraguas de Apache.

Lo usamos para almacenar todo lo que de otro modo podríamos usar un dbms, además de todo tipo de datos no estructurados. Personalmente, me gusta mucho cómo puedes arrojar todo tipo de datos y usar las vistas para seleccionar lo que no necesitas dependiendo de la situación.

La parte más difícil fue alejarse de la mentalidad dbms. Escribimos nuestras propias utilidades de migración cuando el formato de almacenamiento cambió solo para ser seguro, por lo que no fue realmente un problema.

Todavía no hemos tenido ninguna experiencia negativa, pero nuevamente no hemos tenido la configuración bajo ningún tipo de carga enorme. Creo que las cosas funcionarían bastante bien ya que tenemos dos servidores de tipo esclavo que se replican desde un único servidor maestro que obtiene todas las escrituras. Estoy bastante seguro de que no tenemos que hacerlo de esa manera para que la replicación funcione correctamente, pero así es como lo configuramos al principio y se quedó.

Utilizamos CouchDB para almacenar mensajes entrantes y salientes móviles y para informar sobre este tráfico a través de algunas vistas personalizadas que escribí. El front-end está escrito en Python. No tuvimos ningún problema técnico real, y ha estado funcionando desde finales de diciembre. El único obstáculo que encontré fue pensar inicialmente en términos de MapReduce, pero una vez que aprendí a hacer eso, todo lo demás salió bien.

Actualmente estamos utilizando MongoDB en producción como capa de almacenamiento en caché, así como motor de almacenamiento para importar productos y manipular datos de productos. Somos una empresa de comercio electrónico que gestiona más de dos millones de productos (más de 100 millones de atributos), abarcando más de 10 distribuidores y sin MongoDB, esta tarea sería casi imposible.

Actualmente estamos utilizando mongodb como un servicio de almacenamiento de archivos para nuestra colaboración a través de LAN. Además, proyectos como trello están utilizando mongodb como su almacén de datos de fondo. He usado couchdb anteriormente, pero no en capacidad de producción.

Estamos utilizando MongoDB en producción en nuestro servicio de backend móvil, a saber, Netmera. Lo estamos utilizando para almacenar todos los datos de usuario y contenido.

He estado usando CouchDB en producción durante casi 2 años. No hay trabajo de migración ya que el proyecto comenzó directamente con la implementación de CouchDB. Sirve como una base de datos que almacena los datos de un solo producto electrónico desde el principio hasta el empaque.

Dado que estamos vendiendo sensores con una demanda de alta precisión, hacemos muchas pruebas en diferentes etapas y todas estas se almacenarán en un documento en CouchDB.

Hay una curva de aprendizaje que aprendí de mi experiencia, que es hacer un uso completo de las vistas (o también conocidas como vistas permanentes). Las vistas deben ser un "filtro pequeño" de una fracción de la base de datos que se llamará con frecuencia.

Mi base de datos CouchDB no es tan loca como otra compañía gigantesca. Pero hasta ahora, todavía estoy bien. Actualmente tengo 24000 documentos a 700 MB.

La característica de CouchDB que me gusta es 'replicación', 'almacenar revisiones de un documento'.

Había leído muchas buenas críticas en MongoDB y querré probarlo si hay alguna posibilidad.

Estamos utilizando mongodb en producción para

www.beachfront.io - solicitud de escritura de cerca de 5k por segundo www.beachfrontbuilder.com - solicitud de lectura / escritura de 500 por segundo, mantener 10 millones de datos de usuarios y olap.

El único desafío al que se enfrenta el archivo de datos, lo superamos implementando nuestro componente personalizado.

Esta pregunta ya ha aceptado la respuesta, pero ahora, un día más, NoSQL DB está en tendencia para muchas de sus excelentes características. Es Couchbase; que corre comoCouchbaseLite en la plataforma móvil yCouchbase Server en el lado del servidor.

Estas son algunas de las características principales de Couchbase Lite.

Couchbase Lite es un motor de base de datos sincronizable, ligero, orientado a documentos (NoSQL) adecuado para integrarse en aplicaciones móviles.

Ligero significa:

Incrustado: el motor de la base de datos es una biblioteca vinculada a la aplicación, no un proceso de servidor separado. Tamaño de código pequeño: importante para aplicaciones móviles, que a menudo se descargan a través de redes celulares. Tiempo de inicio rápido: importante porque los dispositivos móviles tienen CPU relativamente lentas. Bajo uso de memoria: los conjuntos de datos móviles típicos son relativamente pequeños, pero algunos documentos pueden tener grandes archivos adjuntos multimedia. Buen rendimiento: las cifras exactas dependen de sus datos y aplicaciones, por supuesto.

Orientado a documentos significa:

Almacena registros en formato JSON flexible en lugar de requerir esquemas predefinidos o normalización. Los documentos pueden tener archivos adjuntos binarios de tamaño arbitrario, como contenido multimedia. El formato de datos de la aplicación puede evolucionar con el tiempo sin necesidad de migraciones explícitas. La indexación de MapReduce proporciona búsquedas rápidas sin necesidad de utilizar lenguajes de consulta especiales.

Sincronizable significa:

Cualquiera de las dos copias de una base de datos puede sincronizarse a través de un algoritmo de replicación eficiente, confiable y probado. La sincronización puede ser a pedido o continua (con una latencia de unos pocos segundos). Los dispositivos pueden sincronizarse con un subconjunto de una gran base de datos en un servidor remoto. El motor de sincronización admite conexiones de red intermitentes y poco confiables. Los conflictos se pueden detectar y resolver, con la lógica de la aplicación en control total de la fusión. Los árboles de revisión permiten topologías de replicación complejas, que incluyen servidor a servidor (para múltiples centros de datos) y de punto a punto, sin pérdida de datos o conflictos falsos. Couchbase Lite proporciona API nativas para el desarrollo continuo de iOS (Objective-C) y Android (Java). Además, incluye el complemento Couchbase Lite para PhoneGap,

Puede explorar más en Couchbase Lite

y servidor Couchbase

Esto va a la próxima gran cosa.

Hablando de producción, la recuperación / recuperación tras error sin interrupciones requiere una niñera
1- Couchbase, no hay recuperación / recuperación tras error sin interrupciones, se requiere intervención manual.
El reequilibrio lleva demasiado tiempo, demasiado riesgo si se pierde más de un nodo.

2- Mongo con fragmentos, la recuperación de datos por la pérdida de un servidor de configuración, no es una tarea fácil

Adobe está utilizando MongoDB para su próximo lanzamiento de Adobe Experience Manager (anteriormente Day CQ ) como el motor de base de datos central.

Varios clientes de la agencia en la que trabajo utilizan CouchDB en proyectos para grandes clientes.

Ambos son excelentes y viables bases de datos, en mi opinión. :)

Aquí hay una lista de sitios implementados de producción con mongoDB

• The New Yorks Times : Utilizándolo en una aplicación de creación de formularios para envíos de fotos. La falta de esquema de Mongo brinda a los productores la capacidad de definir cualquier combinación de campos de formulario personalizados.
• SourceForge : se utiliza para el almacenamiento de back-end en las páginas principales de SourceForge, páginas de proyectos y páginas de descarga para todos los proyectos.
• Bit.ly
• Etsy
• IGN : potencia las analíticas de tráfico en tiempo real de IGN y las API de contenido RESTful.
• Justin.tv : potencia las herramientas de análisis interno de Justin.tv para la viralidad, la retención de usuarios y las estadísticas generales de uso que las soluciones listas para usar no pueden proporcionar.
• Posterous
• Intuit
• Foursquare : las bases de datos Sharded Mongo se utilizan para la mayoría de los datos en foursquare.
• Business Insider : su uso desde principios de 2008. Todos los datos del sitio, incluidas las publicaciones, los comentarios e incluso las imágenes, se almacenan en MongoDB.
• Github : se usa para una aplicación de informes internos.
• Examinador : migró su sitio de Cold Fusion y SQL Server a Drupal 7 y MongoDB.
• Grooveshark : actualmente usa Mongo para administrar más de un millón de sesiones de usuario únicas por día.
• Buzzfeed
• Disco
• Evite : Utilizado para análisis e informes rápidos.
• Espacio cuadrado
• Shutterfly : se utiliza para varios requisitos de almacenamiento de datos persistentes dentro de Shutterfly. MongoDB ayuda a Shutterfly a construir un servicio inigualable que permite relaciones más profundas y personales entre los clientes y aquellos que más importan en sus vidas.
• Topsy
• Compartir este
• Mongohq : proporciona una plataforma de alojamiento para MongoDB y también utiliza MongoDB como back-end para su servicio. Nuestra página de centros de alojamiento proporciona más información sobre MongoHQ y otras opciones de alojamiento de MongoDB.

y más...

Extraído de: http://lineofthought.com/tools/mongodb

Puede consultar otras bases de datos o herramientas allí también.

MongoDB tiene algunos problemas con la concesión de licencias a empresas, no estoy seguro de los detalles, pero nuestro departamento legal no nos dijo en términos determinados que no se nos permitía usar MongoDB en ninguno de nuestros productos.