BufWriter<Master<'_>> – Telegram
BufWriter<Master<'_>>
105 subscribers
451 photos
28 videos
34 files
1.7K links
https://www.patreon.com/alxe_master

Видео/статьи. Конспект и мои вольные комментарии по инженерии. тут только то, что считаю полезным для себя или других =)

#os, #cloud, #rust, #golang, #python, #javaScript, #cpp, etc
Download Telegram
== Основы мониторинга 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 Vacuum
https://youtu.be/TDWC66qzxCs

MVCC - multiversion concurency control

- всегда включен автовакуум!
- надо тюнить настройки!
- врапэраунд не страшен!
- вакуум не всегда может вычистить таблицу
- избегайте длинных транзакций
== Энтерпрайзные вызовы для 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 !!!
== Как устроены базы данных
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
== Digital Modulation
https://pysdr.org/content/digital_modulation.html
- ASK
- PSK
- QAM
- FSK