mongodb couchdb database nosql

¿Cuál de CouchDB o MongoDB satisface mis necesidades?



database nosql (1)

Yo trabajo en MongoDB, así que debes tomar esto con un grano de sal, pero esto parece ser un gran ajuste para Mongo.

  • Necesitamos poder seleccionar artículos de solo uno (o varios) inventarios.

Es fácil realizar consultas ad hoc en cualquier campo.

  • Necesitamos poder filtrar artículos según sus parámetros (por ejemplo, obtener todos los artículos del inventario 2 donde el tipo es ''hotel'').

La consulta para esto sería: {"inventory_id" : 2, "type" : "hotel"} .

  • Necesitamos poder agrupar artículos según los parámetros (por ejemplo, obtener el precio más bajo de los artículos en el inventario 1 donde la marca es ''Samsung'').

De nuevo, super fácil: db.items.find({"brand" : "Samsung"}).sort({"price" : 1})

  • Necesitamos (potencialmente) poder recuperar miles de artículos a la vez.

No hay problema.

  • Se desea una inserción masiva rápida, aunque no se requiere.

MongoDB tiene inserciones masivas mucho más rápidas que CouchDB.

Además, hay una interfaz REST para MongoDB: http://github.com/kchodorow/sleepy.mongoose

Es posible que desee leer http://chemeo.com/doc/technology , que se ocupó del problema de búsqueda de propiedad arbitraria con MongoDB.

Donde trabajo, usamos Ruby on Rails para crear aplicaciones de backend y frontend. Normalmente, estas aplicaciones interactúan con la misma base de datos MySQL. Funciona muy bien para la mayoría de nuestros datos, pero tenemos una situación que me gustaría pasar a un entorno NoSQL.

Tenemos clientes, y nuestros clientes tienen lo que llamamos "inventarios", uno o más de ellos. Un inventario puede tener muchos miles de artículos. Esto se hace actualmente a través de dos tablas de bases de datos relacionales, inventories e inventory_items .

Los problemas comienzan cuando dos inventarios diferentes tienen parámetros diferentes:

# Inventory item from inventory 1, televisions { inventory_id: 1 sku: 12345 name: Samsung LCD 40 inches model: 582903-4 brand: Samsung screen_size: 40 type: LCD price: 999.95 } # Inventory item from inventory 2, accomodation { inventory_id: 2 sku: 48cab23fa name: New York Hilton accomodation_type: hotel star_rating: 5 price_per_night: 395 }

Como es obvio que no podemos usar brand o star_rating como nombre de columna en inventory_items , nuestra solución hasta ahora ha sido utilizar nombres de columna genéricos como text_a , text_b , float_a , int_a , etc. e introducir una tercera tabla, inventory_schemas . Las tablas ahora se ven así:

# Inventory schema for inventory 1, televisions { inventory_id: 1 int_a: sku text_a: name text_b: model text_c: brand int_b: screen_size text_d: type float_a: price } # Inventory item from inventory 1, televisions { inventory_id: 1 int_a: 12345 text_a: Samsung LCD 40 inches text_b: 582903-4 text_c: Samsung int_a: 40 text_d: LCD float_a: 999.95 }

Esto ha funcionado bien ... hasta cierto punto. Es torpe, no es intuitivo y carece de escalabilidad. Tenemos que dedicar recursos para configurar esquemas de inventario. Usar tablas separadas no es una opción.

Ingrese NoSQL. Con él, podríamos permitir que cada elemento tenga sus propios parámetros y aún así almacenarlos juntos. De la investigación que he hecho, ciertamente parece ser una gran alternativa para esta situación.

Específicamente, he mirado CouchDB y MongoDB. Ambos se ven muy bien. Sin embargo, hay algunas otras partes que necesitamos para hacer con nuestro inventario:

  • Necesitamos poder seleccionar artículos de solo uno (o varios) inventarios.
  • Necesitamos poder filtrar artículos según sus parámetros (por ejemplo, obtener todos los artículos del inventario 2 donde el tipo es ''hotel'').
  • Necesitamos poder agrupar artículos según los parámetros (por ejemplo, obtener el precio más bajo de los artículos en el inventario 1 donde la marca es ''Samsung'').
  • Necesitamos (potencialmente) poder recuperar miles de artículos a la vez.
  • Necesitamos poder acceder a los datos desde múltiples aplicaciones; tanto backend (para procesar datos) como frontend (para mostrar datos).
  • Se desea una inserción masiva rápida, aunque no se requiere.

Según la estructura y los requisitos, ¿son adecuados para nosotros CouchDB o MongoDB? Si es así, ¿cuál será la mejor opción?

Gracias por leer, y gracias de antemano por las respuestas.

EDITAR: una de las razones por las que me gusta CouchDB es que nos sería posible que nosotros en la aplicación de frontend solicitemos datos a través de JavaScript directamente desde el servidor después de la carga de la página, y mostremos los resultados sin tener que usar ningún código de backend. Esto llevaría a una mejor carga de la página y una menor tensión en el servidor, ya que la obtención / procesamiento de los datos se haría del lado del cliente.