Персональные инструменты
 

Application Developer Days 2: Отчет Кудрявцева В.Б/Пример разработки высоконагруженной базы данных

Материал из CustisWiki

Версия от 20:11, 15 мая 2011; StasFomin (обсуждение | вклад) (Новая страница: « Автор [[Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-201...»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Автор рассказывал о собственном опыте работы над реальным проектом.

Задача состояла в обеспечении репликаций из нереляционной(иерархической) БД собственной разработки в реляционную с цель обеспечить приемлемую скорость выполнения некоторых запросов (auto-complete для пользователя, отчеты). В качестве реляционной БД был выбран MS SQL.

Данные в иерархическую БД вводят пользователи в процессе своей работы, там же используются запросы к реляционной БД. Поэтому для некоторых типов данные репликации должны проходить максимум за одну минуту.

Клещами из докладчика удалось выцепить что же за данные он реплицирует и хранит — компания занимается сбором и систематизацией информации в Web.

Система делалась быстро, и, я так понял, не очень аккуратно. О производительности не думали, поэтому с ростом объема данных появились проблемы:

No.svg запросы работали медленно

No.svg autocomplete отрабатывал за несколько десятков секунд

No.svg rebuild индексов занимал до 12 часов в день!

No.svg задержки репликаций стали исчисляться десятками минут.

Что же было сделано?

  • денормализация
  • посмотрели на запросы
    • убрали лишние колонки
    • убрали лишние JOIN
  • постарались избавиться от LIKE — применили полнотекстовый поиск
  • научились пользоваться профайлером, поставляемым с SQL-сервер
  • вспомнили про индексы
    • узнали, что покрывающий индексы это хорошо!

И еще одно странное решение, мотивацию я так и не понял:

  • стали применять «грязные» чтения

За исключением последнего пункта, который сам по себе очень сомнителен, все остальные решения абсолютно стандартны. Я сначала даже удивился — зачем был нужен доклад, автором которого вполне мог быть Капитан Очевидность? Потом, однако, мне пришла в головы мысль, что всем этим приемам, которые знакомы каждому разработчику, решавшему проблемы с производительностью БД, нигде не учат.

Единственный путь — это учиться у коллег, параллельно читая книжки от которых, без должной поддержки, голова идет кругом. Так что доклад хороший и годный — может быть даст подсказку куда смотреть разработчикам, которые впервые сталкиваются с тормозами БД. Ну а я ничего нового для себя не услышал.