Какой из CouchDB или MongoDB удовлетворяет моим потребностям?

Где я работаю, мы используем 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').
• Мы должны (потенциально) смочь получить тысячи объектов за один раз.
• Мы должны смочь получить доступ к данным из нескольких приложений; оба бэкенда (для обработки данных) и frontend (для отображения данных).
• Быстрая объемная вставка желаема, хотя не требуемый.

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

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

Править: Одна из причин, мне нравится CouchDB, - то, что это было бы возможно для нас в клиентском приложении запросить данные через JavaScript непосредственно с сервера после загрузки страницы и отобразило бы результаты, не имея необходимость использовать любой код бэкенда вообще. Это привело бы к лучшей загрузке страницы и меньшей деформации сервера, поскольку выборка/обработка данных будет сделана клиентская.