CouchDB 或 MongoDB 中的哪一个适合我的需求? [英] Which of CouchDB or MongoDB suits my needs?

问题描述

在我工作的地方，我们使用 Ruby on Rails 创建后端和前端应用程序.通常，这些应用程序与同一个 MySQL 数据库交互.它适用于我们的大部分数据，但有一种情况我想迁移到 NoSQL 环境.

Where I work, we use Ruby on Rails to create both backend and frontend applications. Usually, these applications interact with the same MySQL database. It works great for a majority of our data, but we have one situation which I would like to move to a NoSQL environment.

我们有客户，我们的客户也有我们所说的库存"——其中一个或多个.一个库存可以有数千个项目.目前这是通过两个关系数据库表完成的，inventories 和 inventory_items.

We have clients, and our clients have what we call "inventories"--one or more of them. An inventory can have many thousands of items. This is currently done through two relational database tables, inventories and inventory_items.

当两个不同的库存具有不同的参数时，问题就开始了:

The problems start when two different inventories have different parameters:

# 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
}

由于我们显然不能使用 brand 或 star_rating 作为 inventory_items 中的列名，因此到目前为止我们的解决方案是使用泛型列名如text_a、text_b、float_a、int_a等，并引入第三张表inventory_schemas.现在的表格如下所示:

Since we obviously can't use brand or star_rating as the column name in inventory_items, our solution so far has been to use generic column names such as text_a, text_b, float_a, int_a, etc, and introduce a third table, inventory_schemas. The tables now look like this:

# 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
}

这运作良好......在一定程度上.它笨重，不直观，缺乏可扩展性.我们必须投入资源来建立库存模式.不能使用单独的表格.

This has worked well... up to a point. It's clunky, it's unintuitive and it lacks scalability. We have to devote resources to set up inventory schemas. Using separate tables is not an option.

输入 NoSQL.有了它，我们可以让每个项目都有自己的参数，并且仍然将它们存储在一起.从我所做的研究来看，对于这种情况来说，这似乎是一个很好的替代方案.

Enter NoSQL. With it, we could let each and every item have their own parameters and still store them together. From the research I've done, it certainly seems like a great alterative for this situation.

具体来说，我看过 CouchDB 和 MongoDB.两者看起来都很棒.但是，我们还需要对库存进行一些其他处理:

Specifically, I've looked at CouchDB and MongoDB. Both look great. However, there are a few other bits and pieces we need to be able to do with our inventory:

• 我们需要能够从一个(或多个)库存中选择商品.
• 我们需要能够根据其参数过滤商品(例如，从库存 2 中获取类型为酒店"的所有商品).
• 我们需要能够根据参数对商品进行分组(例如，从库存 1 中品牌为三星"的商品中获取最低价格).
• 我们需要(可能)能够一次检索数千个项目.
• 我们需要能够访问来自多个应用程序的数据；后端(处理数据)和前端(显示数据).
• 虽然不是必需的，但需要快速批量插入.

根据结构和需求，CouchDB 或 MongoDB 适合我们吗?如果是这样，哪一个最合适?

Based on the structure, and the requirements, are either CouchDB or MongoDB suitable for us? If so, which one will be the best fit?

感谢阅读，提前感谢您的回答.

Thanks for reading, and thanks in advance for answers.

我喜欢 CouchDB 的原因之一是我们在前端应用程序中可以在页面加载后直接通过 JavaScript 从服务器请求数据，并显示结果而无需使用任何后端代码.这将导致更好的页面加载和更少的服务器压力，因为数据的获取/处理将在客户端完成.

One of the reasons I like CouchDB is that it would be possible for us in the frontend application to request data via JavaScript directly from the server after page load, and display the results without having to use any backend code whatsoever. This would lead to better page load and less server strain, as the fetching/processing of the data would be done client-side.

推荐答案

我在 MongoDB 上工作，所以你应该对它持保留态度，但这看起来非常适合 Mongo.

I work on MongoDB, so you should take this with a grain of salt, but this looks like a great fit for Mongo.

• 我们需要能够从一个(或多个)库存中选择商品.

对任何字段进行临时查询都很容易.

It's easy to ad hoc queries on any fields.

• 我们需要能够根据其参数过滤商品(例如，从库存 2 中获取类型为酒店"的所有商品).

对此的查询将是:{"inventory_id" : 2, "type" : "hotel"}.

• 我们需要能够根据参数对商品进行分组(例如，从库存 1 中品牌为三星"的商品中获取最低价格).

再次，超级简单:db.items.find({"brand" : "Samsung"}).sort({"price" : 1})

• 我们需要(可能)能够一次检索数千个项目.

没问题.

• 虽然不是必需的，但需要快速批量插入.

MongoDB 的批量插入比 CouchDB 快得多.

MongoDB has much faster bulk inserts than CouchDB.

另外，还有一个用于 MongoDB 的 REST 接口:http://github.com/kchodorow/sleepy.mongoose

Also, there's a REST interface for MongoDB: http://github.com/kchodorow/sleepy.mongoose

您可能想阅读 http://chemeo.com/doc/technology，谁处理过MongoDB 的任意属性搜索问题.

You might want to read http://chemeo.com/doc/technology, who dealt with the arbitrary property search problem with MongoDB.

这篇关于CouchDB 或 MongoDB 中的哪一个适合我的需求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！