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.

我们有客户，我们的客户有什么我们称之为库存 - 一个或多个。库存可以有数千个项目。目前通过两个关系数据库表， inventoryories 和 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
}

由于我们显然不能使用品牌或 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中品牌为三星的商品中获取最低价格）。


• 我们需要（可能）一次检索数千个项目。


• 我们需要能够从多个应用程序访问数据;


• 需要快速批量插入，但不是必需的。

• We need to be able to select items from only one (or several) inventories.
• We need to be able to filter items based on its parameters (eg. get all items from inventory 2 where type is 'hotel').
• We need to be able to group items based on parameters (eg. get the lowest price from items in inventory 1 where brand is 'Samsung').
• We need to (potentially) be able to retrieve thousands of items at a time.
• We need to be able to access the data from multiple applications; both backend (to process data) and frontend (to display data).
• Rapid bulk insertion is desired, though not required.

基于结构和要求，是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的一个原因是，我们在前端应用程序可以在页面加载后直接从服务器请求数据，并显示结果，而不必使用任何后端代码。这将导致更好的页面加载和更少的服务器压力，因为数据的获取/处理将在客户端执行。

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.

推荐答案

p>我在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.

• 我们需要能够

此查询将是： {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屋！