Какие БД используют крупнейшие торговые сети для хранения заказов?

Стало интересно, такие гиганты, типа Магнит, МВидео, Пятерочка, где по всей стране множество магазинов одновременно сохраняют данные покупки (состав покупки, цены, скидки) и это достаточно оперативно становится доступно для просмотра клиентом в приложении - какие используют БД для сохранения покупок?
С одной стороны магазины используют OLAP, ведь им надо делать аналитику, с другой стороны OLTP, потому что нужные "четкие и точные" данные транзакций.
Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?
Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?
Я прав? Буду рад ссылкам на чтиво.
  • Вопрос задан
  • 17012 просмотров
Решения вопроса 3
mayton2019
@mayton2019
Bigdata Engineer
Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?


XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.
Ответ написан
vabka
@vabka
Токсичный шарпист
Ответ на твой вопрос можно дать, но я сильно сомневаюсь, что какую-то пользу он тебе принесёт.
Ну и как заметили в комментариях - ты и так уже сам на свой вопрос ответил.
Чтиво - начни с Клеппмана и его книги с кабанчиком, а в нём ссылок на чтиво более чем достаточно будет.

Обычно в первую очередь OLTP, а уже потом OLAP. Сначала грузится в условный постгрес, а из него уже в какую-то аналитическую систему (сорян, не шарю в этом направлении).

Какие конкретно базы используются - можешь посмотреть по вакансиям. Причём в рамках одной крупной компании (а федеральные сети - это как раз крупные компании) может использоваться сразу несколько разных СУБД чисто за счёт того что внутри существует множество продуктов для внутреннего использования, которые разрабатываются разными командами.

Из конкретных продуктов - буквально все существующие реляционные СУБД бери и в принципе все они будут так или иначе использоваться для разных задач + ещё 1С и SAP.
Ответ написан
Комментировать
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Какие БД используют крупнейшие торговые сети для хранения заказов?

В Магнит и X5 используются PostgreSQL, Greenplum и Clickhouse. В Эльдорадо во времена моей работы был Oracle и MS SQL Server, сейчас наверняка на PostgreSQL переехали.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Опять же не знаю, как сейчас, но 13 лет назад у Эльдорадо была довольно устойчивая иерархическая инфраструктура. Часть сервисов жила в двух ЦОДах, часть в серверных региональных офисов, часть на серверах магазинов, плюс кассы какое-то время могли продолжать работать вообще самостоятельно.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
klassev
@klassev
смотрим вакансии этих компаний и получаем ответ )
668f59e7cf644074182522.png
Ответ написан
Комментировать
@ufff
творец
Как и в 90-е - dbase с интерпретатором clipper
Ответ написан
@Gleb3Bro
Я не работал со всеми СУБД, но из личного опыта скажу что oracle самые быстрые.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы