Ну, целью поста было предупредить тех, кто планирует использовать In-Memory OLTP, или использует, но ещё не столкнулся с описанным, а не сказать, что технология фуфло и использовать её не стоит. Те или иные проблемы будут с любым решением.
Как раз таки фильтруемые индексы проявляются при фильтрациях и не важно где-в update, delete или merge.
ну я же специально привёл пример — где при использовании merge проблема есть, а при использовании update + insert — проблемы нет.
Я изначально «прицепился» к этой вашей фразе:
В данном случае достаточно научиться правильно писать merge и все.
очень уж она категорично звучит и вот мы выяснили, что, как минимум, кроме правильного написания merge нужно ещё не использовать filtered index'ы.
Мне позиция «авторитетов» гораздо более близка. Они говорят менее квалифицированным людям — у merge есть проблемы, они могут выстрелить, лучше их не использовать. Вы пишете в комментариях — я использовал и использую, всё ок, не надо бояться. При этом не оговариваете условия использования.
При использовании merge проблема проявляется, при использовании update+insert — нет, но это проблема не merge? Окей. Но тогда в первом вашем сообщении хотелось бы видеть, что кроме умения готовить merge, нужно ещё отказаться от filtered indexes. Может ещё что-то использовать не стоит?
Что касается "автора материала не в курсе" — ну, даже не знаю что тут сказать.
Ну вот пример бага, который воспроизводится на не самых древних версиях, которые ещё много где используются.
The MERGE plan may fail at execution time depending on the order in which rows are processed, and the distribution of data in the database. Worse, a previously solid MERGE query may suddenly start to fail unpredictably if a filtered unique index is added to the merge target table at any point.
Bug reproduces on:
SQL Server 2014 (SP3-CU2) build 12.0.6214.1
SQL Server 2012 (SP4-GDR) build 11.0.7462.6
Да, там же описаны воркаэраунды, но, считается ли это предсказуемым и допустимым поведением для mission-critical систем? Как по мне — нет.
Я не говорил, что у встроенной репликации нет проблем
Ну да, вы запретили мне их упоминать, пока я не напишу свою без этих проблем.
Задачи разные, квалификация разная, есть множество инсталляций и 2008, и 2012, и 2016 без патчей, где проблемы присутствуют. Говорить, что «надо просто уметь его готовить» — не корректно. Вы предполагаете, что Аарон Бертранд не умеет его готовить?
Да, мне тоже нравится MERGE, он прикольный и удобный, но в критически-важные участки я его без веских причин не потащу — предсказуемость важнее.
Вы писали, что MERGE работает быстрее UPDATE — может быть есть конкретные примеры?
Перед тем как критиковать встроенную репликацию, попробуйте написать свою.
ИМХО, странное предложение. Да репликация сложный механизм, но в ней есть проблемы и приводить её в пример в контексте «у меня с Merge всё работает и у репликации с Merge нет проблем» тоже странно, потому что репликация может привести ко множеству проблем безотносительно того — могу ли я, или кто-то другой, сделать лучше.
Сколько же на этой таблице индексов, что удаление 10 тысяч строк занимало минуту, а перенос сотен миллионов (вы писали про удаление только 100 млн.) занимает час?
И сколько потом все эти индексы и констрейнты снова строились?
Допустимо, кроме того, поместить YEAR в выражение GROUP BY, так как выражение SELECT выполняется первым. В результате интерпретатору, после выполнения этого выражения, уже будет известно о том, что в запросе имеется столбец с именем YEAR:
Вообще, интересно — это часть стандарта или нет? Для MS SQL Server — это процитированное утверждение ложно, обращаться к столбцу по псевдониму в GROUP BY в нём нельзя. SQL Bolt и Towads Data Science, без привязки к СУБД, тоже говорят о том, что GROUP BY «выполняется до» SELECT. А PostgreSQL позволяет такое, MySQL, видимо тоже.
Спасибо!
Насколько я понимаю ситуацию с columnestor'ами — размер сегмента не ограничивается (хотя не знаю не пытается ли он сегмент целиком прочитать и что будет, если не сможет), но в памяти больше чем 352 МБ «держаться» не будет. Причём ограничение там на экземпляр, т.е. несколько DWH-запросов в разные БД могут сильно конкурировать за память.
Спасибо за статью. Имхо, стоит добавить, что и для columnstore индексов, и для in-memory oltp в express edition даже более смешные ограничения, чем на всё остальное.
upd: Увидел, что про ограничения для columnstore написано, сорри.
if you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system.
Даже в вашем эксперименте это starting value вполне неплохо себя показывает. Сделаете таблицу в 4 раза больше и, вероятно, разница на сканах тоже не будет столь заметной.
Конечно было бы здорово иметь столько ОЗУ, чтобы туда влезало всё, что нужно. И, конечно, рекомендации — это всегда что-то усреднённое, подходящее не всем, но они дают хоть какую-то отправную точку.
Спасибо за пост.
Что интересно, как раз для индексов — рекомендации о размере shared_buffers в 1/4 ОЗУ вполне себе работают. При поиске по индексу разница во времени выполнения не велика.
Вот для скана проигрыш на рекомендуемом размере очевиден, но, неочевидно, будет ли при реальной нагрузке картина такой же.
У вас, наверное, и правда крутое хранилище. Просто связи с SQL Server не видно — нет у него чтения (ещё и последовательного, наверное?) блоком 4кб, с блоком 64k было бы интереснее.
Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.
Поскольку статья называется "Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS", расскажите, пожалуйста, при каких операциях SQL Server использует чтение блоком 4k?
каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows
Это неправда, начиная с SQL Server 2017 можно делать Availability Group без кластера. В такой группе. ЕМНИП, не будет авто-файловера, точно не будет listener'a (придётся менять строку соединения приложения, при смене мастера), но это будет Availability Group и реплики могут быть доступны на чтение.
По ссылке, несколько я понял, всё равно под капотом используется backup log, как минимум. Не очень понимаю зачем делать бэкап без использования ключевого слова бэкап.
Предполагаю, что со снапшота ФС можно снять копии файлов данных и ЖТ, и оно потом заведётся.
По вашей ссылке говорится, что deprecated backup [log] with [media]password и backup [log] to tape — нельзя будет пароль повесить и на ленту бэкап сделать. Про сам backup/restore речь не идёт
Спасибо!
Честно говоря не очень понял вопрос. Какой выводимой информации? В blocked process report WaitResources выглядят одинаково в 2012-2017, в 2019 не смотрел. Описанное в посте, вместе с physloc, lockres точно актуально для sql server 2012-2017.
Я изначально «прицепился» к этой вашей фразе:
очень уж она категорично звучит и вот мы выяснили, что, как минимум, кроме правильного написания merge нужно ещё не использовать filtered index'ы.
Мне позиция «авторитетов» гораздо более близка. Они говорят менее квалифицированным людям — у merge есть проблемы, они могут выстрелить, лучше их не использовать. Вы пишете в комментариях — я использовал и использую, всё ок, не надо бояться. При этом не оговариваете условия использования.
При использовании merge проблема проявляется, при использовании update+insert — нет, но это проблема не merge? Окей. Но тогда в первом вашем сообщении хотелось бы видеть, что кроме умения готовить merge, нужно ещё отказаться от filtered indexes. Может ещё что-то использовать не стоит?
Что касается "автора материала не в курсе" — ну, даже не знаю что тут сказать.
Да, там же описаны воркаэраунды, но, считается ли это предсказуемым и допустимым поведением для mission-critical систем? Как по мне — нет.
Ну да, вы запретили мне их упоминать, пока я не напишу свою без этих проблем.
Да, мне тоже нравится MERGE, он прикольный и удобный, но в критически-важные участки я его без веских причин не потащу — предсказуемость важнее.
Вы писали, что MERGE работает быстрее UPDATE — может быть есть конкретные примеры?
ИМХО, странное предложение. Да репликация сложный механизм, но в ней есть проблемы и приводить её в пример в контексте «у меня с Merge всё работает и у репликации с Merge нет проблем» тоже странно, потому что репликация может привести ко множеству проблем безотносительно того — могу ли я, или кто-то другой, сделать лучше.
известная своей беспроблемностью)?
И сколько потом все эти индексы и констрейнты снова строились?
Вообще, интересно — это часть стандарта или нет? Для MS SQL Server — это процитированное утверждение ложно, обращаться к столбцу по псевдониму в GROUP BY в нём нельзя. SQL Bolt и Towads Data Science, без привязки к СУБД, тоже говорят о том, что GROUP BY «выполняется до» SELECT. А PostgreSQL позволяет такое, MySQL, видимо тоже.
Насколько я понимаю ситуацию с columnestor'ами — размер сегмента не ограничивается (хотя не знаю не пытается ли он сегмент целиком прочитать и что будет, если не сможет), но в памяти больше чем 352 МБ «держаться» не будет. Причём ограничение там на экземпляр, т.е. несколько DWH-запросов в разные БД могут сильно конкурировать за память.
Спасибо за статью. Имхо, стоит добавить, что и для columnstore индексов, и для in-memory oltp в express edition даже более смешные ограничения, чем на всё остальное.
upd: Увидел, что про ограничения для columnstore написано, сорри.
Даже в вашем эксперименте это starting value вполне неплохо себя показывает. Сделаете таблицу в 4 раза больше и, вероятно, разница на сканах тоже не будет столь заметной.
Конечно было бы здорово иметь столько ОЗУ, чтобы туда влезало всё, что нужно. И, конечно, рекомендации — это всегда что-то усреднённое, подходящее не всем, но они дают хоть какую-то отправную точку.
Что интересно, как раз для индексов — рекомендации о размере shared_buffers в 1/4 ОЗУ вполне себе работают. При поиске по индексу разница во времени выполнения не велика.
Вот для скана проигрыш на рекомендуемом размере очевиден, но, неочевидно, будет ли при реальной нагрузке картина такой же.
Поскольку статья называется "Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS", расскажите, пожалуйста, при каких операциях SQL Server использует чтение блоком 4k?
Это неправда, начиная с SQL Server 2017 можно делать Availability Group без кластера. В такой группе. ЕМНИП, не будет авто-файловера, точно не будет listener'a (придётся менять строку соединения приложения, при смене мастера), но это будет Availability Group и реплики могут быть доступны на чтение.
Было бы очень интересно увидеть как измерялась нагрузка от бэкапа и её влияние на производительность/отзывчивость системы в целом.
По ссылке, несколько я понял, всё равно под капотом используется backup log, как минимум. Не очень понимаю зачем делать бэкап без использования ключевого слова бэкап.
Предполагаю, что со снапшота ФС можно снять копии файлов данных и ЖТ, и оно потом заведётся.
Честно говоря не очень понял вопрос. Какой выводимой информации? В blocked process report WaitResources выглядят одинаково в 2012-2017, в 2019 не смотрел. Описанное в посте, вместе с physloc, lockres точно актуально для sql server 2012-2017.