Базы данных

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

Postgres LISTEN/NOTIFY can cause severe performance issues under high write concurrency due to a global lock during commit. Learn why it doesn’t scale and how to avoid outages.

1. Масштабирование
2. Бизнес хочет хранить данные за все время
3. EAV упрощает проектирование
4. ORM упрощает разработку
5. Главное зло в PostgreSQL - autovacuum
6. JOIN это зло - они медленные
7. Давайте изобретем Slony
8. У меня в тесте все работает
9. Be smart, as a java-developer
10. Приятные мелочи

Способы скалировать посгрес. От простых к сложным.

Список worst practice для PostgreSQL.

Основные пункты:

• Никогда не использовать BETWEEN
• Никогда не использовать NOT IN
• Никогда не использовать timestamp без таймзоны. Безопасно использовать только timestamptz
• Не рекомендуется использовать serial

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

• MapReduce умерли
• Key-value стали нишевыми
• Document stores функциональность была добавлена в обычные RDBMS, а они сами - стали добавлять транзакции и приближаться к обычным бд
• Columnar database
• Text search engines заняли свою специфичную нишу
• Array databases популярны в Data science
• Vector databases ещё живы, но скорее всего обычные бд адаптируют у себя их фичи
• Graph database заняли нишу для специфичных профилей нагрузки

Новые тренды:

• Column stores
• Cloud databases
• Data Lakes / Lakehouses
• NewSQL systems
• Hardware accelerators
• Blockchain Databases

Чуть более удобный explain analyze.

• Count(*) vs Count(1) одинаковые
• Если хочется иметь быстрый каунт для всей таблички, можно завести доп табличку и триггером ее обновлять
• Можно брать эстимейты из посгресовых данных (данные планировщика)
• Можно эстимейтить по TABLESAMPLE
• Ещё есть вот такая статья, но его ещё нет в PostgreSQL

Процесс миграции в notion с обычной на шардированную бд.

• Проектирование шардирования
• Процесс миграции

Как порядок колонок в посгресе влияет на объем данных, и следовательно на производительность. С примерами как дебажить, жаль без готового тулинга который бы указал “идеальный” порядок

Статья про оптимизацию авто вакума и блоатинга.

Postgres for Search and Analytics

Postgres Data Warehouse, built on Iceberg.

A lightweight message queue. Like AWS SQS and RSMQ but on Postgres. - pgmq/pgmq

PostgreSQL zero-downtime migrations made easy

Мигратор схемы для postgresql. Пишут, что zero downtime, но я внутри не смотрел почему это так.

Разгрузить базу:

1. Оптимальный SQL
2. Правильные настройки
3. Все лишние операции - на приложение
4. Меньше коннектов
5. Транзакции покороче
6. Грамотное использование реплик
7. Секционирование таблиц
8. Асинхронная обработка

Разделить базу:

1. Шардинг уровня БД
2. Шардинг уровня приложения
3. Разделить систему