Там, где я работаю, мы используем 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 напрямую с сервера после загрузки страницы и отображать результаты без необходимости использовать какой-либо внутренний код. Это приведет к лучшей загрузке страницы и меньшей нагрузке на сервер, поскольку выборка / обработка данных будет выполняться на стороне клиента.