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
Media is too big
VIEW IN TELEGRAM
Нормальные формы баз данных

В этом ролике автор рассматривает процесс нормализации баз данных и разбирает для чего он нужен. Вы узнаете что такое нормальная форма и какие формы существуют.

00:00 Введение
01:20 Что такое нормализация
02:08 Что такое избыточность данных с примерами
04:51 Какие бывают нормальные формы БД
08:00 Ненормализованная форма
09:37 Первая нормальная форма
11:24 Вторая нормальная форма
15:29 Что такое декомпозиция
16:18 Третья нормальная форма
18:54 Нормальная форма Бойса-Кодда
21:54 Четвертая нормальная форма
27:45 Почему обычно не нормализуют до 5 или 6 формы
29:14 Пятая нормальная форма
35:39 Шестая нормальная форма
38:02 Выводы и заключение

Смотреть это видео на youtube: youtu.be/zqQxWdTpSIA
== Топ ошибок со стороны разработки при работе с PostgreSQL
https://youtu.be/HjLnY0aPQZo
- планирование
- мониторингг

OLTP+OLAP = HTAP =)

foreign tables !!!

мониторить долгие транзакции. все что больше 20 мин надо автоматом резать ! таблицы начинают медленней работать

очереди можно строить на основе pgQ

автоматизация:
- SplitBrain
- Cascade Failover
про ошибки проектирования

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

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

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

F-sync через ядро ОС гостя, через фс ОС, дойти до ядра ОС, потом до ОС хоста, и тп...
== Основы мониторинга 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 !!!