MongoDB o CouchDB-apto para la producción? [cerrado]

La BBC y meebo.com use CouchDB en producción y también lo hace uno de mis clientes. Aquí hay una lista de otras personas que usan Couch: CouchDB in the wild

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

SourceForge utiliza MongoDB. Ver esta presentación o leer aquí.

Estamos ejecutando CouchDB como un sustituto 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 eran:

1. Fácil replicación desde una base de datos maestra a varios clientes con diferentes documentos.

2. Datos pre-calculados rápidos como "cuántas partes tengo con este atributo y ese filtro, ajustándose a esas condiciones"

Hechos:

1. Nuestras tiendas ahora se ejecutan mucho más rápido que con MySQL (y la base de datos MySQL necesitaba adicionalmente 1-3 días de pre-cálculo (por lo que la actualización era dos veces al mes), haciendo que los datos estén listos para el conteo y filtrado de productos, CouchDB necesita 5 horas, por lo que podríamos actualizar los datos del producto cada noche)
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. Entender map / reduce y los límites de no tener joins es bastante difícil
2. No operación en datos como" delete where "o" update where " sin programas externos
3. La replicación funciona bien, a menos que haya un problema; entonces es realmente difícil averiguar 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 todos los sistemas operativos/versiones) podría ser difícil, si no eres un geek de Linux. Pero la Comunidad CouchDB es útil (#couchdb), y por suerte hay empresas por ahí (cloudant, iriscouch) que ofrece servicios desde gratis hasta 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 mantenimiento de datos es confiable y fácil de entender y manejar. Creo que no vamos a cambiar esto. Pero tampoco quiero perderme la potencia de las vistas CouchDB y la facilidad de configuración de la replicación.

Sofás de producción a veces causó problemas después de meses de trabajo debido a errores de configuración y logrotates olvidados (la construcción de vistas tarda demasiado tiempo o se bloquea, la replicación se detiene), pero nunca se pierden datos y siempre se pueden restablecer fácilmente.

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

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 has hecho en un tiempo.

La versión del código fuente de CouchDB 0.11 está disponible aquí. Hay instaladores binarios y otras cosas vinculadas aquí.

No se nada acerca de MongoDB, pero de la CouchDB FAQ :

¿CouchDB está listo para la producción?

Sí, vea en Thewild para una lista parcial de proyectos usando CouchDB. Otro buen resumen es Estudios de caso de CouchDB

También, algunos enlaces:

• Re: Estado actual de CouchDB?
• SimpleDB, CouchDB y Otros" NUEVOS " Almacenes de datos-Feedback

Usamos couchdb en producción y lo hemos hecho desde justo antes de que el proyecto pasara a estar bajo el paraguas de Apache.

Lo usamos para almacenar todo lo que de otra manera podríamos usar un dbms, además de todo tipo de datos no estructurados. Personalmente, me gusta mucho cómo puedes agregar 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 de dbms. Escribimos nuestros propios utils de migración cuando el formato de almacenamiento cambiado sólo para estar seguro, así que eso no era realmente un problema.

Todavía no hemos tenido ninguna experiencia negativa, pero de nuevo no hemos tenido la configuración bajo ningún tipo de carga enorme. Yo creo que las cosas funcionarían bastante bien ya que tenemos dos servidores de tipo esclavo que se replican desde un solo 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 es cómo lo configuramos al principio y se atascó.

Usamos 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 teníamos ningún problema técnico real, y ha estado funcionando desde finales de diciembre. El único obstáculo que encontré fue inicialmente pensar en términos de MapReduce, pero una vez que aprendí a hacer eso, todo lo demás fue sin problemas.

Actualmente estamos utilizando MongoDB en producción como la capa de almacenamiento en caché, así como el motor de almacenamiento para la importación de productos y la manipulación de datos de productos. Somos una empresa de comercio electrónico que administra más de dos millones de productos (más de 100 millones de atributos), que abarca 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 usando mongodb como su almacén de datos backend. He usado couchdb antes, 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 usando 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 embalaje.

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 consiste en hacer pleno uso de las vistas (o también conocidas como vistas permanentes). Las vistas deben ser "filtro pequeño" de una fracción de la base de datos que se llamará a menudo.

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 700MB.

La característica de CouchDB que me gusta es 'replication', 'store revisions of a document'.

He leído un montón de buenas críticas en MongoDB y voy a querer inténtalo si es posible.

Estamos usando mongodb en producción para

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

El único desafío al que nos enfrentamos en torno al archivo de datos, lo superamos implementando nuestro componente personalizado.

Esta pregunta ya ha aceptado respuesta pero ahora un día más NoSQL DB está en tendencia para muchas de sus grandes características. Es Couchbase; que se ejecuta como CouchbaseLite en la plataforma móvil y Couchbase Server en el lado del servidor.

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

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

Peso ligero significa:

Embedded - la base de datos engine 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 archivos adjuntos multimedia grandes. Buen rendimiento-las cifras exactas dependen de sus datos y aplicación, por supuesto.

Orientado a documentos medios:

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. MapReduce indexing proporciona búsquedas rápidas sin necesidad de utilizar lenguajes de consulta especiales.

Syncable significa:

Cualquier dos copias de una base de datos se pueden sincronizar a través de un eficiente, algoritmo de replicación confiable y probado. La sincronización puede ser bajo demanda o continua (con una latencia de unos segundos). Los dispositivos pueden sincronizarse con un subconjunto de una base de datos grande en un servidor remoto. El motor de sincronización admite conexiones de red intermitentes y poco fiables. 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, incluyendo servidor a servidor (para múltiples centros de datos) y punto a punto, sin pérdida de datos o false conflicto. Couchbase Lite proporciona API nativas para el desarrollo sin problemas de iOS (Objective-C) y Android (Java). Además, incluye el Plug-in Couchbase Lite para PhoneGap, que le permite crear aplicaciones iOS y Android que desarrolla mediante el uso de técnicas de programación de aplicaciones web familiares y el marco de desarrollo móvil de PhoneGap.

Puedes explorar más en Couchbase Lite

Y Servidor Couchbase

Esto va al próximo gran cosa.

Producción oral, conmutación por error/recuperación sin problemas ambos requieren una niñera
1-Couchbase, no hay conmutación por error/recuperación sin problemas, 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 de perder un servidor de configuración, no es una tarea fácil

Adobe está utilizando MongoDB para su próxima versión de Adobe Experience Manager (anteriormente Day CQ) como el motor de base de datos principal.

Varios clientes de la agencia en la que trabajo están usando CouchDB en proyectos para grandes clientes.

Ambos son grandes y viables DBs, en mi opinión. :)

Aquí hay una lista de sitios de producción desplegados con MongoDB

• The New Yorks Times: Usándolo en una aplicación de construcción de formularios para envíos de fotos. La falta de esquema de Mongo da 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 portadas de SourceForge, páginas de proyectos y páginas de descarga para todos proyecto.
• Bit.ly
• Etsy
• IGN : potencia el análisis de tráfico en tiempo real de IGN y las API de contenido RESTful.
• Justin.tv : poderes Justin.tv las herramientas de análisis interno para la viralidad, la retención de usuarios y las estadísticas de uso general que las soluciones listas para usar no pueden proporcionar.
• Posterous
• Intuit
• Foursquare : Las bases de datos de Mongo fragmentadas se utilizan para la mayoría de los datos en foursquare.
• Business Insider : Usándolo 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 utiliza para una aplicación de informes internos.
• Examiner: migraron 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 dia.
• Buzzfeed
• Discus
• Evita: Se utiliza para análisis e informes rápidos.
• Squarespace
• Shutterfly: se utiliza para varios requisitos de almacenamiento de datos persistentes dentro de Shutterfly. MongoDB ayuda a Shutterfly a construir un servicio sin igual que permite relaciones más profundas y personales entre los clientes y aquellos que más importan en sus vida.
• Topsy
• Sharethis
• 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 MongoDB.

Y más...

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

También puede consultar otras bases de datos o herramientas allí.

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