Комментарии 6
Если бы из баз только читали, то подход был бы годным. Чем выше отношение W / (R+W) - тем больше погрешность метода. При достаточно высоком отношении влияние затрат на ожидание/постановку/снятие эксклюзивных блокировок будет порядково выше, чем затрат на операции поиска/выборки. Аналог - модель идеального газа в термодинамике и нелинейного после определенных концентраций молекул - когда влияние их друг на друга начинают существенно искажать простую теорию. Другой аналог - зависимые или независимые случайные величины. Начиная с какой-то величины созависимости пренебрежение ей делает независимую модель практически неработоспособной.
Соответственно, если проверять производительность в близких к реальным условиях - нужно работать на близких к реальным нагрузочных смесях.
Кроме этого - scan и seek в условиях параллельной активности по записи отличаются не только по O(N) vs O(logN) - scan в условиях параллельных записей практически убивает параллелизм, а seek за счет точечных блокировок позволяет системе жить при гораздо более высоких отношениях W / (R+W).
Отсюда вывод - производительность СУБД зависит не только от настройки (задача ДБА), но и от способа работы с ней (задача Дата Архитектора). Даже при наличии индексов или шард один неоптимально написанный запрос убьет перформанс сотни остальных, написанных правильно. И значит, мы можем говорить о производительности СУБД только в контексте ее связки с приложением, которое с ней работает - то есть о производительности всей [b]информационной системы[/b]
И далее - вывод, который непосредственно идет из последнего абзаца - только Дата Инженер / Дата Архитектор компетентны в оптимальной работе с БД. Значит, если построить слой, который позволит менее компетентным разработчикам работать с данными только определенными вышеуказанными фигурами способами - это будет гарантировать производительность системы. Самые надежные способы, которые нельзя обойти by design - это внутрибазное программирование - то есть SP и TVF в первую очередь. Этот способ заодно абсолютно надежно решает и проблемы разделения доступа к БД со стороны разных систем - размещением этих объектов в разных схемах. Оба этих свойства дают абсолютную гарантию того, что автомобили фуллстеков поедут строго по заранее определенным и проверенным дорогам, а не будут двигаться по территории построенного архитектором города хаотически, сталкиваясь и снося все вокруг. Ценность этой гарантии порядково выше (для тех, кто понимает эту ценность) гипотетической возможности заменить бакенд на «аналогичный», которую усиленно педалируют адепты CRUD- и code-first подходов.
А можете предоставить любые расчёты или результаты экспериментов, для обоснования следующих утверждений:
Чем выше отношение W / (R+W) - тем больше погрешность метода. При достаточно высоком отношении влияние затрат на ожидание/постановку/снятие эксклюзивных блокировок будет порядково выше, чем затрат на операции поиска/выборки.
Начиная с какой-то величины созависимости пренебрежение ей делает независимую модель практически неработоспособной.
Ну и мой любимый вопрос - производительность вы как считаете ?
производительность СУБД зависит не только от настройки (задача ДБА), но и от способа работы с ней (задача Дата Архитектора).
Что значить "зависит"?
Следующее утверждение на чем основано
вывод, который непосредственно идет из последнего абзаца - только Дата Инженер / Дата Архитектор компетентны в оптимальной работе с БД.
Это ваш личный вывод ?
Самое главное - кого эта база обслуживает и зачем. В зависимости от бизнес-требований где-то важны одни вещи, где-то другие. Возможна неоднородная ситуация, где каким-то пользователям необходимо обеспечить быстрый отклик, а какие-то пользователи могут быть не особо важны, и оптимизация для них может быть попросту вредной. Так что начинать надо с анализа бизнес-требований, так что метрики, описанные вами, мягко говоря, не особо полезны. Вы можете что-нибудь наоптимизировать по ним и получить якобы результат, но в итоге бизнес может не получить того, что реально нужно.
Короче, почитайте книжки за авторством Cary Millsap про Method-R. Они уже древние, но всё ещё очень полезные.
Пример: есть юзеры категории 1 (приоритетные) и юзеры категории 2 (не приоритетные). 1-й категории вреден индекс I на таблице T, 2-й категории полезен индекс I на таблице T. Но, предположим, вы оперируете только общей картиной и индекс создали, поскольку с ним общие метрики улучшились. Но самое-то важное не общие метрики, а то, что приоритетные юзеры пострадали.
каким-то пользователям необходимо обеспечить быстрый отклик, а какие-то пользователи могут быть не особо важны, и оптимизация для них может быть попросту вредной.
А можно пример из жизни такой оригинальной архитектуры и бизнес требований?
Производительность СУБД — расчет метрики, временной анализ, параметрическая оптимизация