Смотрите, все равно у вас данные находятся в одной базе, неважно как вы их оттуда достаете (через хранимки, через PHP и т.д.). И запись идет только на Мастере. Чем тут помогут PHP-прослойки?

Кроме того, современные БД поддерживают модель «мульти-мастер»

Наш кейс следующий:

1. Вся расчетная логика у нас на слэйвах, Мастер только пишет готовые результаты. По итогам тестов на сервере m5.8xlarge было достигнуто стабильное обновление 50К записей в секунду (для информации: вся VISA по миру обратывает 5К транзакций в секунду)

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

3. Также помогает грамотная работа с индексами: не плодить их десятками на таблицу, а ограничиться 2-3 (у нас во всей системе 12 таблиц и 20 индексов). И минимизировать обновление значений первичных ключей (тоже возможно). Тогда при обновлении данных потребуется заметно меньше операций.

Как сделать первый шаг, я знаю. Как SQL-код из 300 строк превратить в PHP-код из 10 строк — не знаю. Просьба продемонстрировать на примере. Иначе зачем бросать слова на ветер?

База одна — просто хранимки распределены по разработчикам. Их немного, они достаточно изолированные. Критические замечания можно комментами, можно и голосом сказать — нечасто это происходит за счет компактности кода, 2-3 раза на релиз

На входе в json (параметр ljInput) идет шаблон с ключами и необходимый язык локализации (испанский, например) => на выходе: шаблон с уже локализованным текстом.

Все выполнено в одном SQL-запросе: обработка и валидация параметров, получение данных из базы, упаковка ответа в json

Если опустить декларативную часть (до BEGIN и после EXCEPTION), то вот пример (сорри за сбитое форматирование):

RETURN COALESCE((
WITH
«email_keys» AS
(SELECT jsonb_array_elements_text((CASE WHEN (jsonb_typeof(ljInput->'templateName') IS NOT DISTINCT FROM 'array') THEN ljInput->'templateName' ELSE '[]'::jsonb END)) AS key_name)

«email_values» AS
(SELECT
«email_keys».key_name,
COALESCE((SELECT COALESCE(«content_ref».jdesc->>(COALESCE(ljInput->'localeName', '0')), «content_ref».jdesc->>'0')
FROM public.«content_ref»
WHERE («content_ref».ref_id = 16) AND
(«content_ref».ref_name = «email_keys».key_name)
LIMIT 1
), '') AS key_value
FROM «email_keys»)

SELECT jsonb_object_agg(«email_values».key_name, «email_values».key_value)
FROM «email_values»
), '{}'::jsonb);

Кто сказал, что нет код ревью? Сначала ревью, потом тесты на release-candidate базе, потом прод

По фронтенду отдельные статьи будут, но там тоже похожие результаты по эффективности ресурсов и времени разработки

Кто сказал, что PG — это NoSQL база? Я писал про подход «SQL — NoSQL», когда классические SQL-подходы (первичные ключи например, которые и обеспечивают уникальность) совмещаются с гибкостью NoSQL.

Каждый вызов хранимки — это изолированная транзакция, с автоматическим коммитом (или роллбэком на exception)

Отличное решение) За последние 5 лет PG сильно вырос. Надеюсь, не разочаруетесь

Тут как раз все просто:
www.postgresql.org/docs/11/sql.html

Да, есть DataGrip, который напрямую с базой работает. Или pgAdmin

Хранимки хранятся в самой базе данных. Для загрузки на Мастер можно сделать следующее:
1. Запускается SQL-скрипт, который все хранимки собирает в одном большом pgSQL-запросе (на пару мегов)
2. Это запрос выполняется на Мастере

Можно также не все хранимки, а только часть залить

Ринат, спасибо) Интересная статья — рекомендую

В первую очередь я хотел показать возможности баз данных — насколько они эффективнее для решения задач обработки данных, которые хранятся в базах данных (сорри за тавтологию). На нашем примере мы разобрали кейсы обработки данных вне базы (старая архитектура) и внутри базы (новая архитектура).

Обсуждение полной архитектуры веб-сервисов — это наверное темы других статей

Один SQL запрос может включать в себя десятки селектов, инсертов, апдейтов и т.д. Поэтому вы можете в одном запросе:
1. Распарсить json
2. Валидировать атрибуты
3. Выбрать данные из множества таблиц исходя из этих атрибутов
4. Провести дополнительую валидацию
5. Обновить / вставить данные в таблицу 1
6. Удалить данные в таблице 2
7. Сформировать ответ в json

Почему это удобнее:

1. Все данные уже в памяти, во временных таблицах (CTEs): вам не надо каждый раз что-то выбирать из таблицы, сохранять в массиве, обрабатывать массив, потом опять считать данные, и т.д.

2. Логика в одном месте (а не разбросана по микросервисам), ее легко проверить (понятно, что из чего получается), легко накатить (одна хранимка)

3. Про скорость разработки и размер кода уже много раз писал

Это зависит от задачи (нужно ли выбирать данные именно в определенном порядке, или просто отсортировать ответ) и от объема данных (если размер таблицы до миллиона строк, то можно выбрать первичный ключ и поле для сортировки, и далее отсортировать в памяти)

Если таблица большая, и обязательно надо делать выборки с учетом сортировки по определенной колонке (например, из ста миллионов статей выбрать 100 лучших по рейтингу), то я предпочитаю разные запросы написать (пока более 3-х вариантов сортировки не попадалось).

Динамический SQL — тоже вариант, поделитесь опытом использования

Алексей, PG начиная с 10-й версии справляется с парсингом и формированием json не хуже других популярных языков, а учитывая, что данные сразу из таблиц попадают в json внутри одного SQL запроса, то многие ненужные прослойки просто убираются. Кода становится меньше, отлаживать его проще.

Проектированием баз данных я занимаюсь уже почти 30 лет, на заре деятельности прочитал немало книг по реляционной модели СУБД. И активно использовал именно эту модель до 2015 года. Далее я начал активно следить за развитием PG, изучал доклады на PGConf и других конференциях (в 2020 году выступал там) — в итоге с 2016 года перешел на модель SQL-NoSQL, с активными использованием jsonb-полей.