Документ обсуждает множество важных вопросов и проблем, связанных с администрацией баз данных и транзакциями, включая их производительность и архитектурные решения. Основное внимание уделяется различиям между традиционными реляционными базами данных и NoSQL, а также вопросам оптимизации выполнения запросов и репликации. Также рассматриваются мифы и заблуждения, связанные с производительностью различных систем управления базами данных.

1. Top-­‐10
популярных
вопросов
администраторам
баз
данных
или
почему
я
против
свободного
оборота
короткоствола.
Илья
Космодемьянский
ik@postgresql-­‐consul@ng.com

2. "— Военный, а нам оружие дадут?
— Триста тридцать пять…"
(c)ДМБ
2

3. “Можно ли откатить commit? а в git’е можно”
• Часто
транзакции
воспринимаются
разработчиками
как
некое
расширение
синтаксиса
SQL
• Транзакции
-­‐
основа
базы
данных
а
не
дополнительная
фича
• Буква
D
в
аббревиатуре
ACID
• Страничная
модель
шедуллинга
транзакций,
причины
успеха
• Транзакции
не
замедляют
обработку
данных
при
высоком
concurrency
degree,
а
наоборот
ускоряют

4. “SQL это медленно и архаично, давайте будем
читать напрямую из таблицы?”
• Что
значит
напрямую?
• NoSQL
хорошо
бы
называть
NoACID
• Почему
любители
почитать
напрямую
не
любят
BerkeleyDB?
• Упражнение:
перепишите
на
свой
любимый
язык
SQL
запрос
c
join,
order
by,
group
by.
• Удобно?
Изящно?
Производительно?
Создатели
HQL,
HSQL,
OfoQL,
YQL
и
десятка
других
что
подобное
тоже
подозревают.

5. Зачем нам нужно делать бэкап, у нас же есть слэйв.
• Backup/recovery
vs.
High
availability
• Задача
backup’а
-­‐
корректное
восстановление
на
момент
последней
перед
аварией
успешной
транзакции
• Талант
и
рвение:
кто-­‐то
сказал
DROP
TABLE
...
CASCADE.

6. "Нам нужно выводить 20 очень важных count(*)
на главной странице..."
• Почему
это
плохо?
• Чего
именно
мы
хотим?
• Нагрузка
на
базе
-­‐
10К
пишущих
транзакций
в
секунду,
какую
смысловую
нагрузку
несет
count(event_id)
равный
1298734297002?

7. “Ну может все-таки можно?..”
• SELECT
reltuples
FROM
pg_class
WHERE
oid
=
'my_schema.tbl'::regclass;
• денормализуем
счетчик

8. Мы создали индекс, почему он не используется?
• Включен-­‐ли
сбор
статистики?
• Что
эффективней
-­‐
index
scan
или
seq
scan?
• <...>
where
posi•on-­‐1
<
10
-­‐
почему
оптимизатор
не
может
выполнить
такое
просто
действие?
А
дифур
решить?
А
интеграл
взять?
При
Джобсе
такого
не
было!

9. Можно-ли использовать join’ы?
• Нужно
• Альтарнативы:
in(...),
подзапрос,
join
в
приложении
◦ Откуда
оптимизатору
знать
что
попадет
в
in(...)?
◦ В
in(...)
внезапно
оказалось
200К
id
◦ Сколько
раз
надо
сходить
в
базу
за
данными,
чтобы
с’join’ить
5
таблиц?
◦ Алгоритмы
join’ов
имеют
разную
эффективность.
Реализуем
в
приложении
все?
Будем
выбирать?
Напишем
внешний
оптимизатор?
• Когда
join
не
эффективен
◦ Для
hash
join
не
хватает
памяти,
для
nested
loop
-­‐
не
хватает
индексов
◦ Давайте
с’join’ним
255
таблиц...
и
запросто
может
быть
озадачен
выбором
255!
путей
join

10. "Мне говорили что innodb можно так настроить,
что будет быстрее чем Oracle..."
-
Почему
вы
так
думаете?
Ну
оракл
он
для
более
серьезных
задач...
В
смысле!?
Нуу...
он
тяжелый
и
неповоротливый,
у
него
дистрибутив
весит
2.6Gb...

11. "Мне говорили что innodb можно так настроить,
что будет быстрее чем Oracle..."
• Смешно?
• У
многих
сравнений
баз
данных
уровень
аргументации
примерно
такой
же
• Бессмысленно
сравнивать
коробочные
версии
• Не
сравнивайте
очевидные
вещи:
если
база
умеет
своими
средствами
параллельно,
асинхронно
утилизовать
16ти-­‐
канальный
SAN,
синтетические
тесты
I/O
против
базы,
которая
этого
не
умеет,
вырожденны
изначально

12. “Давайте сделаем schemaless (или EAV), это
позволит нам уйти от проблемы добавления
колонок?”
• В
наше
хранилище
ведь
всегда
будет
ходить
только
одно
приложение
• Ну
появится
второе,
будем
выносить
в
конфиг
что
откуда
доставать
-­‐
хардкод
это
плохо!
• А
если
приложения
будут
конфиг
слишком
интенсивно
использовать,
мы
на
него
мьютекс
повесим!
• EAV
это
универсально,
дизайн
схемы
не
нужен.
Внезапно
появляется
аттрибут
нового
хитрого
типа...
• Если
EAV
будет
тормозить,
мы
передем
на
новую,
прекрасную
и
светлую
базу
данных!
• Или
назовем
EAV
ядром
и
будем
денормализовывать!

13. Нам нужно реализовать Мультимастер репликацию
• Чего
мы
хотим?
Катастрофоустойчивости?
Масштабирования
на
запись?
• Mul•site
запись
это
2
Phase
Commit.
Вы
этого
действительно
хотите?
• Различайте
bidirec•onal
репликацию
и
мультимастер
репликацию!
Почти
честную
мультимастер
репликацию
умеет
только
Oracle.
• Катастрофоустойчивый
мультимастер
-­‐
дорого
и
сложно
• Падение
одной
ноды
все
равно
ведет
к
проблемам
• Master/Slave
+
грамотный
failover