Databases
Feedback о курсе: - много текста на слайдах - люди сначала читают - перечитывать что написанно нет смысла)
Books:
- 7 databases 7 weeks - https://www.amazon.com/Seven-Databases-Weeks-Modern-Movement/dp/1934356921
- современные операционные системы
- High performance MySQL - https://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/1449314287
По базам
понятие repeatable-read - когда во время чтения все фризится когда он вЫключен - какая-то таблица может обновляться в пределах транзакции, пока к ней не обратятся Но как все реально будет работать, зависит еще от того, как вы стартуете транзакцию Если у вас не транзакционная база - то это все не работает :) Собственно транзацции происходят в режиме copy-on-write по памяти
MySQL:
- пересчитывает индексы в момент первого SELECT
- поэтому если хотим скопировать - надо закрыть и на запись, и на чтение
- Можно использовать blackhole движок для разгрузки мастера
- тогда мастер пишет только бинлог
- слейвы пишут данные
- только надо чтобы изменение движка не среплицировалось на slave
- можно сделать для отдельной таблицы
- и только если с мастера не читают
- Выдачу прав юзера лучше делать тоже только через мастер и пусть он реплицирует на slave
- Движок innodb при удалении данных из базы не удаляет по факту с диска. Лечится alter table
- Фактически innodb растет бесконечно
Casandra
- Синкает бин-лог
- При старте сравнивает последний дамп и бин-лог, и то, что не было задамплено - доливает.
- Может находится в различных точках CAP соттношения в различное время(availability/consistency/partion tolerance)
- Использует протокол Glossy(сплетница)
- При рассинхроне времени клатер уйдет в офлайн
- Уровни записи и чтения:
- 1
- Q (quorum)
- A (all)
- можно делать Q write and Q read
- или A write and 1 read
Vertica
Колоночная Бесплатная до 1Tb (который по факту может быть меньше 500 Gb данных) Ппц как закрытая
Graphite Whisper
Может упираться в количество файлов на диски, которые он генерит Можно подменить файлы на что-то типа clickhouse метрики идут по UDP, поэтому могут не дойти Хорошо подходит для общего мониторинга Легче чем prometeus или InfluxDB
Prometeus, InfluxDB
Хорошо подходит для тех метрик, которые одни и теже и не меняются
Redis:
- setup OVERCOMMIT=1
Mongo:
- явно mongo.dump может не отработать
- можно сделать полный replica-set базы и сделать слепок с него
- или одна коллекция в один часть(но могут получится расхождения)
- можно посмотреть на роутер mongos
Clickhouse
- для метрик
- база сама по себе “развернута”
- колоночная база хранит время апдейта каждого столбца/поля?
Consul DataBase
Rabbit MQ как хороший messanger router
Наша хранилка
Разбивать на несколько рейдов, что бы мониторить нагрузку на каждый диск Для файлопомойки использовали ребята честный ZFS with Solaris NGinx -> прослойка -> файловая система Push и Pull модель Torrent с анонсером для синхронизации
SysCalls:
железка <- драйвер <- core Core выдает API SysCall:
- open
- write
- lseek
- etc.
lseek: проблема заключается в том, что мы должны не просто сдвинуться, но и выяснить место, куда надо сдвинуться. Т.е попутно мы еще много раз вызываем read, что бы найти свободное место.
Чем меньше ядро обращается к железу, тем лучше.
Практические аспекты
Соотношение скорости и надежности. Highload - когда мы не можем решить проблему стандартными подходами(в частности железом)
В общем современные данные состоят из: - файл с логом операций - собственно данные - различные индексы
Индекс позволяет узнать сразу куда сделать seek, что позволяет сделать его единожды.
Все взаимодествие между пользователем и базой(и на read и на write) проходит через оперативную память
Проблема репликаций баз, в слечае когда одна база отвалилась от сети, но что-то продолжает с ней работать. Поэтому получается сложно определить в случае двух нод, кто прав. Можно использовать какой-то подход 3й реплики или арбитра. Правило 2n + 1
- Разные логические блоки можно держать вообще в отдельных базах(
- например таблицы users и messages живут вообще в различных базах
)
При дебаге - надо знать что и откуда приходит. Хорошая практика - имень скрипт, который умеет лочить все порты кроме 22. И востанавливать все порты обратно.
Не завязывайся на “серую”(локальную) сеть.
Если у вас есть несколько баз данных - расселите их сразу на два отдельных процесса. Вы даже можете использовать одну визическую железку - но виртуально хранить отдельно. Когда придется разносить - к этому будете готовы и вы и разработчики.
Синхронная раздача connection strings?
“Хождение через океан” надо закладывать на уровне архитектуры еще на этапе разработке(очереди)
Приложение которое по сигналу (например SIGHUB) будет переинициализировать пулл коннектов к базе - будет невероятно круто
Открытый tcp-dump по ssh - это хуже чем забытый дома утюг
Удаление файла, с которым что-то работает не освободит место на диске, если дескриптор в пользующей программе не был закрыт.
Join не позваляет в будущем настроить шардинг. В зависимости от того, будет ли расти объем данных и придется ли поднимать шардинг на разных серверах.
Последовательная запись vs. произвольная запись
-
strace: трасировщик
- Но не подключайтесь на проде, ибо это это дорого и нагружает базу данных
-
strace -ff -e lseek -p pidof mysql
- Вообще можно подключаться не только к базам, но и к другим процессам. Например ssh
https://wiki/File_descriptor#Operations_on_file_descriptors
Золотое правило реляционных баз данных - индексы и файлы с данными(одна нода) не должна весить более 200GB
Файлы с данными и AOF (binglogs, append и event логи)
Бинлоги можно читать глазами Бинлоги должны бить длинее чем бекап. Обычно - в дна раза длинее чем время бекапов. Иначе, мы просто не сможем востановить бекапы. Хорошая практика - ежедневная развертка бекапов для каких-то тестовых задач.
Денормализация
- query driven development
- 12 правил кодда - https://ru.wikipedia.org/wiki/12_%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB_%D0%9A%D0%BE%D0%B4%D0%B4%D0%B0
- Денормализация (вики)
Анализ performance issues
- apt-get install sysstat iotop iftop
- cat /proc/cpuinfo
- top (and press 1) (разделить по ядрам)
- iostat -dx 1 (%util - колонка работы с диском)
- iotop - top для дисков
- iftop -i eth0 - мониторинг сети
By default сетевые карты(даже многокональные) - биндятся на 0е ядро. Можно настроить нормально и поднять производительность.
Память
- Resident set size (RSS)
- виртуальная память (VM)
- copy-on-write method (позволяет копировать, но при этом использовать сходные части)
- free -h (buff/cache)
- Потеря page cache при потере питания
- Вымывание page cache
Комманды - netstat -tulp - lsof -p PID (процессы, порты и файлы что юзает) процесс - type redis-server (similar to which) - ldd /usr/bin/redis-server (list used external libraries) - sysctl - configure kernel parameters at runtime
- sysctl -a
Если вы что-то запишете в файл и сразу отключе питание - то файл не запишется. Ибо syscall sfync просто не успеет отработать(не случится физическая запись как таковая)
Забитая память быстрее вымывает кеши -> чаще вызывает fsync() и пишет на диск
Итого запись в файл:
База -> кеш -> page cache -> raid cache -> контролер -> и наконец, физическая запись
Процессорное время, переключение контекста
TODO: посмотреть как и что можно смореть через TOP Ядро видит FUSE как приложение FUSE из-за этого добавяет дополнительное хождение vmstat -s - показывает переключение контекста (IRQ cpu ticks) vmstat -m | less
Swap
Swap есть смысл включать, если при алерте вы готовы изолировать базу и дать свопу рассасаться. Иначе - просто нет смысла. База все равно умрет, просто через какое-то время.
Summary
Мониторьте все что можно Диски - %util Память - мониторить размер page cache и сколько осталось Процессор - мониторить idle Для каждой базы - мониторьте свои важные метрики, наприиер - inno_db - транзакционная глубина(самое большое значение) Отставание репликаций
не особо важно - deploy, monitor - в чат Важное - на звонилку (https://cloud.google.com/spanner/, https://www.pagerduty.com/)
Аппаратная составляющая
Скорость RAID масива меряется по скорости самого медленого диска. У баз есть Hardware compatible list - его можно использовать что бы понимать на чем быстрее и лучше работает. Тем более для новых баз. А то будет как инструкция к салату “Шуба” Если не мониторить состояние дисков - то при подмене и восставлении диска в рейд - можно добить выжившие
Кластеризация и репликация & Топологии репликации
Если есть две ноды - то лучше это закольцевать, а не просто сделать master -> slave Можно делать фильтрации, что надо реплицировать, а что нет
- Пример с сырой статистикой, которые не реплицируются, а агрегируются скриптами, а потом уже записываются дальше
Мастер-мастер и мульти-мастер
- MySQL после рассинхрона не съедется
- Пример одного Я поисковика и системы звонков
Galera claster - медленно, но надежно
Балансировка между нодами клстера
Локальный HAPproxy на каждой машине - это круто. Тем более он поддерживает замену ip-шников Позволяет на гарячую подменить мастер. Просто закрыв networking на местер - тогда HAProxy автоматически все переведет на slave.
Тюнинг индексов
128 GB оперативки стоят дешевле чем хороший DBA, а приносят больше пользы))
- Индексов должно быть мало - только те, которыми вы пользуетесь.
- Потому что они должны up-to-date, и поэтому они каждый раз будут пересчитываться. Любой индекс - удар по производительности (insert and update). Можно по логам смотреть какие индексы используются и какие нет. Которые не используются - убрать
- Настройка индекса по абсолютно разным данным(например время как стринга) - не эффективно.
- Т.к на один индекс приходится одна запись. Можно сделать индекс с игнорированием минут и секунд - тогда он будет эффективен В тоже время когда под одним индексом очень много данных - тоже плохо
Короче - следите за длинной индексов Показать тебе может только explain
Бекапы
- Инкрементальные бекапы - это галимая жадность)
- Если же делать инкрементами - то надо время от времени делать опорные дампы
Лучше делать полный бекап и автоматически проверять его развертку Главное не просто делать бекапы, но и проверять их.
Часто вместо бекапа внутри может оказаться просто сообщение об ошибке
Два канала слака: - Все о хороших бекапах - Все о плохих бекапах Credentials для бекапов - делайте на отдельном хосте
Разбитие разделов and Logical Volume Manager
Система - 32GB Swap - что-то Данные - 100GB После - ничего не размечать Тогда раздел с данными можно бужет увеличить
LVM - если снепшот не удался, то надо его сразу его удалить. Иначе снова будет эффект утюга из-за copy on write. LVM делает небольшой оверхед, но позволяет легче работать с разбиением разделов
Consul and HaProxy хороший must have
Натюрлих богдана хмельникцого Хмельной князь Телеграм Павла - @p01nt