Евгений

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

Ответ на твой вопрос можно дать, но я сильно сомневаюсь, что какую-то пользу он тебе принесёт.
Ну и как заметили в комментариях - ты и так уже сам на свой вопрос ответил.
Чтиво - начни с Клеппмана и его книги с кабанчиком, а в нём ссылок на чтиво более чем достаточно будет.

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

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

Из конкретных продуктов - буквально все существующие реляционные СУБД бери и в принципе все они будут так или иначе использоваться для разных задач + ещё 1С и SAP.

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


Если мы говорим про postgres, то если ты обновил какую-то запись (кортеж), то неявно получаешь на нее (запись) блокировку. Когда кто-то другой хочет обновить эту же запись, то ждет ее освобождения.
В данном случае (визуализация), 1 процесс выполнял UPDATE X, Y а другой UPDATE Y, X, т.е. первый взял блокировку сначала на X потом на Y, а другой - сначала на Y потом на X. Первая блокировка успешна, но вторые нет - они уже заняты.
В данном случае, разрешить их нельзя, т.к. оба ждут пока один из них снимет блокировку, но этого не произойдет. Блокировка со строки снимется по окончании транзакции.

Совет про сортировку взят, чтобы привнести единообразие в работу. Грубо говоря, дедлок появляется, когда нет согласованности в работе. Если оба выполнят UPDATE X, Y (в таком порядке), то дедлока не будет т.к. один из них сможет взять все блокировки на строки успешно. Поведение второго будет уже зависеть от уровня сериализации:
- Read committed - обновит новые данные
- Другие (repeatable read, serializable) - ошибка выполнения
Это уже детали MVCC в postgres (read uncommitted нет)

На Debian-based дистрибутивах (Ubuntu, Debian, etc) есть утилита pg_ctlcluster - с помощью нее можно управлять несколькими инсталляциями postgres одновременно, учитывая версии/название кластера.
Например, так можно

# Запуск кластера 15 версии
pg_ctlcluster start 15 main

Для того, чтобы они запускались одновременно, то можно использовать разные порты - чтобы запускались на разных портах. Например, 15 версия на 5432 порту, а 13 - на 5433.
Это сделать можно либо через postgresql.conf - конфигфайл, ищи port. Изначально он такой:

#port = 5342                      # (change requires restart)

раскоментируй и выстави свое значение. Подсказка - он скорее всего в директории /var/lib/postgresql//, например, /var/lib/postgresql/13/main/postgresql.conf

Для подключения просто передай psql нужный порт:

psql -p 5432 # 15 версия
psql -p 5433 # 13 версия

Добавить индекс по выражению length(my_str)

У тебя есть индекс на выражение?
Если нет, то логично что он делает фул скан таблицы.

Попробуй этот навесить

create index t_my_str_length_idx on t(length(my_str));

1. запустили намеренно pg_dump с отказом -O - то есть --no-owner
   
2. развернули дамп от супера
   
3. все объекты теперь ожидаемо принадлежат суперу, owner'а же не переносили
   
4. удивляемся, что постороннему пользователю нет прав чтения
   

Что же тут могло пойти не так?

Самое простое для баз с одним пользователем - импортируйте дамп базы от имени этого самого пользователя. Если в базе есть какие-то extension - то сперва их создать от суперпользователя.

Зависит от pool_mode.

В режиме session баунсер прозрачен для приложения: не налагает каких-то явных ограничений на использование, но один клиент к баунсеру = один коннект к базе. Соединение с базой сможет быть передано другому клиенту только после того как предыдущий клиент отключится. Поэтому этот режим используется очень редко.

В режиме transaction пула коннект к базе выдаётся клиенту только на время транзакции. Самый распространённый режим работы, любим именно за то, что сколько бы тысяч коннектов не открыло приложение к баунсеру, на базе открыто небольшое число действительно потребовавшихся соединений.
Но этот режим пула налагает ограничения на работу приложения. Вы не сможете нормально использовать ничего, что меняет состояние коннекта, потому что следующий ваш запрос с высокой вероятностью попадёт в другой коннект. То есть курсоры, временные таблицы, set (кроме set local), prepared statements (где parse, bind и execute могут разойтись по 3 разным коннектам)

С prepared statements в transaction pool mode с недавних пор может помочь настройка max_prepared_statements, но только если prepare и deallocate выполняются именно командами протокола, но не SQL запросами. Тут многие широкоиспользуемые библиотеки оказались в пролёте.

pgbouncer начал поддерживать prepared statements совсем недавно и в ограниченном объёме. Если есть возможность - лучше от них избавиться.

В целом в вашем случае пулер - то, что нужно. Если приложение не умеет само вовремя отключаться от базы, пусть лучше занимает слоты у pgbouncer.

Принудительно рубить idle коннекты я бы не стал, но в целом это делается вот этим параметром:

client_idle_timeout

Client connections idling longer than this many seconds are closed. This should be larger than the client-side connection lifetime settings, and only used for network problems.

Default: 0.0 (disabled)

В реляционных БД не существует гарантий относительно порядка записей внутри таблицы. Этот порядок
- это особенности технической реализации хранения данных внутри блоков и сегментов. Это - "know how"
и это будет зависеть от типа DBMS (Postgres, MySQL, Oracle) и от типа таблицы (heap, index-organized, clustered e.t.c)

Если говорить грубо, то записи (data-rows) лежат не плотно а вразнобой с пробелами с выравниванием
к блокам. Ну тоесть вообще-вообще не так как в Excel. Удаление data-rows в Postgres насколько я помню
физически не удаляет запись а помечает ее мертвой используя служебные поля. Впоследствии VACUUM
делает работы по уплотнению.

Поэтому порядок ты сам обеспечиваешь, делая запрос с опцией ORDER BY some_date_time.

Если я правильно понял, когда мы создаем индекс, у нас таблица изменяет порядок записей внутри себя сортируя их по указанным столбцам

нет, никакой порядок не меняется, индекс это отдельные от таблицы данные

И один индекс

равен тому, если бы мы создали три индекса в такой последовательности

нет, перестань уже придумывать и начни читать учебники и документацию

Которые бы по очереди друг за другом добавляли правило сортировки в таблице, верно?

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

Причем при изменении name обновление будет происходить дольше, чем при изменении price, потому что у нас price последняя в нашей очереди индексов по сортировке?

когда фантазию уже не остановить

phpPgAdmin History
------------------
Version 7.13.0
--------------
Released: November 7th, 2020
Features:
* Add support for Postgres 13
* Add provisional support for Postgres 14

Знакомая проблема: пользователи хотят видеть красиво пронумерованные документы.
За годы работы так и не сформировал единого подхода к преобразованию "непонятного" ID в "красивые циферки".
Есть такие реализации, может что подойдет:
1. Считаем порядок по счетчику, который сбрасываем в начале года. Легко реализуется. Минусы: при удалении элементов будут "дыры" в последовательности, что не нравится пользователям.
2. Считаем порядок динамически по дате добавления/утверждения записи. Легко реализуется. Минусы: при редактировании даты, добавлении документов "задним числом" нумерация поедет, что тоже не нравится пользователям.
3. Рассчитывать следующий номер документа исходя из номера последнего сохраненного (N+1). Обычно работает в паре с возможностью изменения номера руками (администратором ИС, например) - сбрасываем ответственность за нумерацию на пользователей. Полно подводных камней: от необходимости реализовать "сместить все на единичку с такого-то документа" до "нумерация поехала, исправьте".

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