Pregunta

Me preguntaba si alguien puede decirme si MongoDB o sofádb están listos para un producción ambiente.

Ahora estoy analizando estas soluciones de almacenamiento (prefiero MongoDB en este momento), sin embargo, estos proyectos son bastante jóvenes y, por lo tanto, preveo que tendré que trabajar bastante duro para convencer a mi gerente de que deberíamos adoptar esto. nueva tecnología.

Lo que me gustaría saber es:

  1. ¿Quién utiliza MongoDB o CouchDB hoy en día en un entorno de producción?

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

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

  4. ¿Cómo abordó los problemas migratorios que tuvo que afrontar?

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

¿Fue útil?

Solución

Soy el director de tecnología de 10gen (desarrolladores de MongoDB) así que estoy un poco sesgada, sino también administro algunos sitios que están usando MongoDB en la producción.

businessinsider ha estado utilizando mongo en la producción de más de un año. Lo están usando para todo, desde los usuarios y blogs, a cada imagen en el sitio.

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

Si vas a la página de los despliegues de producción mongodb verás algunas personas que están usando mongo en la producción.

Si usted tiene alguna pregunta sobre la escala y el alcance de los despliegues de producción, publicar en nuestra lista de usuarios y estaremos más que encantados de ayudarle.

Otros consejos

El BBC y meebo.com usar CouchDB en la producción y lo mismo ocurre con uno de mis clientes. Aquí está una lista de otras personas usando Sofá: CouchDB en el salvaje

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

SourceForge utiliza MongoDB. Ver este presentación o leer 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 artículos).

Nuestros objetivos eran:

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

  2. Datos rápidos precalculados como "cuántas piezas tengo con este atributo y ese filtro, ajustándose a esas condiciones"

hechos:

  1. Nuestras tiendas ahora funcionan mucho más rápido que con MySQL (y la base de datos mysql necesitaba entre 1 y 3 días adicionales de cálculo previo (por lo que la actualización se realizaba dos veces al mes), lo que deja los datos listos para el conteo 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 map/reduce y los límites de no tener uniones es bastante difícil
  2. No se realizan operaciones con 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 muy difícil descubrir cuál fue el motivo (para principiantes)
  4. La instalación de CouchDB sin binarios (sí, hay algunos disponibles, pero no para todos los sistemas operativos/versiones) podría ser difícil, si no eres un experto en Linux.Pero la comunidad CouchDB es útil (#couchdb) y, afortunadamente, existen empresas (cloudant, iriscouch) que ofrecen servicios desde gratuitos hasta grandes empresas.
  5. CouchDB está avanzando, por lo que se están realizando 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 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 de CouchDB y la facilidad de configuración de la replicación.

Los sofás de producción a veces causaban problemas después de meses de trabajo debido a una mala configuración y logrotates olvidados (la creación de vistas tarda demasiado o se bloquea, la replicación se detiene), pero nunca se perdían datos y siempre se podían restablecer fácilmente.

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

Es un paso bastante arriesgado, lo reconozco. En primer lugar, porque no es v1.0 todavía. Y en segundo lugar, porque se trata de DriveSpace de hambre. Según mis cálculos, 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 todo saldrá bien.

CouchDB 0,11 (liberado al final de marzo) es una liberación característica de congelación para 1.0. Esto significa que vamos a mantener la compatibilidad con la API actual de 1,0, por lo que ahora es un buen momento para echar otro vistazo a CouchDB si no es así desde hace tiempo.

El liberación de código CouchDB 0,11 fuente está disponible aquí. Hay instaladores binarios y otras golosinas vinculados aquí

No sé nada acerca de MongoDB, pero desde el CouchDB FAQ :

  

¿Es CouchDB listo para la producción?

     

Sí, consulte InTheWild para una lista parcial de proyectos usando CouchDB. Otra buena visión general es CouchDB Casos de estudio

Además, algunos enlaces:

couchdb utilizar en la producción y desde entonces justo antes del proyecto fue bajo el paraguas de Apache.

Lo utilizamos para almacenar todo lo que de otro modo podríamos utilizar un DBMS, además de todo tipo de datos no estructurados. En lo personal, me gusta mucho la forma en que sólo se puede tirar todo tipo de datos en él y utilizar los puntos de vista de sacrificar lo que no es necesario dependiendo de la situación.

La parte más difícil fue alejando de la mentalidad DBMS. Escribimos nuestras propias utilidades de migración cuando el formato de almacenamiento cambió sólo para estar seguro, así que no era realmente un problema.

No hemos tenido ninguna experiencia negativa, sin embargo, pero por otra parte no hemos tenido la disposición en virtud de cualquier tipo de carga enorme. I pensar 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 la forma en que configurarlo en el principio y se quedó.

Utilizamos CouchDB para almacenar mensajes entrantes y salientes móviles e informar sobre este tráfico a través de algunas vistas personalizadas que he escrito. 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é estaba pensando inicialmente en términos de MapReduce, pero una vez que aprendí a hacer eso, todo fue sin problemas.

Actualmente estamos utilizando MongoDB en la producción como la capa de almacenamiento en caché, así como motor de almacenamiento para el producto de importación y manipulación de datos del producto. Somos una empresa de comercio electrónico de gestión de más de dos millones de productos de más de 100 millones de dólares (atributos), que abarca 10 + distribuidores y sin MongoDB, esta tarea se acerca a imposible.

Actualmente estamos utilizando mongodb como un servicio de almacenamiento de archivos de nuestra colaboración a través de LAN. Además, proyectos como Trello están utilizando mongodb como su almacén de datos back-end. He utilizado couchdb antes, pero no en la capacidad de producción.

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

He estado usando CouchDB en producción durante casi 2 años. No hay trabajo migración como se inició el proyecto de aplicación directamente con CouchDB. Sirve como una base de datos que almacena los datos de un único producto electrónico desde el principio hasta el embalaje.

Dado que estamos vendiendo sensor con una demanda de alta precisión, que hacer un montón de pruebas en una fase diferente y todos estos se almacenarán en un solo documento en CouchDB.

Hay un poco de curva de aprendizaje que he aprendido de mi experiencia, que es hacer un uso completo de los puntos de vista (o también conocido como vistas permanentes). Vistas deben ser "filtro" de una fracción de la base de datos que será llamado a menudo.

Mi DATABSE CouchDB no es tan loco como otra empresa gigantesca. Pero hasta ahora, todavía estoy haciendo bien. Actualmente estoy teniendo 24000 documentos en 700MB.

Función de CouchDB que me gusta es 'la replicación', 'tienda de las revisiones de un documento.

Me había leído un montón de buenas críticas en MongoDB y yo desee probar si hay una posibilidad.

Estamos utilizando mongodb en la producción para

www.beachfront.io - cerca de 5K solicitud de escritura por segundo www.beachfrontbuilder.com -. 500 de petición de lectura / escritura por segundo, mantener a los usuarios de datos y OLAP 10m

El único desafío que enfrentan alrededor de archivo de los datos, podemos superar mediante la implementación de nuestro componente personalizado.

Esta pregunta ya ha aceptado respuesta, pero hoy en día una más NoSQL DB es en la tendencia de muchos 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.

Aquí es algunas de las características principales de Couchbase Lite.

Couchbase Lite es un motor ligero, (NoSQL), orientada a documentos syncable base de datos adecuada para integrarse en aplicaciones para móviles.

medios ligeros:

-Embedded motor de base de datos es una biblioteca vinculada en la aplicación, no es un proceso de servidor independiente. Tamaño pequeño-importante para aplicaciones móviles, que a menudo se descargan a través de redes celulares de código. tiempo importante arranque rápido ya que los dispositivos móviles tienen CPUs relativamente lentos. Bajo memoria conjuntos de datos móviles de uso típico son relativamente pequeñas, pero algunos documentos podrían tener grandes archivos multimedia adjuntos. Las buenas cifras de rendimiento-exacta depende de los datos y las aplicaciones, por supuesto.

orientados a documentos de medio:

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

sincronizables significa:

Cualquiera de las dos copias de una base de datos pueden ser llevados a la sincronización mediante un algoritmo eficiente, fiable y probada replicación. Sincronización puede ser bajo demanda o continua (con una latencia de unos pocos segundos). Los dispositivos se pueden sincronizar con un subconjunto de una gran base de datos en un servidor remoto. El motor de sincronización es compatible con conexiones de red intermitentes y poco fiables. Los conflictos pueden ser detectados y resueltos, con la lógica de la aplicación en el control total de la fusión. árboles de revisiones permiten topologías de replicación complejos, incluidos los de servidor a servidor (por múltiples centros de datos) y peer-to-peer, sin pérdida de datos o conflictos falsos. Couchbase Lite proporciona APIs nativas para iOS sin costura (Objective-C) y Android de desarrollo (Java). Además, incluye el Couchbase Lite Plug-in para PhoneGap, que le permite construir iOS y Android que desarrolle utilizando técnicas de programación de aplicaciones web familiares y el marco de desarrollo móvil PhoneGap.

Usted puede explorar más en Couchbase Lite

Couchbase servidor

Esto va a la próxima gran cosa.

Al hablar de producción, sin problemas de conmutación por error / recuperación ambas requieren una niñera
1- Couchbase, no hay fisuras de conmutación por error / recuperación, se requiere intervención manual.
reequilibrio lleva demasiado tiempo, demasiado riesgo si hay más de un nodo se pierda.

2- Mongo con fragmentos, recuperación de datos de perder 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 Día CQ ) como el núcleo del motor DB.

Varios clientes de la agencia Trabajo en están utilizando CouchDB en proyectos para grandes clientes.

Los dos son grandes y viable DBs, en mi opinión. :)

He aquí una lista de los centros de producción desplegado con MongoDB

  • The New Yorks tiempos : Su uso en una aplicación de creación de formulario para la presentación de fotos. falta de esquemas de Mongo da a los productores la posibilidad de definir cualquier combinación de campos de formulario personalizado.
  • SourceForge . Se utiliza para el almacenamiento de fondo en las páginas frontales de SourceForge, páginas del proyecto, y las páginas de descargas de todos los proyectos
  • Bit.ly
  • Etsy
  • IGN . Poderes de IGN análisis en tiempo real del tráfico y las API REST contenido
  • Justin.tv . Poderes herramientas de análisis internos de Justin.tv para viralidad, la retención de usuarios, y las estadísticas de uso generales que fuera-de-la-caja de soluciones no pueden proporcionar
  • Posterous
  • Intuit
  • Foursquare :. Bases de datos fragmentados 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, incluyendo mensajes, comentarios, e incluso las imágenes, se almacenan en MongoDB
  • Github :. Se utiliza para una aplicación de informes internos
  • Examinador . Migrado su sitio de la fusión fría y SQL Server para Drupal 7 y MongoDB
  • Grooveshark . Actualmente utiliza Mongo para gestionar más de un millón de sesiones de usuarios únicos por día
  • Buzzfeed
  • Disco
  • Evite . Se utiliza para el análisis y la presentación de informes rápida
  • Squarespace
  • Shutterfly : se utiliza para diversos requisitos de almacenamiento de datos persistentes dentro de Shutterfly. MongoDB ayuda a Shutterfly construir un servicio incomparable que permite relaciones más profundas personales entre los clientes y los que son lo más importante en sus vidas.
  • Topsy
  • sharethis
  • Mongohq : proporciona una plataforma de alojamiento para MongoDB y también utiliza MongoDB como el back-end para su servicio. Nuestra página centros de alojamiento proporciona más información acerca de MongoHQ y otras opciones de alojamiento 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 las empresas, que no estoy seguro de los detalles, pero nuestro departamento legal nos dijeron que en ciertos términos que no se nos permitió utilizar MongoDB en cualquiera de nuestros productos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top