Там, где я работаю, мы используем Ruby on Rails для создания как внутренних, так и внешних приложений. Обычно эти приложения взаимодействуют с одной и той же базой данных MySQL. Он отлично работает для большинства наших данных, но у нас есть одна ситуация, которую я хотел бы перенести в среду NoSQL.

У нас есть клиенты, и у наших клиентов есть то, что мы называем «запасами» - один или несколько из них. В инвентаре может быть много тысяч предметов. В настоящее время это делается с помощью двух таблиц реляционной базы данных,inventories а такжеinventory_items.

Проблемы начинаются, когда два разных инвентаря имеют разные параметры:

# 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, Таблицы теперь выглядят так:

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

Это сработало хорошо ... до определенного момента. Это неуклюже, это не интуитивно понятно, и ему не хватает масштабируемости. Мы должны выделить ресурсы для настройки схем инвентаризации. Использование отдельных таблиц не вариант.

Введите NoSQL. С его помощью мы можем позволить каждому элементу иметь свои собственные параметры и при этом сохранять их вместе. Из проведенного мною исследования это, безусловно, кажется большой альтернативой для этой ситуации.

В частности, я посмотрел на CouchDB и MongoDB. Оба выглядят великолепно. Тем не менее, есть несколько других частей, которые мы должны иметь в своем инвентаре:

Нам нужно иметь возможность выбирать предметы только из одного (или нескольких) запасов.Нам нужно иметь возможность фильтровать предметы по его параметрам (например, получить все предметы из инвентаря 2, где тип - «гостиница»).Нам нужно иметь возможность группировать товары на основе параметров (например, получить самую низкую цену от предметов в инвентаре 1, где брендом является «Samsung»).Нам необходимо (потенциально) иметь возможность извлекать тысячи элементов одновременно.Нам нужно иметь доступ к данным из нескольких приложений; как backend (для обработки данных), так и frontend (для отображения данных).Быстрая массовая вставка желательна, хотя и не обязательна.

Исходя из структуры и требований, подходят ли нам CouchDB или MongoDB? Если да, какой из них подойдет лучше всего?

Спасибо за чтение, и заранее спасибо за ответы.

РЕДАКТИРОВАТЬ: Одна из причин, по которой мне нравится CouchDB, заключается в том, что в веб-приложении мы можем запрашивать данные через JavaScript напрямую с сервера после загрузки страницы и отображать результаты без необходимости использовать какой-либо внутренний код. Это приведет к лучшей загрузке страницы и меньшей нагрузке на сервер, поскольку выборка / обработка данных будет выполняться на стороне клиента.