== Энтерпрайзные вызовы для 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

== Архитектура платежной системы: почти enterprise
https://youtu.be/wMcWo2cT7Ck
ДАЙОЖ ПЛЭЙН ЖСОН!!!
(на самом деле нет)

== Digital Modulation
https://pysdr.org/content/digital_modulation.html
- ASK
- PSK
- QAM
- FSK

== Зачем нужен мультимастер?
https://youtu.be/bcRo--JlR14
- Oracle RAC (не совсем м-м реплика, сторадж всеже один)
- Postgres XC/XL
- Postgres BDR (репликация через WAL, малые понятные данные)
- Postgres Slony (репликация на триггерах) - более надежен

простой инсерт скейлить не проблема. а вот проапдейтить - это сложней

СЛУЧАЕВ КОГДА ИСПОЛЬЗОВАНИЕ МУЛЬТИМАСТЕРА ВМЕСТО hoststandby ОПРАВДАННО - ИСЧЕЗАЮЩЕ МАЛО

== Cautious: IPv6 is here
https://youtu.be/UIpm7FTpreA

- ipV4 или IPv6 лучше ? НЕКОРРЕКТНО !!! невозможно замерить
- какой протокол надежней ? ПОКА ipV4
- кто победит ? MPTCP

тема клевая. а доклад так себе
== Принципы и приёмы обработки очередей
https://youtu.be/CvT1v7xiRS0

== Использование очередей асинхронных сообщений с PostgreSQL
https://youtu.be/EHABzlUYOZk

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

== Пишем свой протокол поверх UDP
https://youtu.be/1Ih0bL2Zp1c

== Игровой сервер: что там внутри?
https://youtu.be/YxLxSNNEqk0
- postgres
- kafka
- hazelcast
- vert.x = reactor template (queue + eventloop)
- prometheus + graphana
- hadoop

про проблемы в сетях и перегрузки

== Тюнинг параметров TCP-соединений в высокоскоростных сетях
https://youtu.be/F0Zif5Enbgc

планировать сеть очень сложно. никто об этом не задумывается

есть всегда опасность каскадной деградации сервиса

сейчас все сети перегруженные. современный мир =(

MICROBUURST
- взрывной характер трафика на уровне милисекунд. и пакеты не влазят в пропускную способность

механизм медленного старта

аппаратный буфер сетевого оборудования
- сохранить тело пакета
- скгладить поток пакетов до скорости выходного интерфейса
- контролировать нагрзуку

у каждого интерфейса есть очередь отправки. память конечна
- что бы сохранить все пакеты на скорости 1ггб в сек нужен 25мб. для 10ггб = 250 мб. НЕ ВСЕ ТАК УМЕЮТ
- фильтруем трафик. QoS

Причины перерегрузок
- трафик переходит в мене скоростной интерфейс
- трафик с нескольких входрящих портов должен попасть в один исходящий Downlink-Backpressuer
- прочие типы burst-трафика
- Incast

перегрузка это норма

Incast
- очень часто появляется в распределенных системах (ceph, hadoop, hdfs...)
- все данные что не влезли в коммутатор - будут дропнуты
- ЭТО ПАДЕНИЕ пропускной способности TCP по мере того как коммутаторы не успевают буферизировать все и TCP начинает троттлить и появляются задержки в 200мс

Решение Incast
- большие буфера коммутатора
- управление потоком
- уменьшение номинального RTO TCP

RTO это значение ожидания при котором мы считаем что пакет потерялся в TCP. много плохо и мало плохо

сликом малый RTO - это много повторов

слишком много RTO - это медленные реакции на потери