13
Top10 популярных вопросов администраторам баз данных или почему я против свободного оборота короткоствола. Илья Космодемьянский ik@postgresqlconsul@ng.com

Top-10 популярных вопросов администраторам баз данных или почему я против свободного оборота короткоствола

Embed Size (px)

Citation preview

Top-­‐10    популярных  вопросов  администраторам  баз  данных  или  

почему  я  против  свободного  оборота  короткоствола.

Илья  Космодемьянскийik@postgresql-­‐[email protected]

2

"— Военный, а нам оружие дадут? — Триста тридцать пять…"

(c)ДМБ

“Можно ли откатить 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

Нам нужно реализовать Мультимастер репликацию