"Мы два месяца долбались, а потом построили индекс" (c) Аксенов
9 likes•3,310 views
Саша, главный инженер компании Git in Sky, делится опытом оптимизации MySQL-сервера и управления большими объемами данных, обсуждая проблемы производительности и способы их решения. Основное внимание уделяется замедлению запросов и необходимости улучшения индексов, а также интеграции с системами мониторинга. Автор подчеркивает важность искать альтернативные хранилища для управления данными, а не слепо следовать устаревшим методам.
"Мы два месяца долбались, а потом построили индекс" (c) Аксенов
- 2. Привет! ● Меня зовут Саша ● Я работаю главным инженером ● В компании Git in Sky ● Однажды я настроил один MySQL-сервер
- 3. Какого цвета инсталлятор Oracle? ● Вы используете базы данных? ● Умеете читать и понимать план запроса? ● Настраивали однажды MySQL-сервер? ● Может, и не однажды? ● Может, и не MySQL?
- 4. Какова цель операции? ● Однажды ко мне обратился один человек ● Он предоставил следующие документы: ● http://slideshare.net/profyclub_ru/08-6 ● Действовать надо было быстро и осторожно
- 5. Кто мой заказчик? ● Конструктор сайтов, http://setup.ru ● Пользовательские файлы хранятся в базе данных (PostgreSQL) ● Для больших файлов используется large objects API ● Приложение на Perl, под Apache + mod_perl ● В 2012-м это работало хорошо, в 2014-м...
- 6. Перечень возникших сложностей ● Количество файлов: 6 млн => 207(85) млн ● Размер индексов: 2Gb => десятки Gb ● Скорость синхронизации: 100 f/s => ~30 f/s ● Объем базы данных на дисках: 6Tb на тот момент ● ^ Сейчас уже 6.7Tb, и дальше будет только больше
- 7. Анализ ситуации ● Гражданский специалист: “Файлы в БД? АААА, куда я попал!” ● Советы взять какое-нибудь другое хранилище я уже слышал, можно их не повторять :) ● Наш специалист: “Ничего не ломаем, валим всех аккуратно, отходим быстро”
- 8. Детальный анализ ситуации ● Бизнес-причины хранить файлы в СУБД: ● Нужны транзакции при публикации сайта ● Варианты: ● Менять хранилище и делать транзакции на уровне приложения ● Найти транзакционное хранилище (а это СУБД :) )
- 9. Объекты предметной области ● Таблица domains – имена доменов ● Таблица content – метаинформация о файле (время последнего изменения и путь) ● Таблица stat – сами бинарные данные и их sha-1 хэш для дедупликации ● Таблица deleted – признак того, что файл удален ● Все четыре связаны между собой
- 10. Пользовательские сценарии ● Публикация и синхронизация файлов: ● Публикуем всегда на одну и ту же ноду ● Кастомный синхронизатор не очень быстро обновляет все остальные ноды ● Отдача статического контента: ● Отдаем а) последнюю, б) неудаленную версию
- 11. Что плохо? ● Отдача файлов работает не очень быстро ● Публикация и синхронизация – тоже ● Существующее железо справляется не очень хорошо ● Одним словом, Hetzner!
- 12. Я бы даже сказал, полный Hetzner ● Было: RAID0 2*3Tb SATA, 16G RAM, 128G SSD – для pg_temp и nginx, сортировка в PostgreSQL и буферизация в nginx – быстро ● Стало: RAID10 4*4Tb SATA, 48G RAM без SSD ● SSD не дают, хотя место в корпусе еще есть – Hetzner! ● Надо жить с этим
- 13. Но как? ● Как обычно: ● slow queries log, потом pgFouine или pgBadger, раз в сутки – смотреть отчеты, в них смотреть план запроса
- 14. Все еще проще ● Два самых популярных запроса при отдаче и синхронизации - “найти неудаленный файл” и “найти, что синхронизировать” - это запросы ко view ● Они и тормозят, их и надо оптимизировать
- 15. Начнем с отдачи файлов ● Этот план запроса мне не нравится ● В нем слишком многабукв
- 16. Нам нужен новый план ● Материализовать view ● В PostgreSQL 9.2 нет materialized view ● Но в книге “Enterprise Rails” написано, как их эмулировать с помощью триггеров ● Enterprise WHAT, sorry?
- 17. Шаверма своими руками ● “Поверх” нематериализованного view делается таблица с такими же полями ● Она работает как кэш – записи в ней заводятся по запросу ● Сначала ищем в ней, потом в исходном view, если не нашлось в ней ● Записи инвалидируются триггерами на всех таблицах-участниках исходного view
- 18. Как измерить результат? ● pgFouine и pgBadger не подходят – долго ждать, много процессить, slow log нерепрезентативен ● Расширение pg_stat_statements ● ^ Лучшее, что было со мной ● Позволяет смотреть статистику в реальном времени
- 19. Как пользоваться? ● SELECT (total_time / 1000 / 60) as total_minutes, (total_time/calls) as average_time, calls, query FROM pg_stat_statements ORDER BY total_minutes/average_time desc;
- 20. Что покажет?
- 21. Близки ли мы к цели? ● Хорошо: кэширующая таблица кэширует ● Плохо: примерно 30-40% запросов не попадают в кэш ● Может быть, надо подождать? ● На третий день Зоркий Глаз заметил, что у тюрьмы нет одной стены
- 22. Know your weapon ● “Посмотреть в таблице, потом во view” ● А что, если у нас 404, и файла нет вообще? ● Зачем ходить за такими файлами во view?
- 23. Стало ли лучше? ● Ночью – 15мс в среднем ● Днем – 40-50мс в среднем ● Обычно я работаю по ночам ● А результат нужно смотреть в середине дня на пике нагрузки ● Что очень неудобно
- 24. Я люблю графики! ● Главная метрика – время отдачи контента ● Ее лучше измерять на эппсервере, а не в базе? ● Zabbix ● Graphite/StatsD ● http://goo.gl/x6If1S ● ^ Ansible playbook для установки StatsD и Graphite
- 25. Я не люблю Zabbix! ● Это плохо написанная система “все-в-одном”, по качеству напоминающая китайскую видеодвойку из 90-х ● К тому же, там плохие планы запросов
- 26. UNIX-way не всегда вреден ● Graphite/StatsD stack: ● Dashboard (сначала – стандартный от Graphite), ● Веб-сервис отдачи графиков (на Django) ● Коллектор с RRD-like хранилищем (Carbon) ● Агрегатор/препроцессор с UDP-интерфейсом (собственно, StatsD)
- 27. StatsD server ● Есть на Go, Node.JS, Python, Perl, C, Ruby, ... ● Сперва я взял Python: ● Потом опомнился и взял Perl
- 28. Уже должен быть результат? ● 40-50мс никак не хотят превращаться в 0-1 ● Что делать? ● Построить более лучшие индексы
- 29. Сказано – сделано ● Для самого частого запроса построен индекс на все три столбца, по которым идет поиск ● В этот момент все стало еще хуже! :) ● Размер индекса – 18 гигабайт ● Зоркий Глаз опять заметил, что у тюрьмы нет одной стены
- 30. Чрезвычайные меры ● Одно из полей, по которым индекс – varchar ● Превращаем varchar в int: ● http://stackoverflow.com/a/9812029/601572 ● Совсем забыл сказать: база данных уже полна хранимых процедур и триггеров, кроме того, я их совершенно не боюсь ● Просто не люблю
- 31. Что же было по ссылке? ● Я не помню, поэтому записал прямо сюда: ● create function h_int(text) returns int as $$ select ('x'||substr(md5($1),1,8))::bit(32)::int; $$ language sql;
- 32. К чему приводит чтение* ● *плана запроса ● SET enable_bitmapscan=false; <= nested loops SELECT something FROM stat s JOIN domains d ON d.id = s.domain JOIN content c ON c.id = s.content LEFT JOIN deleted e ON e.id = s.id WHERE d.name = domname AND h_int(s.name) = h_int(filename) <= новый индекс AND s.name = filename AND date_part('epoch'::text, s.ptime) = filerev
- 33. Счастливы ли мы? ● Размер индекса: 18G => 8G ● Время запроса: 40-50мс => 20-25мс ● 90% всех запросов обслуживаются за 100мс ● В среднем запрос обслуживается приложением за 50мс
- 34. Как это выглядит в Graphite
- 35. Как это выглядит в Zabbix
- 36. Часть вторая, момент истины ● При проверке существования файла я получал id файла, если он есть, и решил этим воспользоваться, чтобы ходить во view по PK ● Оказалось, я ошибся ранее, и мне возвращался массив id – при оптимизации это стало явным ● Я исправил ошибку и этой оптимизацией добился ускорения еще в два раза
- 37. Что мешало ● PL/pgSQL – плохой, негодный язык ● Я так и не понял, как в нем сконструировать программно множество из нуля строк, поэтому возвращал, при необходимости, такое множество, делая SQL-запрос в специально заготовленную пустую таблицу с нужным списком полей
- 38. Что еще удалось ● В качестве dashboard к Graphite я поставил Grafana ● Систему отдачи файлов я переписал на смешанную асинхронно/синхронную, используя для внутренних нужд HTTP status 418 I'm a teapot ● “Асинхронная” не значит “быстрая” (наоборот), но значит “экономичная”
- 39. Что было дальше ● Я пытался тюнить кастомный репликатор, но быстро понял, что это невозможно – он работает на пределе ● Я решил заменить его на какое-то общее средство репликации и выбрал Bucardo ● Bucardo в тестовом режиме работало отлично, но из 6+Tb базы среплицировало 1Tb
- 40. WTF? ● Know your weapon: ● Large objects – это просто еще один key-value storage, по сути ● Репликация ими не занимается ● При этом в нашей базе мы никогда их не перезаписываем после создания! ● Кроме того, у них уникальные номера
- 41. И вот тут мне карта пошла! ● Object storages: ● LeoFS ● OpenStack Swift ● Elliptics ● Riak CS ● Ceph Object Gateway ● Но это другая история, и она еще не закончена
- 42. Выводы ● Иногда, прежде чем сказать “давайте перепишем всё”, стоит попробовать переписать не всё ● “Переписать всё” - тоже выход, надо только уметь писать и знать, где взять оружие
- 43. Спасибо за внимание! ● Пожалуйста, ваши вопросы! ● С вами был Александр Чистяков, ● Главный инженер Git in Sky ● http://twitter.com/noatbaksap ● [email protected] ● http://gitinsky.com, http://meetup.com/DevOps-40