GitHub - thisroot/highload-architecture: stages of build highload systems

Архитектура высоконагруженных систем

Метрики качества
Проблемы нагрузок
Тестирование производительности
Индексы
Репликация
Шардирование
- 6.1 Общее
- 6.2 Vitess.io
Кеширование
Брокеры сообщений
Транзакции в РСУБД
In-memory СУБД

Метрики качества

Что мерять

rps, rpm - количество запросов в единицу времени
pps (packets per second), mps (megabytes ...) - количество данных в единицу времени
simultaneous connections, concurrency - количество одновременных соединений
latency - задержка ответа
throughput - пропускная способность системы (в хайлоад жертвуют latency ради этого)

Как мерять

Статистические величины (95, 99) - перцентили

Виды масштабирования

Вертикальное - увеличение мощности сервера
Горизонтальное - использование большего количества серверов

к оглавлению >>

Проблемы нагрузок

Переключение контекста

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

Сохранение регистров процессора
Сохранение общей информации pid, tid, uid, gid, euid, egid и т. д.
Сохранение состояния процесса/потока
Сохранение прав доступа
Сохранение используемых потоком ресурсов и блокировок
Сохранение счетчики использования ресурсов (например, таймеры использованного процессорного времени)
Сохранение регионов памяти, выделенных процессу
Очистка конвейера команд и данных процессора
Очистка TLB, отвечающий за страничное отображение линейных адресов на физические

Процессы и потоки

В системе linux процессы и потоки отличаются доступом к памяти. У потоков она общая

создание процесса

     clone(
         child_stack=0, 
         ags=CLONE_CHILD_CLEARTID |
             CLONE_CHILD_SETTID |
             SIGCHLD, 
         child_tidptr=0x7fa001a93a10) = 6916

создание потока

    clone(
      child_stack=0,
      ags=CLONE_VM|
          CLONE_FS|
          CLONE_FILES|
          CLONE_SYSVSEM|
          CLONE_SIGHAND|
          CLONE_THREAD|
          CLONE_SETTLS|
          CLONE_PARENT_S
      child_tidptr=0x7fa001a93a10) = 6916

Модели Веб серверов

worker (многопоточный)
prefork (многопроцессный)
синхронный (select)
async (асинхронный epol)
Комбинированные варианты

worker vs prefork

переключение контекста между потоками менее затратное
меньше потребление памяти
потоки сложнее синхронизировать

Блокирующие и неблокирующие системные вызовы

Блокирующие системные вызовы блокируют процесс (или поток) до того, как будут получены данные (часть данных). Во время блокировки процесс не потребляет процессорное время, но потребляет память. Чтение из сети может быть неблокирующим. В неблокирующем режиме чтение из сокета возвращает или ответ (хотя бы его часть), или сообщение, что данные еще не готовы. Чтение с диска может быть только блокирующим(*)

Apache - синхронный многопроцессный
Nginx - асинхронный многопоточный

Концепция Fiber

Асинхронный код - быстрый, потребляет мало памяти.
Асинхронный код - сложно писать.
Синхронный код - медленее, потребляет больше памяти.
Синхронный код - просто писать.

Обзор языков программирования

Perl
- Обычно работает внутри apache.
- Синхнронный язык с поддержкой тредов (редко).
- Есть библиотека AnyEvent (еще реже тредов)
- Есть библиотека для fiber
Php
- CLI SAPI - в качестве консольной команды php для запуска наших кронов и других cli-программ (Command Line Interface)
- apxs2 SAPI - в качестве модуля к apache2
- CGI SAPI - в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)
- FPM SAPI - Fast Process Manager, написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом
- Можно делать потоки, но редко используется.
Python
- Есть потоки.
- Есть fiber.
- Процесс с потоками в Python может утилизировать только одно ядро процессора
Node.js
- Асинхронный код.
- Строго однопоточный.
Go
- Концепция зеленых тредов.
- Умеет использовать столько ядер ЦПУ, сколько нужно.
- Ориентирован на микросервисы.
- Быстрый.

Трехзвенная архитектура

Frontend, Backend, Storage

Задачи frontend (reverse proxy)
- Терминировать ssl-соединения.
- Обработка медленных клиентов.
- Отдача статики.
- Keep-Alive.
- Кэширование.
- Балансировка.
- Роутинг по бэкендам
Задачи backend
- Бизнес-логика
- Ожидание ответов от хранилищ
Задачи хранилищ
Хранение информации
Быстрый поиск (индексы)
Обеспечение транзакционности (ACID)

Библиография

Node.js multithreading: What are Worker Threads and why do they matter? - LogRocket Blog https://blog.logrocket.com/node-js-multithreading-what-are-worker-threads-and-why-do-they-matter-48ab102f8b10/
Влияние Transparent Huge Pages на производительность системы https://habr.com/ru/company/tinkoff/blog/446342/
Is this explanation about VSS/RSS/PSS/USS accurate? https://stackoverflow.com/questions/22372960/is-this-explanation-about-vss-rss-pss-uss-accurate

к оглавлению >>

Тестирование производительности

Области

Администраторы, backend
- Быстрые ответы сервера
- Эффективное использование оборудования
Проектировщики интерфейсов, Frontend, Android, iOs
- Клиентская оптимизация, быстрая отрисовка
- Энергоэффективность
Аналитики
- Удобство использования
- Понятность бизнес-процесса, запоминаемость

Тестирование производительности

Подсисием серверов

нагрузка на диск

fio - flexible i/o tester https://github.com/axboe/fio

The following example benchmarks maximum write throughput:

     fio --ioengine=sync --direct=0 \
     --fsync_on_close=1 --randrepeat=0 --nrfiles=1  --name=seqwrite --rw=write \
     --bs=1m --size=20G --end_fsync=1 --fallocate=none  --overwrite=0 --numjobs=1 \
     --directory=/mnt/gcfs --loops=10

The following example benchmarks maximum write IOPS:

    fio --ioengine=sync --direct=0 \
    --fsync_on_close=1 --randrepeat=0 --nrfiles=1  --name=randwrite --rw=randwrite \
    --bs=4K --size=1G --end_fsync=1 --fallocate=none  --overwrite=0 --numjobs=80 \
    --sync=1 --directory=/mnt/standard --loops=10

нагрузка на процессор

Phoronix https://phoronix-test-suite.com/

 phoronix-test-suite benchmark smallpt
     Test Results:
         57.683207988739
         57.237819910049
         57.684161901474
     Average: 57.54 Seconds

нагрузка на сеть

iperf3 https://software.es.net/iperf/

    iperf3 -s
    iperf3 -c 192.168.1.66
    [ ID] Interval           Transfer     Bandwidth       Retr
    [  4]   0.00-10.00  sec  42.9 GBytes  36.8 Gbits/sec    0             sender
    [  4]   0.00-10.00  sec  42.9 GBytes  36.8 Gbits/sec

Cерверов приложений на простых запросах

Подать нагрузку на балансировщик
- httpperf, ab
Подать нагрузку на сервер баз данных
- sysbench (MySQL), pgbench (PostgreeSQL)
Подать нагрузку на сервер приложений
- curl, wget, ab
- на уровне TCP - tcpreplay

Приложений при выполнении сценариев

Производятся динамически связанные запросы к системе, связанные со сценариями пользовательской активности, с высокой интенсивностью

Самописные утилиты "Бешенный пользователь"
Функциональный тест без пауз в несколько потоков

В соответствии с требованиями

Производится точная нагрузка, в подходящее время, в нужном месте, с нужной силой, с анализом происходящего

Appache.JMeter - простые сценарии (Groovy, Java, JavaScript)
Gatling - сложные сценарии с десятками зпросов (Scala)
wrk - автоматизация на Lua
Yandex.Tank - единый отчет, масштабирование (Go, Pyhon)

Валидация результатов

Смоделировать нагрузку
Отладить мониторинг (для сравнения результатов теста с показателями мониторинга систем)
- TIG - Telegraph, InfluxDB, Grafana
- Prometheus - Telegraf, Prometheus, Grafana
- Zabbix - Zabbix, Grafana.
Сравнить со стандартами для оборудования

Виды тестиования производительности

Нагрузочное (load testing) - выполнение программы с повышением нагрузки от среднего профиля до максимального и выше
- подаем нагрузку ступенями, наращиваем количество операций в единицу времени ( выдержит ли система нагрузку, есть ли узкие места)
- выше максимума, чтобы знать есть ли запас
- ищем точку деградации и доступности (timeout, 504)
- сравниваем с профилем нагрузки (min, med, max)
- ищем узкое место, лимиты, в.т.ч конфигурационные
- необходимо понимание работы системы
- ищем точку появления ошибок под нагрузкой
- стараемся избавиться от ошибок и предупреждений
- их их отношения к профилю нагрузки (med, max)
- выбираем профиль для теста стабильности (80% от точки деградации)
Стабильности (stability testing) - длительное тестирование со средней нагрузкой, поиском отклонений и проверками корректности работы (что будет при эксплуатации 24/7, стабильна ли система под нагрузкой, как быстро растет размер базы данных, есть ли утечка соединений, нет ли потерь данных)
- не выше предельной, чтобы не было ошибок
- всю ночь или все выходные
- выполняются во время или между интерациями
- попадут в отчет по тестированию стабильности
Стрессовое (stress testing) - тестирование за пределами рабочих нагрузок в ограниченных ресурсах (если нагрузка ненадолго превысит максимум, освобождаются ли неиспользуемые ресурсы, восстановится ли система после ошибок, какие ошибки проявляются под нагрузкой)
- быстро и ненадолго повысим нагрузку и повторим такой процесс несколько раз
- Выявим утечку ресурсов, проверим корректность обработки исключений
- выявим утечку ресурсов, возможно, что ресурсы не освобождаются полностью
- возможно, что ресурсы не освобождаются частично
- быстро ли разбираются внутренние очереди системы
Обьемное (volume testing) - тестирование при увеличении обьемов данных (что будет через 5 лет работы, а если увеличить размер документов)
- сценарий через 1 год работы
- сценнарий через 5 лет работы
- сценарий через 10 лет работы
- нужен генератор баз данных и лучше его писать на SQL
- профиль нагрузки - размер пакета данных >
Масштабируемости (scalability testing) - серия нагрузочных тестов для разных профилей оборудования, количества серверов или узлов системы, настроек - размеров очередей, лимитов (поможет ли увеличение памяти в 2 раза, какой предел на другом железе, какая производительность на двух серверах)
- Наращивание мощьности оборудования вертикальное масштабирование
- Тестирование на разных конфигурациях для прогноза затрат
- Наращивание мощьности оборудования имеет технический предел
- Наращивание количества узлов горизонтальное масштабирование
- Наращивание количества узлов закладывается в архитектуру
- Наращивание количества узлов - дает гибкость

Генерация данных

Лучше всего использовать SQL для генерации данных
- высокая скорость генерации
- можно сгенерировать 100Гбайт
- не нужны интеграции
- SQL - может многое
API - гибкость и надежность
- генерация на активной системе
- быстрый отклик по корректировке

к оглавлению >>

Индексы

Большинство проблем с производительностью баз данных решается индексами

Ускоряют запросы
Позволяют делать constaints (UNIQUE, FOREIGN KEY)

Виды индексов

BTREE
RTREE
Hash
FULLTEXT

BTREE

умеет
- Поиск по равенству (а=5)
- Поиск по открытым диапазонам (а > 5 b a < 3)
- Поиск по закрытому диапазону ( 2 < f < 8)
не умеет
- Искать четные числа
- Искать суффиксы
для строк те же правила (Like то же работает с индексами)
- хорошо LIKE "a%", плохо LIKE "%c"

Типы индексов Mysql

InnoDB - указателем на данные для вторичного ключа будет значение первичного ключа (у любого индекса есть скрытый элемент индекса)
MyIsam - указателем на данные для ключа будет физическое смещение в файле

Особенности

Могут быть многоколоночными key(a,b,c)
- сравниваются по элементам массива
Индексы дорогая штука
- при записи данных происходит обновление индексов
- при чтении приходится анализировать больше индексов
Кластерный ключ - InnoDB - создает скрытый кластерный ключ, из PRIMARY_KEY или UNIQUE_KEY или создает самостоятельно
- если правильно задавать кластерный ключ,то можно достичь высокой степени локализации записей ( к примеру идентификатор комментария к посту, является конкатенацией идентификатора поста и своей части) это позволяет достичь хранения всех комменатиев рядом друг с другом, что ускоряет чтение

Зачем используются индексы

Поиск данных
Сортировка
Избежание чтения из таблицы (покрывающие индексы - covering indexes)
Специальные оптимизации

   USE db;
 
   CREATE TABLE tbl (
           id bigint(20) NOT NULL AUTO_INCREMENT,
           a bigint(20) NOT NULL,
           b bigint(20) NOT NULL,
           c bigint(20) NOT NULL,
           d bigint(20) NOT NULL,
           e bigint(20) NOT NULL,
           str VARCHAR(54) NOT NULL,
           PRIMARY KEY (id)
       ) ENGINE=InnoDB DEFAULT CHARSET=utf8

контейнер - data/docker-compose.yml
данные - mock-generate.py

Создание индекса

EXPLAIN SELECT a, b from tbl where a = 1;
type: all - полное сканирование

    +----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows  | filtered | Extra       |
    +----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------------+
    |  1 | SIMPLE      | tbl   | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 21460 |    10.00 | Using where |
    +----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+-------------+

создаем индекс CREATE INDEX a ON tbl(a);
EXPLAIN SELECT a, b from tbl where a = 1;

    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows  | filtered | Extra |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------+
    |  1 | SIMPLE      | tbl   | NULL       | ref  | a             | a    | 8       | const | 10730 |   100.00 | NULL  |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------+

type: ref

Покрывающий индекс

EXPLAIN SELECT a from tbl where a = 1;
Extra: Using index - все данные берутся из индекса

    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows  | filtered | Extra       |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+
    |  1 | SIMPLE      | tbl   | NULL       | ref  | a             | a    | 8       | const | 10730 |   100.00 | Using index |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+

Запрос с префиксами

EXPLAIN SELECT a, b from tbl where a = 1 and b = 3
запрос по индеску а, с дополнительным сканированием по b

    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows  | filtered | Extra       |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+
    |  1 | SIMPLE      | tbl   | NULL       | ref  | a             | a    | 8       | const | 10730 |    10.00 | Using where |
    +----+-------------+-------+------------+------+---------------+------+---------+-------+-------+----------+-------------+

CREATE INDEX a_b ON tbl(a,b);
EXPLAIN SELECT a, b from tbl where a = 1 and b = 3
составной индекс и запрос по соответствующим ключам позволяет получать данные покрывающим индексом

    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref         | rows | filtered | Extra       |
    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
    |  1 | SIMPLE      | tbl   | NULL       | ref  | a_b           | a_b  | 16      | const,const | 1000 |   100.00 | Using index |
    +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

Когда индекс применим

CREATE INDEX a_b_c ON tbl(a,b,c)
Хорошие запросы
- where a = 0
- where a > 0
- where a = 0 and b > 4
- where a = 0 and b = 2
- where a = 0 and b = 2 and c > 2
- where a = 0 and b in (2,4) and c > 3
Плохие запросы (индекс не работает,так как префикс а не используется)
- where b > 3
- where b = 6
- where b = 2
Частичное использование - префикс индекса работает с лева на право, до первого условия неравенства включительно
- a > 0 and b = 4
- a = 0 and b < 3 and c = 3
- a = 0 and b > 3 and c < 3

Индексы для сортировки

Хороший запрос
- SELECT * FROM tbl ORDER BY a LIMIT 10
- SELECT * FROM tbl WHERE a = 1 ORDER BY b LIMIT 10
- SELECT * FROM tbl WHERE a > 1 ORDER BY a LIMIT 10 - те же правила к сортировке что и к неравенству (это же сравнение)
- SELECT * FROM tbl ORDER BY a DESC, b DESC LIMIT 10 - сортировка должна быть однонаправленной
- SELECT * FROM tbl ORDER BY a ASC, b ASC LIMIT 10
Плохие запросы
- SELECT * FROM tbl ORDER BY b LIMIT 10
- SELECT * FROM tbl WHERE a > 1 ORDER BY b LIMIT 10
- SELECT * FROM tbl WHERE a in (1,2,3) ORDER BY b LIMIT 10 - в сортировке in не работает!!!
- SELECT * FROM tbl ORDER BY a ASC, d DESC LIMIT 10 - в новых версиях появились разнонаправленные индексы

Оптимизация агрегирующих функций

min и max - очень быстро работают по индексам, другие функции не ускоряются
CREATE INDEX a_str ON tbl(a, str)
SELECT a, max(str) from tbl GROUP BY a

Оптимизация JOIN

В MySQL используется метод nested loops, но с оптимизациями
JOIN должны быть по индексам

    SELECT * FROM posts WHERE author='Peter'
    JOIN comments ON posts.id = comments.post_id

Индекс по post_id - бесполезен
Индекс по comments.post_id - необходим

Index Merge

OR это плохая конструкция в запросе
Можно использовать два индекса, вместо составного

Префиксные индексы

можно составить индекс по префиксу строки, важна селективность

Хаки

between
- нельзя - SELECT * FROM tbl WHERE a BETWEEN 0 AND 5 AND b = 5
- можно SELECT * FROM tbl WHERE a IN (0,1,2,3,4,5) AND b = 5
фейковые фильтры - если надо использовать одно значение из составного индекса, можно включить весь первый
- SELECT * from tbl WHERE gender in('m', 'f') and city = 'Moscow' (index - gender_city)

сортировка

нельзя SELECT * FROM tbl WHERE a IN(0,1) ORDER BY b LIMIT 10
можно

    (SELECT * FROM tbl WHERE a = 0 ORDER BY b LIMIT 10)
    UNION ALL
    (SELECT * FROM tbl WHERE a = 1 ORDER BY b LIMIT 10)
    ORDER BY b LIMIT 10

к оглавлению >>

Репликация

Репликация - это копирование данных

один из способов масштабирования
можно использовать множество серверов для обработки запросов
не является backup

Зачем

Не помогает ускорить запись
помогает ускорить чтение
Помогает при падениях

Master-Slave

один источник данных
наиболее распространенный подход
относительно просто и понятно
отключить/включить реплику
мастер иногда крашится...

Master-master

нет единой точки отказа
постоянное время работы
легкий failover
нет консистентности (все обязательно поломается)
group replication?

Виды синхронизации

sync
- закомитили локально, закомитили удаленно (Postgres)
- сделанное изменения видные всем и везде
async
- закомитили локально, все (MySQL, Postgres))
- никаких гарантий на другом конце
semi-sync
- закомитили локально, получили ack (MySQL)
- доступно здесь, уже скопировано на другой конец

Репликация в MySql

Master:
- обрабатывает запросы
- делает транзакции
- пишет binary logs
- binlog dump thread (SHOW PROCESSLIST на мастере)
Slave:
- стягивает изменения с мастера, кладет в relay log
- читает данные из relay log и применяет изменения
- slave I/O thread (SHOW SLAVE STATUS на слейве)
- slave SQL thread

https://dev.mysql.com/doc/refman/5.7/en/replication-implementation-details.html

Форматы

statement based
- передаются сами запросы
- гоняется небольшое количество данных
- все запросы в логе
- UPDATE items SET enabled=1 WHERE time < UNIX_TIMESTAMP(NOW())-60 и все поломалось каждый запрос считается на каждой ноде https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html
row based
- передаются измененные строчки
- бинарный формат
- непонятны границы statementа
- его трудно читать
- before/after image
- Посмотрите на binlog_row_image: full, minimal, blob https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_row_image
mixed

https://dev.mysql.com/doc/refman/5.7/en/binary-log-setting.html

Фильтрация репликации

можно реплицировать данные частично
можно обогощать данные слейва
использовать осторожно!

Опции:

replicate_do_db, replicate_ignore_db, replicate_do_table... https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html

Позиционирование логов

binary log position (FILE NAME + OFFSET)
- mysql-bin.00078:44
- локальный для сервера
- обязательно разъедется!
GTID (SOURCE_ID:TRANSACTION_ID)
- 7F33BC78-56CA-44B3-5E33-B34CC7689333:44
- глобален, генерируется автоматически при коммите
- бесплатная трассировка
- простой slave promotion
- используйте его!
- https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html

Параллельная репликация

обычно используется однопоточная репликация всех данных
с MySQL5.6 можно реплицировать параллельно несколько баз данных
с MySQL5.7 можно реплицировать параллельно одни и те же таблицы

Полезные опции:

slave-parallel-workers
slave-parallel-type (DATABASE|LOGICAL_CLOCK)

https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html

Сценарий:

1 мастер, 3 слейва
первый реплицирует в 1 поток
второй реплицирует в 20 потоков
третий реплицирует в 100 потоков
вставка в 25 различных таблиц внутри одной базы в 100 потоков (sysbench)

https://www.percona.com/blog/2016/02/10/estimating-potential-for-mysql-5-7-parallel-replication/

Репликация в Postgrees - WAL

физические изменения страниц (значение в блоке 2564 равно 154)
сюда попадают абсолютно все операции
один журная на все

https://wiki.postgresql.org/images/a/af/FOSDEM-2015-New-WAL-format.pdf

Репликация в MySQL

есть binlog
у некоторых движков есть аналог WAL (InnoDB Undo/Redo Log)
с точки зрения MySQL - это разные логи!
нарушение абстракций (логгирование реализовано на разных уровнях программы)
MySQL пишет больше данных для репликации (~1.5 раза)

https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-logs.html

Логическая репликация

тот самый row based формат
работает с кортежами данных
не знает, как они хранятся на диске
CPU-bound, можно параллелить по процессорам
В Postgres10+ тоже есть - https://www.postgresql.org/docs/10/logical-replication.html

Физическая репликация

работает со страницами
slave = master байт в байт
Postgres WAL, InnoDB Undo/RedoLog - как примеры работающих со страницами
IO-bound, нет смысла параллелить

Групповая репликация

плагин начиная с версии MySQL5.7
по сути - синхронная репликация
нет концепта master-slave, скорее master-master
репликация между всеми нодами
single primary (по умолчанию)
кворум, умеет automatic failover
flow control (я что-то очень отстал)
лимит в 9 node

Можно попробовать групповую репликацю в докере:

https://mysqlhighavailability.com/setting-up-mysql-group-replication-with-mysql-docker-images/ Документация:
https://dev.mysql.com/doc/refman/5.7/en/group-replication.html Обзор, бенчмарки, сравнения:
http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

Транзакции

подготовить транзакию движком базы данных
записать транзакию в binary log
завершить транзакию в движке базы
вернуть ответ клиенту

Отставание репликации

В нормальной ситуации отставание достигает секунды.
- Плохие запросы (и по мастеру, и по реплике) могут вызвать отставание репликации.
Рекомендация:
- Убивайте медленные запросы.
- Держите отдельную реплику для медленных запросов.
- Думайте о кросс-СУБД репликации.
- Старайтесь избегать паттерна запись-чтение.

Чтение данных

свои данные читаем с мастера, чуижие со слейва
Монотонное чтение
- Ожидается, что пользователь не будет видеть пропадающие комментарии.
- Вариант - привязать пользователя к реплике.
Согласованное префиксное чтение
- Характерно для шардированных баз данных.
- Важно для сохранения причинно-следственных связей.

Конфликты репликации

Избегание конфликтов.
Last wins.
Ранг реплик. Выйгрывает запись от старшей реплики.
Слияние.
Решение конфликтов на клиенте.
Conflict-free replicated data types (CRDT).
Mergeable persistent data structures.

Безмастерная репликация

Предотвращение энтропии данных - Формула для расчета кворума: w + r > number of replicas

Литература

https://www.youtube.com/watch?v=ppI74hTuXO0
https://www.youtube.com/watch?v=_r8vLPTl0PE
https://m.habr.com/ru/company/oleg-bunin/blog/414111/
https://severalnines.com/database-blog/overview-logical-replication-postgresql
документация MySQL
документация Postgres
блог Percona

к оглавлению >>

Шардирование

Общее

Партицирование

берем данные и разделяем по какому-то признаку
разделенные данные физически лежат отдельно
все в пределах одного сервера!
бывает разных типов
в теории, должно работать быстрее (?)

Типы партицирования

key
range
list
hash

    CREATE TABLE members (
        firstname VARCHAR(25) NOT NULL,
        lastname VARCHAR(25) NOT NULL,
        username VARCHAR(16) NOT NULL,
        email VARCHAR(35),
        joined DATE NOT NULL
    )
    PARTITION BY RANGE( YEAR(joined) ) (
        PARTITION p0 VALUES LESS THAN (1960),
        PARTITION p1 VALUES LESS THAN (1970),
        PARTITION p2 VALUES LESS THAN (1980),
        PARTITION p3 VALUES LESS THAN (1990),
        PARTITION p4 VALUES LESS THAN MAXVALUE
    );

https://dev.mysql.com/doc/refman/8.0/en/partitioning.html

    CREATE TABLE measurement (
        city_id
        int not null,
        logdate
        date not null,
        peaktemp
        int,
        unitsales
        int
    ) PARTITION BY RANGE (logdate);
    CREATE TABLE measurement_y2006m02 PARTITION OF measurement
        FOR VALUES FROM ('2006-02-01') TO ('2006-03-01');
    CREATE TABLE measurement_y2006m03 PARTITION OF measurement
        FOR VALUES FROM ('2006-03-01') TO ('2006-04-01');

https://www.postgresql.org/docs/10/ddl-partitioning.html

Шардирование

один из вариантов масштабирования
разбиение данных на куски
данные живут физически на разных серверах (ну обычно так)
не репликация - !
не партиционирование - !

Зачем нужно шардирование

горизонтальное масштабирование
ускорить обработку запросов (особенно запись!)
повысить отказоустойчивость(*)

Выбор критерия шардирования

Key Based Sharding
- еще называют hash based
- формула примерно такая: F(key) -> shard_id
- F и key очень важны
- наиболее распространенный способ
- плюсы
  - просто и понятно (+)
  - равномерное распределение (+)
  - алгоритмическое распределение (+)
- минусы
  - добавление/удаление шарда всегда боль (-)

Range Based Sharding
- может называться table function/virtual bucket
- статический конфиг range -> shard
- формула примерно такая: hash(key) -> virtual_bucket -> shard_id
- плюсы
  - прост в реализации (+)
- минусы
  - потенциально неравномерная нагрузка (-)
  - обновление (-)
Directory Based Sharding
- похож на range based
- отображение key -> shard_id
- low cardinality для key - наш случай
- плюсы
  - гибкость (+)
- минусы
  - обновление (-)
  - SPOF (-)

Роутинг

из приложения (умный клиент)
- простой метод
- нет лишних хопов
- как обновлять/решардить?
прокси
- приложение вообще не знает о шардинге
- код не меняется
- лишний хоп (*)
- могут падать
- им нужно общаться
- https://www.proxysql.com https://shardingsphere.apache.org/document/current/en/manual/sharding-proxy
координатор
- приложение вообще не знает о шардинге
- код не меняется
- лишний хоп
- нагрузка
- SPOF

Проблемы шардинга

Плохо распределили данные
- подобрать лучший ключ/функцию шардирования
- решардинг (если имеет смысл)
JOIN
- держать нужные данные на одной машине
- делать вычисления на одной машине

Решардинг

В лоб:
- в худшем случае нужно перемешать все данные
- если степени 2ки - уже неплохо (переместить ~50%)
- Пример:
  - формула shard_id % count
  - 16 записей на 8 шардов => 2 записи на шард
  - 16 записей на 16 шардов => 1 запись на шард
Consistent hashing
- используем одну hash-функцию для нод и данных
- выбирается ближайший по часовой стрелке узел
- при добавлении/удалении затрагивается только часть
- формально не больше K/N (K-ключи, N-сервера)
- Данные могут быть распределены неравномерно.
Consistent hashing - Virtual Nodes
- помогает разделить данные более равномерно
- количество физических серверов не меняется

Шардирование и производительность запросов

запросы по ключу шардирования вероятно ускорятся
запросы не по ключу обойдут все шарды
запросы по диапазону ключей могут обойти все шарды
aggregating, joinы - отдельная тема

Было:

Total = Serial + Parallel

Стало:

Total = Serial + Parallel/N + Xserial

https://en.wikipedia.org/wiki/Amdahl%27s_law

Базы и шардинг

MySQL не умеет автошардинг (NDB ?)
Postgres умеет автошардинг (FDW)
Cassandra умеет автошардинг
MongoDB умеет автошардинг

    CREATE TABLE temperature (
        id BIGSERIAL PRIMARY KEY NOT NULL,
        city_id INT NOT NULL,
        timestamp TIMESTAMP NOT NULL,
        temp DECIMAL(5,2) NOT NULL
    );
    
    CREATE TABLE temperature_201904 (
        id BIGSERIAL NOT NULL,
        city_id INT NOT NULL,
        timestamp TIMESTAMP NOT NULL,
        temp DECIMAL(5,2) NOT NULL
    );
    
    CREATE EXTENSION postgres_fdw;
    GRANT USAGE ON FOREIGN DATA WRAPPER postgres_fdw to app_user;
    CREATE SERVER shard02 FOREIGN DATA WRAPPER postgres_fdw
        OPTIONS (dbname 'postgres', host 'shard02', port
        '5432');
    CREATE USER MAPPING for app_user SERVER shard02
        OPTIONS (user 'fdw_user', password 'secret');
    
    CREATE FOREIGN TABLE temperature_201904 PARTITION OF temperature
        FOR VALUES FROM ('2019-04-01') TO ('2019-05-01')
        SERVER remoteserver01;

Доп материалы

к оглавлению >>

Vitess.io

Система для горизонтального масштабирования MySQL
Обеспечивает read-tolerance и переключение мастер-баз в случае выхода мастера из строя

Умеет
- горизонтальное масштабирование(шардирование)
- пуллинг соединений
- кеширование запросов(удаление дублей)
- 2хфазный коммит(c недавнего времени)
- топология(при помощи consul, etcd, ZooKeeper)
- ACL на запросы
Не умеет
- last_inserted_id на шардированном кейспейсе: SELECT last_inserted_id() FROM user;
- distinct & функции агреггирования: SELECT DISTINCT a, COUNT(*) FROM user
- если используется группировка по полю, то поле должно обязательно быть написано в SELECT: SELECT a FROM user GROUP BY b;
- удаление по шардам с лимитом: DELETE FROM user LIMIT 10;
- Полный список: https://github.com/vitessio/vitess/blob/master/go/vt/vtgate/planbuilder/testdata/unsupported_cases.txt

CELL

- Cell — группа серверов и сетевой инфраструктуры, изолированной от аварий
в других cell(датацентр)
- Обычно, это или ДЦ или часть ДЦ, иногда называется “зона” или “зона
доступности”.

Keyspace

- Keyspace — логическая база данных
- Если используется шардирование, то кейспейс указывает на несколько
- MySQL баз данных, иначе на одну базу
- Чтение данных из кейспейса представляет собой чтение из MySQL

Keyspace graph

- Keyspace graph позволяет Vitess решать, какой шард использовать для 
конкретного запроса

Shard

- Shard — логическая часть внутри кейспейса. Обычно содержит один мастер
и много MySQL слейвов
- В конфигурации имеет следующий вид
- SHARD=-80, где -80 — это ключи [0x0, 0x80)
- Или же SHARD=80-, где 80- — это ключи [0x80, 0xff]

Tablet

- Таблетка — это комбинация процесса mysql и vttablet, запущенных на одной 
и той же машине.

Состояния Tablet

master — мастер-база
replica — слейв, который может быть продвинут до мастера
rdonly — слейв, который не может быть продвинут до мастера. Обычно, используется в качестве обработки background задач, дампа данных, тяжелых запросов
backup — база с остановленной репликацией
restore — база, в которую наливаются данные из бекапа.
drained — разезервированная база для background задач Vitess’a

Topology Service

Сервера, которые хранят данные о топологии и предоставляют
распределенный сервис блокировок
Например, etcd, ZooKeeper или Consul
- Роутит запросы
- Координирует таблеты между собой
- Хранит конфигурацию серверов

VSchema

Описание того, как данные лежат внутри кейспейсов и шардов. Чаще всего описывается JSONом, например

    { 
        "sharded": true,
        "tables": {
            "dinosaurs": {
            "column_vindexes": [
                {"column": "id", "name": "hash"}
            ]
        }
    }

Виды индексов в VSchema

hash — 3DES null-key hash
consistent_lookup_unique — хеш по уникальным значениям в таблице(primary key)
unicode_loose_md5 — md5 по ключу в таблице

https://vitess.io/docs/reference/vschema/ — полный список

vtgate

Прокси-сервер между пользователем и vttablet.
Общается с клиентом по MySQL протоколу
Общается с vttablet по gRPC

vtctl, vtctld

vtctl — CLI для администрирования vitess-кластера

vtworker

Занимается долгими задачами, например, решардингом

к оглавлению >>

Кеширование

Кэш или кеш(англ. cache, от фр. cacher — «прятать»; произносится [kæʃ] — «кэш») — промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удалённого источника, однако её объём существенно ограничен по сравнению с хранилищем исходных данных.

Принцип локальности

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

Для чатов - последние сообщения
Для новостей - последние новости
Для сервиса такси - активные заказы.

Алгоритмы вытеснения

Алгоритм Белади (идеальный алгоритм)
Least recently used (LRU)
Most Recently Used (MRU)
Псевдо-LRU
Least-Frequently Used
Adaptive Replacement Cache

Правило №1

Вы должны держать нагрузку без кеша. Задача кеша - ускорить ответ, а не держать нагрузку. Проводите учения. Убедитесь, что вы работаете без кеша.

Виды кешировния

Кеширование в браузере
Кеширование страниц (или блоков)
Кеширование данных базы

Кеширование в браузере

Кешируем только GET, ожидается, что GET - идемпотентен.

ETAG
If-Modified-Since
Cache-Control
LocalStorage

Кеширование в браузере инвалидация

Самый простой вариант - указывать версию в гет-параметрах. Еще более правильный вариант - делать название файла md5-суммой от содержимого.

Кеширование в Nginx

кеширование статичского контента
https://habr.com/ru/post/428127/

    proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m;
    map $request_method $purge_method {
        PURGE
        1;
        default 0;
    }
    server {
    ...
        location / {
        proxy_pass http://backend;
        proxy_cache cache_zone;
        proxy_cache_key $uri;
        proxy_cache_purge $purge_method;
        }
    }

Кеширование на сервере

Походы в базу данных могут быть достаточно дорогими. В этом случае, результаты запросов имеет смысл сохранять в кеш. Самыми распространенными вариантами являются:

Храниние данных в ОЗУ/shared memory
memcache
redis

redis vs memcache

Redis:
- Большое колличество команд
- Есть встроенный lua
- Сложный типы данных
- Есть персистентный режим
- Кластерный
- Сложный в настройках
Memcache:
- Простой
- Многопоточный
- Для кластерных конфигураций есть moxy.
- Tarantool поддерживает протокол memcache

Cache miss

AverageTime = DbAccessTime * CacheMissRate + CacheAccessTime

Пусть:

DbAccessTime = 100ms CacheAccessTime = 20ms
Тогда при CacheMissRate > 0.8 - кеш вреден!

Перестройка кеша (Thundering herd)

При отсутствии ключа есть большой риск перегрузить базу. Для избежания проблем с перегрузкой базы необходимо ставить локи. Хорошие пример - новая запись в блоге под высокой нагрузкой.

Получаем доступ к кэшу cache, его срок жизни истёк.
Пытаемся заблокироваться по ключу user_cache_lock.
Не удалось получить блокировку:
- ждём снятия блокировки;
Не дождались
- возвращаем старые данные кэша;
Дождались
- выбираем значения ключа заново, возвращаем новые данные (построенный кэш другим процессом).
Удалось получить блокировку:
- строим кэш самостоятельно.

Старт с холодным кешом

После аварии кеш, скорее всего будет инвалидирован. А в случае неперсистентных хранилищ кеша не будет точно при пропадании питания. Подняться с непрогретым кешом сложная задача. Общий рецепт:

Заранее напишите скрипт прогрева кешей
Возвращайте нагрузку плавно
Помните о правиле No1

Инвалидация кеша

Инвалидация по времени
- Указываем TTL
- После устаревание, автоматическое обновление
- Данные могут быть не консистентны при большом TTL.
- При малом TTL будет высокий cache miss.
Инвалидация по событию
- Удаляем данные из кеша при изменении в базе
- Опасно из-за риска мгновенной инвалидации.
Инвалидация по ключу
- Меняем данные в базе
- В ключ включаем версию
- Версию храним отдельно
- Старые версии протухают со временем
- Плюс - высокая консистентность.

Тегерирование ключей

    Версии тэгов:
        tag1 -> 25
        tag2 -> 63
    Кэш выборки:
    [
        срок годности: 2008-11-07 21:00
            данные кэша: [
            ...
    ]
        тэги: [
            tag1: 25
            tag2: 63
        ]
    ]

к оглавлению >>

Брокеры сообщений

Решаемые проблемы

Асинхронные ответы на долгие запросы
- построение отчетов
- аналитические, бухгалтерские запросы
Асинхронная обработка очереди запросов
Передача данных между приложениями, микросервисами

Решения

использование базы данных
- медленно, неэффективно
использование IPC, shared memory
- сложная реализация, блокировки
- отсутствие кластеризации
использование систем доставки сообщений
- Rabbitmq
- Kafka
- NATS
- Redis ( pub/sub, streams)

Требования к брокерам

Гарантия доставки сообщений
- at least once delivery
- at most once delivery
- exactly once
Порядок передачи сообщений
Управлению размером очереди (ограничение на передачу)
Зеркалирование
Масштабирование

протокол AMPQ

AMQP (Advanced Message Queuing Protocol) обеспечивает взаимодействие между клиентами и брокерами (промежуточным ПО для обмена сообщениями).

Протокол обеспечивает:
- Надежность доставки сообщений
- Высокую скорость доставки сообщений
- Подтверждение приема сообщений

Терминология AMPQ

Брокер – это приложение, реализующее модель AMQP, которое принимает соединения клиентов для маршрутизации сообщений и т.п.
Сообщение (message) – это единица передаваемых данных (включая полезные данные и атрибуты сообщения).
Потребитель (consumer) – приложение, которое получает сообщения из очередей.
Производитель (producer)– приложение, которое отправляет сообщения в очередь через обмен.

RabbitMQ

гарантия доставки сообщений
- at least once delivery
- at most once delivery
Гарантирует порядок передачи сообщений (FIFO)
Возможность сохранения на диск
Подтверждение отправки, подтверждение получения
Ограничение кол-ва отправляемых сообщение
Управление поведением неполученных сообщений
Кластеризация
Зеркалирование

Варианты взаимодействия

consume
pub/sub
роутинг / фильтрация
запрос / ответ

Терминология

Producer, consumer, message - (рассмотрели ранее)
Queue: Буфер который хранит сообщения
Connection: TCP соединение между приложениями и менеджером очередей
Channel: Виртуальное соединение внутри соединения. Когда вы публикуете или получаете сообщения через очередь – это все делается в канале.
Exchange: Получает сообщение от поставщика и отправляет его в очередь. Зависит от типа.
Binding: Связь между очередью и обработчиком сообщений
Routing key: Ключ на который смотрит обработчик и решает в какую очередь перенаправить сообщение
Users: Возможность подключится к брокеру сообщений с помощью имени пользователя и пароля.
Vhost, virtual host: Способ разделения приложений используя один и тот же экземпляр RabbitMQ.

RabbitMQ: Exchange

Сообщения публикуются в очередь не на прямую, вместо этого, поставщик шлет сообщение обработчику который отвечает за перенаправление сообщения в нужную очередь с помощью биндинга ключей роутинга.

Поставщик публикует сообщение в exchange: direct, fanout, topics, headers Exchange. Типы
Обработчик получает сообщение и отвечает за его перенаправление. Обработчик берет различные атрибуты, такие как, ключ роутинга, зависимость на тип обмена и другие.
Создается связь между обработчиком и очередью
Сообщение остается в очереди до тех пор пока не будет обработано получателем.
Получатель обрабатывает сообщение

Ключ маршрутизации — значение, которое указывается при публикации сообщения в точку обмена, служит для определения очередей в которые попадет сообщение.

Заголовок сообщения — набор аргументов вида ключ- значение связанных с сообщением.

Типы обработчика

direct — сообщения попавшие в эту точку обмена будут скопированы только в те очереди, которые связаны с точкой обмена строгим ключом маршрутизации.
fanout — сообщение поступившее в точку обмена копируется во все привязанные очереди, без проверки ключа маршрутизации или заголовка сообщения.
topic — ключ маршрутизации может быть составным, и задаваться в виде паттерна, для чего существуют два специальных символа: * — обозначает одно слово, # — одно или несколько слов. Слова разделяются точкой. Пример: routingKey = "*.database"
headers — очередь связывается с обработчиком по заголовку сообщения, указывается условие, какие аргументы и их значения ожидаются

Флаги очередей

auto_delete — если очередь пустая и к ней нет активных подключений, очередь автоматически удаляется
durable — устойчивая очередь, сообщения не теряются при рестарте rabbitMQ (или внезапной перезагрузке), при публикации и до окончания отдачи хранятся в базе данных
exclusive — очередь предназначена для не более чем одного подключения единовременно
passive — при объявлении очереди пассивной, при обращении клиента сервер будет считать что очередь уже создана, т.е. не будет автоматически создавать ее в случае отсутствия, этот вариант нужен если вы хотите обратиться к серверу не изменяя его состояние.
internal - очередь между exchanges

Кластер

Синхронизировать /var/lib/rabbitmq/.erlang.cookie
- rabbitmqctl stop_app
- rabbitmqctl join_cluster --ram rabbit@master
- rabbitmqctl start_app
По умолчанию очереди не синхронизированы!
- Включение зеркалирования очередей
  - # rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

Память

По-умолчанию, в случае если RabbitMQ начинает использовать больше 40% от общего объема памяти, то все соединения блокируются. При высвобождении памяти до требуемого уровня нормальный процесс работы RabbitMQ возобновляется. Порог используемой памяти можно переопределить: rabbitmqctl set_vm_memory_high_watermark 0.5 или перманентно в /etc/rabbitmq/rabbitmq.config

    [{rabbit, [{vm_memory_high_watermark, 0.5}]}].

Apache Kafka

Kafka — это
- распределенный
- реплицированный
- журнал фиксации изменений (commit log).

Характеристики

Гарантия доставки
Репликация журнала и синхронизация реплик
Уведомление о смещении(offset) получателя
Уведомление о получении сообщения для продюсера
хранит свои записи на диске и ничего не держит в -оперативной памяти
- Операции считывания и записи выполняются за постоянное время O(1)
Последовательное чтение и запись на диск
Использует кэш диска
API для producers/consumers
поддержка KSQL
Consumer через pull запрашивает о появлении новых сообщений
Журнал очищается на основе настроек времени и размера
Есть возможность сжатия журнала
Есть возможность сдвига смещения для переигрывания приема сообщений
Для хранения метаданных используется zookeeper, в последних версиях отдельные топики kafka

Терминология

Record – Запись, состоящая из ключа и значения
Topic – категория или имя потока куда публикуются записи
Producer – процесс публикующий данные в топик
Consumer – процесс читающий данные из топика
Offset – позиция записи
Partition – шард топика

Consumers и партиции

Кластер - Zookeper

Zookeeper – это распределенное хранилище ключей и значений. Оно сильно оптимизировано для считывания, но записи в нем происходят медленнее. Применяется для хранения метаданных и обработки механизмов кластеризации (hearbeat, распределенные операции обновления, конфигурации, т.д.).
- Offset групп потребителей в рамках секции
- ACL — используются для ограничения доступа /авторизации
- Квоты — максимальные предельные количества сообщений в секунду
- Partition Leaders и уровень их работоспособности

к оглавлению >>

Транзакции в РСУБД

ПО или аппартное обеспечение могут отказать в любое время
В любой момент может произойти фатальный сбой ПО
Может случиться разрыв сети
Клиенты работают с базой параллельно, могут перезаписывать друг друга
Клиенты могут читать частично обновленные состояния

Транзакции

Транзакция — способ группировки приложением нескольких операций записи и чтения в одну логическую единицу. По сути, все операции записи и чтения в ней выполняются как одна: вся транзакция или целиком выполняется успешно (с фиксацией изменений), или целиком завершается неудачно (с прерыванием и откатом). Появились в середине 1970-х, с тех пор не сильно менялись. В NoSQL от них часто отказываются.

ACID

Atomicity: Атомарность означает "все или ничего". Гарантирует, что либо все операции транзакции будут успешно применены, либо не будет применена ни одна из них. Благодаря этому появляется возможность повторять прерванные транзакции, не опасаясь что часть операций уже была выполнена.
Consistency: Определяются инварианты системы: ( Дебит должен сходится с кредитом, Цена проданных билетов должна соответствовать выручке за сеанс.)
- В реальность означает только то, что constaints будут выполнятся.
- По сути, поддержание согласованности - задача приложения, а не базы.
Isolation: Изоляция - свойство, которое позволяет выполнять параллельные транзакции как последовательные. Существует несколько уровней изоляции, которые дают различные гарантии. В полном смысле изоляцию обеспечивает только уровень SERIALIZABLE.
Durability: Под этим свойством подразумевают только одно - данные при отдаче ответа зафиксированны в энергонезависимой памяти (fsync). Полностью это свойство обеспечить невозможно. Диски сбоят. Но можно повышать (репликация) гарантии.

Атомарные операции

Многие NoSQL базы, хоть и не поддерживают транзакции, обладают возможностью атомарных операций. Для memcached это:

inc
dec

Аномалия dirty reads

Чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится).

Аномалия dirty writes

Аномалия lost update

при одновременном изменении одного блока данных разными транзакциями теряются все изменения, кроме последнего;

Аномалия Unrepeatable read

Ситуация, когда при повторном чтении в рамках одной транзакции ранее прочитанные данные оказываются изменёнными.

Аномалия "Фантомное чтение"

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

Уровни изоляции

Под «уровнем изоляции транзакций» понимается степень обеспечиваемой внутренними механизмами СУБД (то есть не требующей специального программирования) защиты от всех или некоторых видов вышеперечисленных несогласованности данных, возникающих при параллельном выполнении транзакций. Стандарт SQL-92 определяет шкалу из четырёх уровней изоляции: Read uncommitted, Read committed, Repeatable read, Serializable. Первый из них является самым слабым, последний — самым сильным, каждый последующий включает в себя все предыдущие.

Read uncommitted (чтение незафиксированных данных)

Низший (первый) уровень изоляции. Он гарантирует только отсутствие потерянных обновлений. Если несколько параллельных транзакций пытаются изменять одну и ту же строку таблицы, то в окончательном варианте строка будет иметь значение, определенное всем набором успешно выполненных транзакций. При этом возможно считывание не только логически несогласованных данных, но и данных, изменения которых ещё не зафиксированы.

Read committed (чтение фиксированных данных)

Большинство промышленных СУБД, в частности, Microsoft SQL Server, PostgreSQL и Oracle, по умолчанию используют именно этот уровень. На этом уровне обеспечивается защита от чернового, «грязного» чтения, тем не менее, в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных.

Покрывает аномалии
- dirty reads
- dirty writes
Реализация:
- Блокировка строк при записи
- Сохраняем после записи старые значения строк до коммита изменений.

Repeatable reads

Уровень, при котором читающая транзакция «не видит» изменения данных, которые были ею ранее прочитаны. При этом никакая другая транзакция не может изменять данные, читаемые текущей транзакцией, пока та не окончена.

покрывает
- unrepeatable reads
реализация
- Блокировки (чтение не блокирует запись, а запись не блокирует чтение)
- MVCC
  - В начале каждой транзакции база данных создает список всех остальных выполняемых на текущий момент транзакций (но еще не зафиксированных или прерванных). Все выполненные этими транзакциями изменения игнорируются, даже если впоследствии они будут зафиксированы.
  - Все операции записи, выполненные прерванными транзакциями, игнорируются.
  - Все операции записи, выполненные транзакциями с более поздним идентификатором транзакции (то есть начавшиеся после запуска текущей транзакции), игнорируются независимо от того, были ли они зафиксированы.
  - Результаты всех остальных операций записи видны запросам приложения.

Serializable (упорядочиваемость)

Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга, каждая выполняется так, как будто параллельных транзакций не существует. Только на этом уровне параллельные транзакции не подвержены эффекту «фантомного чтения».

покрывает
- фантомное чтение
реализация
- последовательное выполнение
- двухфазная блокировка (2-Phase Lock)
- методы оптимистического управления конкурентным доступом

Параллельное выполнение

Пример - tarantool, redis.
Хорошо подходит для In-Memory баз данных. Крайне рекомендуется использовать шардинг (но кросс-шард запросы надо синхронизировать).
Есть комбинированное решение. OLAP - выносится в отдельные потоки выполнения с MVCC.

к оглавлению >>

In-memory СУБД Tarantool

Ускорение работы
Избегаем проблем кешей
Экономия денег
Горизонтальное масштабирование
Полноценный lua application server

Когда не использовать

Хранение логов
Аналитические запросы
Тяжелые запросы

Терминология

space - таблица
tuple - строка таблицы

Создание space

box.schema.space.create('myspace', {if_not_exists=true})

Создание индекса

box.space.myspace:create_index(
    'primary', {
        type="TREE", 
        unique=true,
        parts={
            1, 'unsigned', 2, 'string'
        }, 
        if_not_exists=true
    })

Параметры индексов

type - тип индекса: TREE, HASH, RTREE, BITMAP
unique - уникальность индекса
parts - индексные поля. Важно - можно использовать префикс индекса

Вставка данных

        > box.space.myspace:insert({"test", 3, 6})
        ---
        - error: 'Tuple field 1 type does not
        match one required by operation: expected unsigned'
        ...
        > box.space.myspace:insert({1, 'qwerty', 6})
        ---
        - [1, 'qwerty', 6]
        ...
        > box.space.myspace:insert({1, 10, 6})
        ---
        - error: Duplicate key exists in unique index
        'primary' in space 'myspace'
        ...
        > box.space.myspace:insert({2, 10, 6})
        ---
        - [2, 10, 6]
        ...
        > box.space.myspace:insert({3, 10, 6, 98})
        ---
        - [3, 10, 6, 98]
        ...

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

Изменение данных

    > box.space.myspace:update({2}, {{'+', 3, 1}})
    ---
    - [2, 10, 7]
    ...
    > box.space.myspace:update({2}, {{'+', 3, 1}})
    ---
    - [2, 10, 8]
    ...
    > box.space.myspace:update({2}, {{'+', 3, 10}})
    ---
    - [2, 10, 18]
    ...
    > box.space.myspace:update({2}, {{'-', 3, 3}})
    ---
    - [2, 10, 15]
    ...
    > box.space.myspace:update({2}, {{'=', 3, 148}})
    ---
    - [2, 10, 148]
    ...

Важно: менять можно только по уникальному индексу.

SELECT

    box.space.myspace:create_index('tindex', {type="TREE", parts={3, 'unsigned'}, unique=false})
    box.space.myspace:create_index('hindex', {type="HASH", parts={1, 'unsigned'}})
    box.space.myspace:select({}) box.space.myspace.index.tindex:select({}) box.space.myspace.index.tindex:select({148})
    box.space.myspace.index.tindex:select({148}, {iterator='GT'}) box.space.myspace.index.tindex:select({148}, {iterator='GE'})
    box.space.myspace.index.hindex:select({3}, {iterator='GE'})

Другие операции

replace
delete
upsert

Хранимые процедуры

    function myproc(id)
        local tup = box.space.myspace.index.tindex:select({id}, {iterator='GE'})
        return tup[2]
    end

Переключение контекста

Не забывайте, что тарантул однопоточен.
Тарантул передает управление сам при:
- Модифицирующих операциях
- Блокирующих системных вызовах
select не передает управление
- Во время долгих циклов пользуйтесь fiber.yield()

Транзакции

Начало транзакции - box.begin()
Откат транзакции - box.rollback()
Подтверждение транзакции - box.commit() Важно: блокирующие операции откатывают транзакцию автоматически

Практика

Изучаем сервис профилей Почта@Mail.ru

https://github.com/mailru/tntlua/blob/master/pro le17.lua

Репликация mysql <-> tarantol

к оглавлению >>

Шардирование

к оглавлению >>

Name		Name	Last commit message	Last commit date
Latest commit History 15 Commits
data		data
img		img
.gitignore		.gitignore
README.md		README.md

thisroot/highload-architecture

Folders and files

Latest commit

History

Repository files navigation

Архитектура высоконагруженных систем

Метрики качества

Что мерять

Как мерять

Виды масштабирования

Проблемы нагрузок

Переключение контекста

Процессы и потоки

Модели Веб серверов

worker vs prefork

Блокирующие и неблокирующие системные вызовы

Концепция Fiber

Обзор языков программирования

Трехзвенная архитектура

Библиография

Тестирование производительности

Области

Тестирование производительности

Подсисием серверов

Cерверов приложений на простых запросах

Приложений при выполнении сценариев

В соответствии с требованиями

Валидация результатов

Виды тестиования производительности

Генерация данных

Индексы

Виды индексов

BTREE

Типы индексов Mysql

Особенности

Зачем используются индексы

Создание индекса

Покрывающий индекс

Запрос с префиксами

Когда индекс применим

Индексы для сортировки

Оптимизация агрегирующих функций

Оптимизация JOIN

Index Merge

Префиксные индексы

Хаки

Репликация

Зачем

Master-Slave

Master-master

Виды синхронизации

Репликация в MySql

Форматы

Фильтрация репликации

Позиционирование логов

Параллельная репликация

Репликация в Postgrees - WAL

Репликация в MySQL

Логическая репликация

Физическая репликация

Групповая репликация

Транзакции

Отставание репликации

Чтение данных

Конфликты репликации

Безмастерная репликация

Литература

Шардирование

Общее

Партицирование

Типы партицирования

Шардирование

Зачем нужно шардирование

Выбор критерия шардирования

Роутинг

Проблемы шардинга

Решардинг

Шардирование и производительность запросов

Базы и шардинг

Доп материалы