Nilson Report: UnionPay стала лидером по объёму транзакций на мировом рынке дебетовых карт

Кажется, что с картинкой что-то не так:

• в глаза сразу бросается, что сумма за 2021 год больше 100% (привет Чурову)

• числа не очень совпадают с оригинальным исследованием:

Для UnionPay: 40.03 - 1.39 = 38.64% в 2021 и 40.03% в 2022

Debit cards with the UnionPay brand held a market share of 40.03% of all debit card purchase transactions, an increase of 139 bps.

Для Visa: 38.78 + 0.82 = 39.6% и 38.78%

Visa’s share of debit card transactions was 38.78%, down 82 bps.

Mastercard: 21.19 + 0.57 = 21.76% и 21.19%

Debit cards with the Mastercard brand held a 21.19% share of all debit card purchase transactions, a decline of 57 bps. 

Также не очень понятно откуда взялось вот это (не нашел в оригинале):

1. Транзакции по дебетовым картам Visa с 2011 года сократились с 80% до 39,53%. 

2. Доля дебетовых карт Mastercard в 2021–2022 годах снизилась с 39,5% до 21,1%. 

SQL миграции в Postgres. Часть 2

Спасибо! К сожалению, мой опыт работы с другими РСУБД значительно меньше, поэтому не смогу сделать качественный анализ.

Синхронизируем приложения с помощью Advisory Locks (postgresql). Что это, зачем, и нюансы работы с pgBouncer

PgBouncer может работать в двух режимах: сессионный и транзакционный.

В 3 режимах - есть ещё statement.

Мигрируем БД в продакшене без даунтайма

Мы же не пытаемся обеспечить там zero-downtime, верно? И вообще, зачем пытаться запускать окружение разработчика на кластере и за балансировщиком нагрузки?

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

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

Мигрируем БД в продакшене без даунтайма

промазал ответом

Мигрируем БД в продакшене без даунтайма

"Auto-migration on startup" - это одна из стратегий. Есть еще режим "Validate", который сверяет миграции в приложении с теми, что были применены в БД. Это позволяет, например, реализовать схему, когда один экземпляр приложения отвечает за накатку миграций, а остальные делают только валидацию.

Мигрируем БД в продакшене без даунтайма

При использовании CI/CD сервера для накатки миграций каким образом накатывать их на локальные окружения разработчиков?

Одно из удобств упомянутых ранее инструментов вроде flyway и liquibase, а если быть точнее в целом стратегии обновления схемы через приложение, в том, что процесс одинаков для всех окружений - где бы приложение не запустилось, оно либо обновит схему до нужной версии, либо упадет, сообщив, что схема несовместима.

Мигрируем БД в продакшене без даунтайма

Я не большой эксперт в kubernetes, но вроде как это можно решить с помощью настройки maxUnavailable и maxSurge.

Храним данные в JSONB, как это влияет на скорость запросов?

Помимо отсутствия индекса history_b_results(history_b_id), не понятно для чего разбивать таблицу на две - можно в history_b_results добавить customer_uuid и не делать JOIN. Но возможно, что в реальности есть какие-то доп. детали, которые опущены в примере.

PostgreSQL Antipatterns: делаем группировку быстрее от 0.1 до 5 раз

У вас результаты исходного и оптимизированного запросов отличаются. Исходный запрос сперва делает join, а потом sum, а второй сперва sum, а потом DISTINCT, из-за чего сумма в 8 раз больше. До:

i	sum
1	288
2	288
3	288

После:

i	sum
1	36
2	36
3	36

SQL миграции в Postgres. Часть 1

В добавление к ответу выше – если ограничение/индекс не включает ключ партиционирования, но при этом «глобальная» уникальность требуется, есть костыльный вариант создать триггер на модифицации для валидации. Но это будет сильно влиять на производительность обновлений.

SQL миграции в Postgres. Часть 1

Согласитесь, что ключи и индексы — это совершенно разные вещи. Ключи обеспечивают целостность и непротиворечивость данных с точки зрения бизнес правил, в то время как индексы — это чисто техническая вещь для ускорения доступа к данным.

Полностью согласен с вами и сам лично также предпочитаю выполнять этот последний «опциональный» пункт по созданию ограничения на основе индекса.
Более того, как я отметил в статье, раньше даже сама документация советовала использовать ограничение, а вот почему с 9.5 эту сноску удалили – интересный вопрос.

SQL миграции в Postgres. Часть 1

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

С EXCLUDE мне не особо приходилось работать, поэтому ничего не написал :-) Если есть, чем поделиться, то так же буду рад дополнить статью.

Насчет остального – спасибо за идеи, подумаю.

SQL миграции в Postgres. Часть 1

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

SQL миграции в Postgres. Часть 1

Спасибо за подробный комментарий! Дополню статью.
Небольшой вопрос – в какую из минорных версий pg12 попал ваш патч (беглый поиск по release notes не помог мне)?

SQL миграции в Postgres. Часть 1

Спасибо за комментарий!

Ответ очень простой: на ограничения уникальности можно ссылаться из внешних ключей. Просто индекса в этом случае недостаточно. Читаем документацию:
…

Эксперименты показывают, что уникального индекса все же достаточно. В ссылке на SO выше есть пример для воспроизведения:

create table A(
  first_a varchar,
  second_a varchar,
  third_a varchar,
  primary key(first_a, second_a)
  );
  
  create unique index on A (second_a, third_a);
  
  create table B(
    first_b varchar,
    second_b varchar,
    foreign key (first_b, second_b) references A(second_a, third_a), --references the unique index
    foreign key (first_b, second_b) references A(first_a, second_a) -- references the primary key
    );

Причем, если не создавать индекс, то получим ошибку:

ERROR: there is no unique constraint matching given keys for referenced table «a»

В общем, похоже на неточность в документации.

Работа с базами данных глазами разработчика

Спасибо!
Кстати, для того, чтобы быстро откатывать вашу базу в начальное состояние вы можете посмотреть в сторону «тонкого клонирования» — быстрое создание копии файловой системы на основе ZFS. Есть даже более менее готовое решение — Database Lab. Сам я его на практике не пробовал, но вероятно, мы будем рассматривать его как один из вариантов для реализации т.н. «иммутабельных» тестовых сред (когда на каждый запуск набора e2e тестов создается новая база с подготовленными тестовыми данными).

Работа с базами данных глазами разработчика

Я согласен с вами — тестовые данные нужны только для тестов и располагать их в общих миграциях будет неправильно. С другой стороны, если для тестов также хочется иметь версионность (т.е. для разных версий схемы данных разные тестовые наборы, а не только тесты для последней версии), то можно вести отдельную систему миграций. Примерно так:
Основные миграции:
V1_create_table1.sql
V2_alter_table1.sql
V3_create_table2.sql
Тестовые миграции:
V1_create_test_data_table1.sql
V2_create_test_data_table1.sql
V3_create_test_data_table2.sql
А при запуске тестов в зависимости от версии схемы данных накатывать на базу соответствующую миграцию с данными.

Не очень понимаю, когда это может быть нужно, но теоретически, наверное, имеет право на жизнь :-)

Работа с базами данных глазами разработчика

Промахнулся ответом — comment_21926692

Работа с базами данных глазами разработчика

Сколько у вас тестов и как долго они выполняются?

Интеграционных тестов примерно 2 тысячи, выполняются около 5-7 минут.

Не удалось ли вам с подготовкой образа как-то примонтировать tmpfs (может быть, копированием data dir через init.sh в образе)?

Сконцентрировавшись на проблеме прогона миграций на запуске каждого тестового класса, мы почему-то даже не посмотрели в эту сторону, но выглядит перспективно, попробую — спасибо за идею и за вашу заметку!