database - oriented - couchdb vs mongodb
MongoDB o CouchDB: ¿aptos para la producción? (19)
Me preguntaba si alguien me puede decir si MongoDB o CouchDB están listos para un entorno de producción .
Ahora estoy viendo estas soluciones de almacenamiento (estoy favoreciendo a MongoDB en este momento), sin embargo, estos proyectos son bastante jóvenes y, por lo tanto, creo que tendré que trabajar muy duro para convencer a mi gerente de que deberíamos adoptar esto. nueva tecnología.
Lo que me gustaría saber es:
¿Quién está utilizando MongoDB o CouchDB hoy en un entorno de producción?
¿Cómo estás usando MongoDB / CouchDB?
¿Qué problemas (si los hay) encontró cuando adoptó este nuevo mecanismo de almacenamiento (y cómo los superó)?
¿Cómo lidiar con los problemas de migración con los que tuvo que lidiar?
¿Tiene alguna experiencia buena / mala con alguna de estas soluciones que le gustaría compartir?
Actualmente estamos utilizando MongoDB en producción como la capa de almacenamiento en caché, así como el motor de almacenamiento para importar 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), con 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 utilizado couchdb anteriormente, pero no en la capacidad de producción.
Aquí hay una lista de sitios de producción desplegados con mongoDB
- The New Yorks Times : usándolo en una aplicación de creación de formularios para enviar fotos. La falta de esquema de Mongo le 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 páginas principales de SourceForge, páginas de proyectos y páginas de descarga para todos los proyectos.
- Bit.ly
- Etsy
- IGN : potencia el análisis 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 viralidad, retención de usuarios y estadísticas de uso general que las soluciones listas para usar no pueden proporcionar.
- Posteroso
- Intuit
- Foursquare : las bases de datos Sharded Mongo 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 interna.
- 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 usuarios únicas por día.
- Buzzfeed
- Disco
- Evite : Se utiliza para análisis e informes rápidos.
- Espacio al cuadrado
- Shutterfly : se utiliza para varios requisitos de almacenamiento de datos persistentes dentro de Shutterfly. MongoDB ayuda a Shutterfly a construir un servicio incomparable que permite relaciones más profundas y personales entre los clientes y las personas más importantes en sus vidas.
- Topsy
- Compartir este
- Mongohq : proporciona una plataforma de alojamiento para MongoDB y también utiliza MongoDB como servicio de fondo 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
Puedes consultar otras bases de datos o herramientas allí también.
CouchDB 0.11 (lanzado a fines de marzo) es una versión congelada 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 desde hace tiempo.
El lanzamiento del código fuente de CouchDB 0.11 está disponible aquí. Hay instaladores binarios y otras cosas enlazadas aquí.
Estamos ejecutando CouchDB como 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 los artículos).
Nuestros objetivos fueron:
Fácil replicación de un master-db a varios clientes con diferentes documentos.
Datos precalculados rápidos como "cuántas partes tengo con este atributo y ese filtro, ajustándose a esas condiciones"
hechos:
- Nuestras tiendas ahora están funcionando mucho más rápido que con MySQL (y la base de datos mysql necesitó de 1 a 3 días de cálculo previo (por lo que la actualización fue dos veces al mes), preparando los datos para el conteo y filtrado del producto, CouchDB necesita 5 horas, por lo que podríamos actualizar los datos del producto cada noche)
- La configuración (filtrada) de la distribución de datos y las copias de seguridad en los nodos de la tienda es rápida y fácil
pero también:
- Comprender el mapa / reducir y los límites de no tener uniones es bastante difícil
- No se realizan operaciones en datos como "eliminar dónde" o "actualizar dónde" sin programas externos
- La replicación funciona bien, a menos que haya un problema; entonces es muy difícil averiguar cuál fue la razón (para principiantes)
- La instalación de CouchDB sin binarios (sí, hay algunos en el mundo salvaje, 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, afortunadamente, hay empresas (cloudant, iriscouch) que ofrecen servicios de libre a gran empresa.
- CouchDB está avanzando, por lo que hay muchos cambios (mejoras) que podrían cambiar su forma de trabajar. Pero las cosas básicas se mantienen 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 vamos a cambiar esto. Pero tampoco quiero perder la potencia de las vistas de CouchDB y la facilidad de configuración de la replicación.
Los sofás de producción a veces causaron problemas después de meses de trabajo debido a una mala configuración y olvidados logrados (la construcción de vistas tarda demasiado o se bloquea, la replicación se detiene), pero nunca se pierden los datos, y siempre se pueden restablecer fácilmente.
Estamos usando mongodb en producción para
www.beachfront.io - cerca de 5k solicitud de escritura por segundo www.beachfrontbuilder.com - 500 solicitudes de lectura / escritura 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 al implementar nuestro componente personalizado.
Estamos utilizando MongoDB en producción en nuestro servicio backend móvil, a saber, Netmera. Lo estamos utilizando para almacenar todos los datos de usuario y contenido.
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.
Es un paso bastante arriesgado, lo admito. En primer lugar, porque todavía no es v1.0. Y en segundo lugar, porque está lleno 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.
Hablando de producción, la recuperación / recuperación de fallos sin problemas requieren una niñera
1- Couchbase, no hay recuperación / recuperación de fallos sin problemas, se requiere intervención manual.
el rebalanceo 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
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 empaquetado.
Ya que estamos vendiendo sensores con una demanda de alta precisión, hacemos muchas pruebas en diferentes etapas y todas 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 "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 otras compañías gigantescas. Pero hasta ahora, todavía estoy bien. Actualmente tengo 24000 documentos a 700MB.
La característica de CouchDB que me gusta es la "replicación", "almacenar revisiones de un documento".
Leí muchas buenas críticas sobre MongoDB y querré intentarlo si hay una oportunidad.
La BBC y meebo.com usan CouchDB en producción y también lo hace 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.
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 ningún sentido que no se nos permitía usar MongoDB en ninguno de nuestros productos.
No sé nada acerca de MongoDB, pero de las preguntas frecuentes de CouchDB :
¿Está listo CouchDB para la producción?
Sí, vea InTheWild para obtener una lista parcial de proyectos usando CouchDB. Otra buena visión general es CouchDB Case Studies
Además, algunos enlaces:
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.
Businessinsider 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 del sitio.
shopwiki lo 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 a 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 utilizando mongo en producción.
Si tiene alguna pregunta sobre la escala o el alcance de las implementaciones de producción, publíquelas en nuestra lista de usuarios y estaremos encantados de ayudarle.
Usamos CouchDB para almacenar mensajes móviles entrantes y salientes e informar sobre este tráfico a través de algunas vistas personalizadas que escribí. El front-end está escrito en Python. No tuvimos problemas técnicos reales, 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í cómo hacerlo, todo lo demás salió bien.
Usamos couchdb en producción y desde entonces, justo antes de que el proyecto quedara 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 simplemente tirar todo tipo de datos y usar las vistas para seleccionar lo que no necesites, dependiendo de la situación.
La parte más difícil fue alejarse de la mentalidad de dbms. Escribimos nuestras propias utilidades de migración cuando el formato de almacenamiento cambió para ser seguro, por lo que no fue realmente un problema.
Aún no hemos tenido experiencias negativas, pero tampoco 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 es así como lo configuramos al principio y se atascó.
Adobe está utilizando MongoDB para su próximo lanzamiento de Adobe Experience Manager (anteriormente Day CQ ) como el motor central de base de datos.
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. :)
SourceForge utiliza MongoDB. Vea esta presentación o lea aquí .
Esta pregunta ya ha aceptado la respuesta, pero hoy en día uno más de NoSQL DB está en tendencia para muchas de sus excelentes características. Es Couchbase
; que se ejecuta como CouchbaseLite
en la plataforma móvil y Couchbase Server
en su servidor.
Estas son algunas de las características principales de Couchbase Lite.
Couchbase Lite es un motor de base de datos sincronizable, ligero y orientado a documentos (NoSQL), adecuado para integrarse en aplicaciones móviles.
Ligero significa:
Integrado: 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 las 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 aplicaciones, por supuesto.
Documento orientado a los medios:
Almacena los 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 usar lenguajes de consulta especiales.
Syncable significa:
Cualquiera de las dos copias de una base de datos se pueden sincronizar a través de un algoritmo de replicación eficiente, confiable y comprobado. 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 no confiables. Los conflictos se pueden detectar y resolver, con la lógica de la aplicación bajo el control total de la fusión. Los árboles de revisión permiten topologías de replicación complejas, que incluyen servidor a servidor (para centros de datos múltiples) y de igual a igual, sin pérdida de datos ni 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, que le permite crear aplicaciones iOS y Android que desarrolle mediante el uso de técnicas de programación de aplicaciones web conocidas y el marco de desarrollo móvil de PhoneGap.
Puedes explorar más en Couchbase Lite
Esto va a la próxima gran cosa.