Базы данных NoSQL: выбираем способ хранения информации о товарах для e-commerce

Amazon Web Services DynamoDB, MongoDB, Couchbase, MarkLogic – примеры баз данных NoSQL, которые могут предложить вам удобный способ хранения информации о товарах.

То, как e-commerce-сайт хранит информацию о товарах, имеет ощутимое влияние на успех бизнеса.

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

Атрибуты товаров

Большинство e-commerce-платформ хранят информацию о товарах в реляционных базах данных. Допустим, у нас есть красная футболка размером S со своим уникальным номером и артикулом (SKU). Вот как выглядела бы таблица со всеми данными об этом товаре:

Для каждого из этих атрибутов требуется колонка в таблице базы данных. Строка таблицы отображает полную информацию о товаре.

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

Запрос по какому-нибудь из товаров из такой таблицы будет относительно простым, и нужный результат должен быстро загрузиться. Но что, если, помимо футболок, интернет-магазин продает брюки, имеющие другой набор атрибутов? Допустим, размер брюк не измеряется по стандартным S, M и L, а по талии и внутреннему шву.

В таблице понадобятся дополнительные колонки:

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

Каждый новый тип потребует по несколько новых атрибутов, не считая цен, скидок, веса, габаритов и прочего.

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

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

Мы получим таблицу для футболок:

И таблицу для брюк:

Но таким способом хранения данных, хоть он и более рационален в плане экономии пространства в таблицах, будет крайне сложно пользоваться. E-commerce-платформе будет трудно справляться с таким количеством таблиц, стараясь при этом еще и понимать их связь друг с другом. Чтобы получить из такой базы, например, список товаров от одного производителя, потребуется несколько сложных запросов.

Еще одно решение проблемы атрибутов товара – это использование системы EAV (entity-attribute-value). Entity – это некая сущность, абстрактное понятие, у которого существует неограниченный набор атрибутов, например, категории товаров или сам товар. Attribute – это, собственно, атрибуты товара, например, название, размер, цена. И value – это конкретное значение, принадлежащее атрибуту. Некоторые популярные e-commerce-платформы, например, Magento, используют этот подход.

В системе EAV часто используется несколько таблиц для хранения отдельных порций информации о товаре. Вот, например, информация о сущности, объекте:

Другие таблицы будут содержать значения отдельных атрибутов

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

NoSQL для информации о товарах в e-commerce

NoSQL – это нереляционные базы данных с другим, неструктурированным, подходом к хранению информации. Здесь нет таблиц с структурированными колонками и строками, а хранение данных допускается виде “ключ-значение”.

Несмотря на то, что нереляционные базы данных существуют уже несколько десятилетий, NoSQL только в последнее время стали популярными среди крупных игроков интернет-бизнеса, включая Google, Facebook, eBay и Amazon.

Архитектура NoSQL может отличаться в разных решениях этого типа баз данных. Но в целом NoSQL предполагает, что вся информация об отдельном товаре хранится в одном так называемом контейнере для строк или документе.

Иногда эти контейнеры или документы выполнены в JSON или другом подобном формате, поэтому часто они могут выглядеть знакомо для веб-разработчиков.

Итак, товар в такой базе данных будет иметь уникальный номер (ID), набор общих атрибутов товара и несколько атрибутов, уникальных конкретно для этого товара. Наша красная футболка в размере S в такой базе данных может выглядеть следующим образом:

{
    unique_id: ‘HY8765NBg6yYT77nBhNkln543NjNhYTR’,
    sku: ‘POI0987654321’,
    type: ‘футболка’,
    title: ‘Клевая футболка’

   attributes: {
        size: ‘s’,
        color: ‘красный’
    }
}

В случае с брюками контейнер будет выглядеть так:

{
    unique_id: ’99iIiGtg6GHGjfj776098JjHGtgfffhhh’,
    sku: ‘POI0987654323’,
    type: ‘брюки’,
    title: ‘Зачетные брюки’

   attributes: {
         waist: ’76’,
         inseam: ’79’,
        color: ‘черный’
    }
}

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

{
    unique_id: ‘jjfJlkjsdfALKJljJLKDJ877KJNBB’,
    sku: ‘BE1888477’,
    type: ‘пояс’,
    title: ‘Отличный ремень’

   attributes: {
         size: ’76’,
         length: ’76’,
         color: ‘черный’,
         material: ‘кожа’
    }
}

Как видите, NoSQL – намного более удобная и гибкая система хранения данных. Она позволяет сделать запрос по конкретному товару намного более быстрым. А это особенно радует, учитывая то, что количество товаров в базе данных со временем всегда возрастает. Все больше компаний выбирает именно NoSQL-решения, большинство из которых поддерживает горизонтальное масштабирование, и, таким образом, способствует существенной экономии средств.

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