про ошибки проектирования

== Как устроить хайлоад на ровном месте
https://youtu.be/jcCLqVQs5No?t=678
ошикби:
- неэффективное использование ресурсов
- база наружу
- разные сервисы на одной машине
- одна синхронная реплика ПОНИМАЖАЕТ надежность. Лучше одна синхронная и онда Асинхроннная с быстрым переключением
- неправильное тестирование
- пиковые нагрузки (по времени, по событиям, таймзонам)
- разумный отлуп роботов

Ошибки проектирования БД
- пагинация
- узкие таблицы (оверхед заголовков)
- широкеи таблицы (не более 50-100 колонок)
- NoSQL когда не надо
- json/xml когда не надо
- ненужная точность вычислений
- виртуализация для ДБ = ЗЛО

В индии ОДНА таймзона. нагрузка по времени в пике просто дичайшая!

F-sync через ядро ОС гостя, через фс ОС, дойти до ядра ОС, потом до ОС хоста, и тп...

== Транзисторный ключ, эмиттерный повторитель, пуш-пулл, полумост и мост. Самое подробное объяснение.
https://youtu.be/MgpT7ZICZSk

== Полнотекстовый поиск в PostgreSQL
https://youtu.be/5ZATiyvPQ-A
Индексы
- GIN - указатель (часто ищу)
- GIST - хэш дерево (редко ищу)
- RUM (extension)

Fuzzy search
- pg_trgm (extension)

прикольно, я думал что MIRO будут на редиске до конца жизни))) но...

== Отказоустойчивый кластер PostgreSQL + Patroni.
https://youtu.be/ZvLw9PU--_w

== Odyssey - масштабируемый пулер соединений для PostgreSQL
https://youtu.be/Wq7wQ9oyvSw
под каждый запрос постгрес делает FORK процесса !!! поэтому экономить подключения необходимо !!!

== Основы мониторинга PostgreSQL
https://youtu.be/Hbi2AFhd4nY

== PostgreSQL worst practices
https://youtu.be/HxwLCyCY8ec
- используйте индексы
- не используйте ОРМ
- юзайте джоины
- НЕ юзайте json поля
- не юзайте EAV (entity, attr, value)
- не ставьте индексы везде, только где надо и только где выигрыш по времени, меряй!
- не юзайте реплику как бэкап
- тестируйте бэкапы
- НЕ выключайте автовакуум
- архивируйте старые данные !
- используйте SLONY если надо, не юзайте велики!
- реплики и мастеры должны быть на одинаковом железе и с одинаковыми настройками!!!!
- не исполльзуйте синхронную репликацию для разных ЦОД
- юзайте FK. контроль целостности должен работать на строне БД а не приложения !!!!
- не патчите постгрес!
- надо делать маленькие транзакции !
- хранимка это место для только внутренних запросов. никаких запусков сторонних сервисов
- писать код нужно для того что бы потом читать
- оптимизируйте запросы
- юзайте PgQ
- попробуйте PL/pgSQL
- используйте Exceptions
- меньше коннекшнов! т.к. один запрос = 1процесс = 1ядро
- юзайте pgbouncer
- НЕ ЮЗАЙТЕ pgPool
- настраивайте shared_buffers! дефолтные натсройки PG для самого гголимого железа !
- не юзайте xmin/xmax для продакшна !
- мониторинг!
- надо делать меньше потоков
- юзайте COPY

== Блокировки в PostgreSQL
https://youtu.be/_R2-IsKfsUU
pg_stat_activity
pg_wait_sampling
pg_locks

SELECT pid, query, pg_blocking_pids(pid) AS blocking FROM pg_stat_activity

pg_row_locks

SELECT llocked_row, xids, modes, pids FROM pgrowlocks('t);

SELECT pid, locktype, transactionid AS xid, tuple as t, granted FROM pg_locks;

deadlock_timeout

== Девять кругов ада или PostgreSQL Vacuum
https://youtu.be/TDWC66qzxCs

MVCC - multiversion concurency control

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

== Зачем нужны Витрины данных (Data Mart)
https://telegra.ph/Prostor-dlya-dannyh-02-09

== Postgres 14 и высокие нагрузки
https://youtu.be/PIBuf3E4C04

== Энтерпрайзные вызовы для Postgres'а
https://youtu.be/bra0bQhIF8k
1) вызов горизонтальной масштабируемости
- масштабируется сейчас только READ нагрузка
- шардинг единственный способ для WRITE - только руками
- распределенные транзакции

2) Вызовы репликации
- проблема долгих запросов
- проблема временных таблиц на реплике
- задача сокращения WAL файлов
- логическая репликация DDL
- параллельное применение логического репликации
- физиологическая репликация

3) развигание пределов
- большине таблицы = решается секционированием
- BYTEA не гигабайт
- эффективное секционирование
- большое количество таблиц = стратегия вакуума
- большие поля - специализированный TOAST
- Wraparound (64бит!!!!)

== Как стать классным спецом по базам данных?
https://youtu.be/SpLVs6lfXps

DBA:
- Computer science
- soft skills
- development
- sql & Ko
- data science
- dba
- operations
- backend
- clouds

важно
- нормальные формы 1,2,3
- 2 phase locking
- deadlock detection
- MVCC
- write ahead log (WAL)
- писсимистические алгоритмы !
- RTFM

опционально
- реляционная алгебра
- нормальные формы 3+
- b-tree, B+, B*

подводные камни
- не путать 2pl и 2pc
- не противопоставлять 2pl и MVCC
- читайте доку по .conf
- keep calm
- dont tune the query !!!

==Redis Crash Course
https://youtu.be/jgpVdJB2sKQ

МАЛО!
- list
- set
- hash

== Redis Crash Course - the What, Why and How to use Redis as your primary database
https://youtu.be/OqCK95AS-YE

ЧУТЬ БОЛЬШЕ
- modules
- structures
- HA
- redis on flash
- scaling
- sharding

== What Happens When Redis Runs Out of Memory
https://youtu.be/W8IEzoxRMz4

неплохо однако

== How to develop if you are Senior or Lead?
https://youtu.be/WnVXljx5iVU

очень хорошо

== Что такое ceph "НЕ анатомия катастрофы" #1
https://youtu.be/D1FwD_mP2e0

оч давно было интересно на самом деле это так или нет

== Равно ли 80 км/ч и 80 км/ч в сумме 160 км/ч?
https://youtu.be/jirh3s0d2s0

== Как устроены базы данных
https://youtu.be/c4_5rqvmDFU

1) Слой доступа к данным
- универсальность
- оптимальность
- параллелизм
= Язык запросов
= транзакционность
2) слой хранения
- параллелизм
- эффективность
- надежность
= Сериализация
= Восстановление
3) железо
- надежность
- эффективность
= интеграция с ядрами ОС

Конкурентный доступ

ACID
- Изолированность транзакций
- Атомарность транзакции
- Консистентность транзакции
- долговечность (хранимость)

Как обеспечить
- блокировки на ресурс
- эффективные алггоритмы блокировок

Планировщик
- пессимистичный
- оптимистичный
- гибридный
- основнанные на упорядочивании таймстемпов транзакций

двухфайзное блокирование
- неизбежно возникнут дедлоки
- нужна система отстрела дедлоков
- медленно
+ обеспечена сериализация

MVCC
- что бы не ждать блокировку - возмем предыдущю версию, если что перечитаем заново (это быстрей чем ждать до конца)

WAL = Write Ahead Log
прежде чем ответ вернется клиенту все запишется в WAL/ если чтото пошло не так. то вычитаем предыдущую строчку из WAL

БД используюти страницы фиксированного размера - удобно для алгоритмов сериализации
- При записи вся страница помечается как грязная
- Если после этого сбой - теряем грязные страницы
- что бы можно было востановить после сбоя пишем WAL
- что бы WAL не рос бесконечно. БД имеет алгоритм чекпоинтов, когда все грязные страницы свопаются на диск

нашел неплохой подкаст по Базам данных и в частности много про Постгрес
https://www.youtube.com/c/RuPostgres/videos

== Секционирование таблиц PostgreSQL
https://youtu.be/eE9ZZc_oqQk