Реляционные базы данных часто подвергаются высоким нагрузкам, обслуживая большое количество пользователей и сервисов. Разработать базу, способную эффективно работать в высоконагруженной среде – не такая простая задача.
В докладе будет рассмотрен пример из практики про разработку высоконагруженной базы данных (сотни миллионов записей, постоянно меняющихся из нескольких десятков потоков) на основе MS SQL Server , расказано о проблемах, с которыми мы столкнулись, как их решали и какие подходы при этом использовали. Будет разобран пример разрешения взаимных блокировок в базе под большими нагрузками.
История оптимизации работы с БД в одном проекте. Особенности: используются 2 БД — объектная и реляционная. Первая является основным хранилищем, с ней работают бизнес-операции. А вторая (в нее реплицируются данные из первой) используется для чтения во всяких отчетах (или даже вообще повсеместно). Для чего нужна вторая — то ли для скорости, то ли из-за бедности языка запросов в используемой объектной БД. По мере роста объема данных возникли 2 основные проблемы:
долго выполняются запросы при интерактивной работе (> 3 минут)
На доклад я пришел почти в конце, потому что общался после своего доклада. Доклад был о приложении по синхронизации объектной оперативной базы данных в реляционную. В объектной базе данных хранятся оперативные данные, она хорошо масштабируется. В реляционную передается только часть, обеспечивающая поиски и запросы, и она существенно меньше по объему. При этом есть разные требования по оперативности передачи для разных данных — от минут до часов. Проект был начат семь лет назад, и сейчас стадия — доработка по требованиям на изменения. А также оптимизация — за время эксплуатации в реляционной части накоплены большие объемы данных.
Для меня лично содержание доклада большого интереса не представляло, так как по своему опыту работы с базами данных я эти механизмы хорошо представляю. Это Этап решение проблем в тяжелыми запросами, блокировками и deadlock.Однако, доклад будет интересен тем, у кого такие задачи встают в первые.
Механизмы, упомянутые в докладе.
Избегание tablock
Чтобы избегать deadlock — стройте обработку с циклом по одному индексу.
Учите матчасть — индексы, блокировки, планы выполнения.
Автор рассказывал о собственном опыте работы над реальным проектом.
Задача состояла в обеспечении репликаций из нереляционной(иерархической) БД собственной разработки в реляционную с цель обеспечить приемлемую скорость выполнения некоторых запросов (auto-complete для пользователя, отчеты). В качестве реляционной БД был выбран MS SQL.
Данные в иерархическую БД вводят пользователи в процессе своей работы, там же используются запросы к реляционной БД. Поэтому для некоторых типов данные репликации должны проходить максимум за одну минуту.
Клещами из докладчика удалось выцепить что же за данные он реплицирует и хранит — компания занимается сбором и систематизацией информации в Web.
Система делалась быстро, и, я так понял, не очень аккуратно. О производительности не думали, поэтому с ростом объема данных появились проблемы:
запросы работали медленно
autocomplete отрабатывал за несколько десятков секунд
rebuild индексов занимал до 12 часов в день!
задержки репликаций стали исчисляться десятками минут.
Что же было сделано?
денормализация
посмотрели на запросы
убрали лишние колонки
убрали лишние JOIN
постарались избавиться от LIKE — применили полнотекстовый поиск
научились пользоваться профайлером, поставляемым с SQL-сервер
вспомнили про индексы
узнали, что покрывающий индексы это хорошо!
И еще одно странное решение, мотивацию я так и не понял:
стали применять «грязные» чтения
За исключением последнего пункта, который сам по себе очень сомнителен, все остальные решения абсолютно стандартны. Я сначала даже удивился — зачем был нужен доклад, автором которого вполне мог быть Капитан Очевидность? Потом, однако, мне пришла в головы мысль, что всем этим приемам, которые знакомы каждому разработчику, решавшему проблемы с производительностью БД, нигде не учат.
Единственный путь — это учиться у коллег, параллельно читая книжки от которых, без должной поддержки, голова идет кругом. Так что доклад хороший и годный — может быть даст подсказку куда смотреть разработчикам, которые впервые сталкиваются с тормозами БД.
Ну а я ничего нового для себя не услышал.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
запросы работали медленно