Скидки до  250$  ! Успейте купить ImageCMS 5.0 с дизайном или заказать разработку сайта  Подробнее
Главная / Блог / Электронная коммерция / Базы данных NoSQL: выбираем способ хранения информации о товарах для e-commerce

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

20 июля 16
Reading Time: 2 minutes
Комментариев нет
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes)

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

Comments (0)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Более 3000 запущенных проектов

Вместе с нами многие уже развивают свой бизнес! Смотреть все отзывы
Перепробовав много CMS (opencart, Битрикс) и др. Мы увидим, как много в каждой из них недостатков. Где-то или очень сложно или очень дорого кастомизировать. Работая маркетологом, могу заверить, что в ImageCMS большинство нужны "фич" реализовано из коробки, без дополнительных надстроек. Посмотрев демо версию новой версии движка, был приятно удивлен скоростью работы (ооочень важно).
За время сотрудничества компания показала себя в качестве ответственного подрядчика, быстро воплотив в жизнь удобный интернет-магазин с учетом всех наших пожеланий.
Работой доволен. Отвечают всегда быстро и по сути, остаются только приятные впечатления от общения. Пара слов о новом движке: Быстро, красиво и интуитивно понятно. Полностью оправдывает вложенные средства. Рекомендую.
Доволен. Скрипт считаю перспективным. Считаю, что ваш коллектив работает на опережение: ваше предложение было оптимальным по цене/качеству.
Опертивная и четкая работа, своевременое предоставление дополнительных консультаций по работе с административной частью. Созданным магазином довольна. Рекомендую этот движок!
Заказать услугу
Персональная информация:

прикрепить файл

Создайте свой личный демо-магазин ImageCMS