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

Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Павел Белоусов

Реляционные базы данных часто подвергаются высоким нагрузкам, обслуживая большое количество пользователей и сервисов. Разработать базу, способную эффективно работать в высоконагруженной среде – не такая простая задача.

В докладе будет рассмотрен пример из практики про разработку высоконагруженной базы данных (сотни миллионов записей, постоянно меняющихся из нескольких десятков потоков) на основе MS SQL Server , расказано о проблемах, с которыми мы столкнулись, как их решали и какие подходы при этом использовали. Будет разобран пример разрешения взаимных блокировок в базе под большими нагрузками.

В докладе будут упомянуты следующие темы:

  • денормализация данных;
  • планы выполнения;
  • оптимизация индексов;
  • профайлинг базы данных;
  • взаимные блокировки и их разрешение.

Видео

Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/2b5-highload-relational-database-belousov.avs.avi


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация


Примечания и отзывы


Узнал, как с помощью кувалды и напильника заточить перфоманс MSSQL. Не дай бог таким заниматься :). ©
Если не ошибаюсь, именно эти ребята настроили репликацию из проприетарной объектной базы в реляционную, и потом разгребали получившиеся завалы. Выступление оставило легкий привкус трюкачества, но было не очень скучным. ©

История оптимизации работы с БД в одном проекте. Особенности: используются 2 БД — объектная и реляционная. Первая является основным хранилищем, с ней работают бизнес-операции. А вторая (в нее реплицируются данные из первой) используется для чтения во всяких отчетах (или даже вообще повсеместно). Для чего нужна вторая — то ли для скорости, то ли из-за бедности языка запросов в используемой объектной БД. По мере роста объема данных возникли 2 основные проблемы:

  • долго выполняются запросы при интерактивной работе (> 3 минут)
  • лаг чтения из-за репликации (> 1 часа)

Решали денормализацией, настройкой индексов, оптимизацией планов выполнения.

На доклад я пришел почти в конце, потому что общался после своего доклада. Доклад был о приложении по синхронизации объектной оперативной базы данных в реляционную. В объектной базе данных хранятся оперативные данные, она хорошо масштабируется. В реляционную передается только часть, обеспечивающая поиски и запросы, и она существенно меньше по объему. При этом есть разные требования по оперативности передачи для разных данных — от минут до часов. Проект был начат семь лет назад, и сейчас стадия — доработка по требованиям на изменения. А также оптимизация — за время эксплуатации в реляционной части накоплены большие объемы данных.

Для меня лично содержание доклада большого интереса не представляло, так как по своему опыту работы с базами данных я эти механизмы хорошо представляю. Это Этап решение проблем в тяжелыми запросами, блокировками и deadlock.Однако, доклад будет интересен тем, у кого такие задачи встают в первые.

Механизмы, упомянутые в докладе.

  • Избегание tablock
  • Чтобы избегать deadlock — стройте обработку с циклом по одному индексу.
  • Учите матчасть — индексы, блокировки, планы выполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Репликация: База Знаний «Заказных Информ Систем» → «Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-2011)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».