Эталонная архитектура розничной торговли, часть 1: создание гибкого каталога продуктов с низкой задержкой и возможностью поиска

[Эта статья была написана Брайаном Рейнеро.]

Управление данными каталога товаров является сложной задачей для ритейлеров сегодня. После многих лет использования нескольких монолитных систем, предоставляемых поставщиками, розничные продавцы сейчас пересматривают свои возможности и смотрят в будущее.

В современных системах, предоставляемых поставщиками, данные о продуктах часто необходимо перемещать назад и вперед с использованием процессов ETL, чтобы гарантировать, что все системы работают с одним и тем же набором данных. Этот подход медленный, подвержен ошибкам и дорог с точки зрения разработки и управления. В ответ ритейлеры теперь предоставляют услуги передачи данных по отдельности в рамках централизованной сервис-ориентированной архитектуры (SOA).

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

Почему MongoDB?

Множество разных типов баз данных могут удовлетворить наш сценарий использования каталога продуктов, так почему же стоит выбрать MongoDB?

• Гибкость документа: каждый документ MongoDB может хранить данные, представленные в виде расширенных структур JSON. Это делает MongoDB идеальным для хранения практически всего, включая очень большие каталоги с тысячами вариантов на элемент.
• Динамическая схема: структуры JSON в каждом документе могут быть изменены в любое время, что позволяет повысить гибкость и простую реструктуризацию данных при необходимости. В MongoDB эти несколько схем могут храниться в одной коллекции и могут использовать общие индексы, обеспечивая эффективный поиск как старого, так и нового форматов одновременно.
• Язык экспрессивных запросов: возможность выполнять запросы по многим атрибутам документа упрощает многие задачи. Это также может повысить производительность приложений за счет снижения необходимого количества запросов к базе данных.
• Индексирование: Мощные вторичные, составные и геоиндексирующие опции доступны в MongoDB прямо из коробки, быстро обеспечивая такие функции, как сортировка и запросы на основе местоположения.
• Согласованность данных: по умолчанию все операции чтения и записи отправляются первичному члену набора реплик MongoDB. Это обеспечивает строгую согласованность, важную функцию для розничных продавцов, у которых может быть много клиентов, делающих запросы на один и тот же товар.
• Геораспределенные реплики. Задержка в сети из-за географического расстояния между источником данных и клиентом может быть проблематичной, особенно для службы каталогов, которая, как ожидается, будет поддерживать большое количество операций чтения с низкой задержкой. Наборы реплик MongoDB могут быть геораспределены, так что они близки к пользователям для быстрого доступа, что во многих случаях снижает потребность в CDN.

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

• Поиск предметов и вариантов предметов
• Получение цен на товары в магазине
• Включение просмотра каталога с помощью фасетного поиска

Модель данных элемента

Первое, что нам нужно рассмотреть, — это модель данных для наших товаров. В следующих примерах мы показываем только самую важную информацию о каждом товаре, такую ​​как категория, марка и описание:

{   “_id”: “30671”, //main item ID   “department”: “Shoes”,   “category”: “Shoes/Women/Pumps”,   “brand”: “Calvin Klein”,   “thumbnail”: “http://cdn.../pump.jpg”,   “title”: “Evening Platform Pumps”,   “description”: “Perfect for a casual night out or a formal event.”,   “style”: “Designer”,   …}

Этот тип простой модели данных позволяет нам легко запрашивать элементы на основе наиболее востребованных критериев. Например, используя db.collection.findOne, который вернет один документ, который удовлетворяет запросу:

• Получить товар по ID
  db.definition.findOne({_id:”301671”})
• Получить элементы для набора идентификаторов продуктов
  db.definition.findOne({_id:{$in:[”301671”,”452318”]}})
• Получить товары по префиксу категории
  db.definition.findOne({category:/^Shoes\/Women/})

Обратите внимание, как во втором и третьем запросах используются $inоператор и регулярное выражение соответственно. При выполнении с правильно проиндексированными документами MongoDB может обеспечить высокую пропускную способность и низкую задержку для этих типов запросов.

Вариантная модель данных

Еще одним важным фактором для нашего каталога продукции являются варианты элементов, такие как доступные размеры, цвета и стили. Наша модель данных об элементах, представленная выше, собирает только небольшое количество данных о каждом элементе каталога. Так что же насчет всех доступных вариантов элементов, которые нам могут понадобиться, таких как размер и цвет?

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

Другой вариант — создать отдельную вариантную модель данных, на которую можно ссылаться относительно основного элемента:

{
“_id”: ”93284847362823”, //variant sku
“itemId”: “30671”, //references the main item
“size”: 6.0,
“color”: “red”
…
}

db.prices.find({_id:{$in:[“30671_store23”,
“30671_sgroup12”,
“93284847362823_store23”,
“93284847362823_sgroup12” ]}})

{ 
“_id”: “30671”,
“title”: “Evening Platform Pumps”,
“department”: “Shoes”,
“Category”: “Women/Shoes/Pumps”,
   “price”: 149.95,
“attrs”: [“brand”: “Calvin Klein”, …],
“sattrs”: [“style”: ”Designer”, …],
“vars”: [
{
“sku”: “93284847362823”,
“attrs”: [{“size”: 6.0}, {“color”: “red”}, …],
“sattrs”: [{“width”: 8.0}, {“heelHeight”: 5.0}, …],
}, … //Many more SKUs
]

}