View
1.101
Download
2
Category
Preview:
Citation preview
Top-‐10 популярных вопросов администраторам баз данных или
почему я против свободного оборота короткоствола.
Илья Космодемьянскийik@postgresql-‐consul@ng.com
“Можно ли откатить commit? а в git’е можно”
• Часто транзакции воспринимаются разработчиками как некое расширение синтаксиса SQL• Транзакции -‐ основа базы данных а не дополнительная фича• Буква D в аббревиатуре ACID• Страничная модель шедуллинга транзакций, причины успеха• Транзакции не замедляют обработку данных при высоком concurrency degree, а наоборот ускоряют
“SQL это медленно и архаично, давайте будем читать напрямую из таблицы?”
• Что значит напрямую?• NoSQL хорошо бы называть NoACID • Почему любители почитать напрямую не любят BerkeleyDB?• Упражнение: перепишите на свой любимый язык SQL запрос c join, order by, group by.• Удобно? Изящно? Производительно? Создатели HQL, HSQL, OfoQL, YQL и десятка других что подобное тоже подозревают.
Зачем нам нужно делать бэкап, у нас же есть слэйв.
• Backup/recovery vs. High availability • Задача backup’а -‐ корректное восстановление на момент последней перед аварией успешной транзакции• Талант и рвение: кто-‐то сказал DROP TABLE ... CASCADE.
"Нам нужно выводить 20 очень важных count(*) на главной странице..."
• Почему это плохо?• Чего именно мы хотим?• Нагрузка на базе -‐ 10К пишущих транзакций в секунду, какую смысловую нагрузку несет count(event_id) равный 1298734297002?
“Ну может все-таки можно?..”
• SELECT reltuples FROM pg_class WHERE oid = 'my_schema.tbl'::regclass;
• денормализуем счетчик
Мы создали индекс, почему он не используется?
• Включен-‐ли сбор статистики?• Что эффективней -‐ index scan или seq scan?• <...> where posi�on-‐1 < 10 -‐ почему оптимизатор не может выполнить такое просто действие? А дифур решить? А интеграл взять? При Джобсе такого не было!
Можно-ли использовать join’ы?• Нужно• Альтарнативы: in(...), подзапрос, join в приложении◦ Откуда оптимизатору знать что попадет в in(...)?◦ В in(...) внезапно оказалось 200К id◦ Сколько раз надо сходить в базу за данными, чтобы с’join’ить 5 таблиц?◦ Алгоритмы join’ов имеют разную эффективность. Реализуем в приложении все? Будем выбирать? Напишем внешний оптимизатор?
• Когда join не эффективен◦ Для hash join не хватает памяти, для nested loop -‐ не хватает индексов◦ Давайте с’join’ним 255 таблиц... и запросто может быть озадачен выбором 255! путей join
"Мне говорили что innodb можно так настроить, что будет быстрее чем Oracle..."
- Почему вы так думаете?- Ну оракл он для более серьезных задач...- В смысле!? - Нуу... он тяжелый и неповоротливый, у него дистрибутив весит 2.6Gb...
• Смешно?• У многих сравнений баз данных уровень аргументации примерно такой же• Бессмысленно сравнивать коробочные версии• Не сравнивайте очевидные вещи: если база умеет своими средствами параллельно, асинхронно утилизовать 16ти-‐канальный SAN, синтетические тесты I/O против базы, которая этого не умеет, вырожденны изначально
"Мне говорили что innodb можно так настроить, что будет быстрее чем Oracle..."
• В наше хранилище ведь всегда будет ходить только одно приложение• Ну появится второе, будем выносить в конфиг что откуда доставать -‐ хардкод это плохо!• А если приложения будут конфиг слишком интенсивно использовать, мы на него мьютекс повесим!• EAV это универсально, дизайн схемы не нужен. Внезапно появляется аттрибут нового хитрого типа...• Если EAV будет тормозить, мы передем на новую, прекрасную и светлую базу данных!• Или назовем EAV ядром и будем денормализовывать!
“Давайте сделаем schemaless (или EAV), это позволит нам уйти от проблемы добавления колонок?”
• Чего мы хотим? Катастрофоустойчивости? Масштабирования на запись?• Mul�site запись это 2 Phase Commit. Вы этого действительно хотите?• Различайте bidirec�onal репликацию и мультимастер репликацию! Почти честную мультимастер репликацию умеет только Oracle.• Катастрофоустойчивый мультимастер -‐ дорого и сложно• Падение одной ноды все равно ведет к проблемам• Master/Slave + грамотный failover
Нам нужно реализовать Мультимастер репликацию
Recommended