Какую версию SQL Server использовать?

Материал является переводом статьи «Which Version of SQL Server Should You Use?».

Прежде чем в очередной раз установить SQL Server, подумайте. Вы уверены насчет версии? Я знаю, руководство хочет оставаться на старой версии, и вендоры приложений говорят, что поддерживают только старые версии SQL Server, но теперь вы можете найти аргументы для новой версии.

Мы начнем издалека и посмотрим, что полезного было в каждой из версий.

Возможно, вам следует установить SQL Server 2008, если ...

• У вас древнее приложение, которое больше не поддерживается вендором.
• У вас есть лицензия только на SQL Server 2008, так как вы не купили Software Assurance, что дало бы вам возможность использовать бесплатно новые версии.
• У вас только Standard Edition и вам нужна поддержка неограниченной памяти (это убрали в 2008R2).
• Вы не знаете, что и SQL Server 2008, и SQL Server 2008 R2 (который вышел примерно через два года после) имеют одинаковый срок окончания поддержки (хотя, теперь вы это знаете, так что это уже не причина).
• Вы не знаете, что расширенная поддержка прекратилась 9 июля 2019 года. Да, если вы используете SQL Server в Azure, то Microsoft предоставит вам расширенную поддержку до 2022 года.

Из-за срока окончания поддержки я не сторонник новых инсталляций SQL Server 2008. Так что, давайте двигаться дальше.

Вам нужен SQL Server 2008 R2, если ...

Вам нужны новые возможности, добавленные после SQL Server 2008:

• PowerPivot for Excel (который был заменен);
• Utility Control Point (которым никто не пользуется);
• Master Data Services;
• StreamInsight.

Э-э ... Давайте пропустим эту версию и продолжим.

Вам нужен SQL Server 2012, если ...

• У вас приложение, которое поддерживает только SQL Server 2012, но не 2014 или более новый.
• Вы абсолютно не склонны к установке обновлений (потому что SP4 вышел в октябре 2017 года, и с тех пор было только одно исправление безопасности, и все).
• Вы не прочь через 2 года обновить SQL Server (потому что поддержка заканчивается в июле 2022 года).
• Вам либо не нужно шифрование резервных копий, либо для этого вы готовы купить сторонний инструмент.

В 2012 было представлено несколько новых возможностей: Availability Groups, Columnstore indexes, Contained databases, Data Quality Services. Но в то время они были настолько ограничены, что сегодня сложно считать эту версию хорошим началом для использования этих технологий.

Вам нужен SQL Server 2014, если ...

• У вас приложение, которое поддерживает только SQL Server 2014, но не 2016 или более новые.
• Вы хотите использовать Always On Availability Groups (но я уже даже не решаюсь написать, что AG были значительно улучшены в последующих версиях). Я бы счел эту версию минимальной для рассмотрения AG (забудьте про 2012), потому что начиная с 2014, вторичный сервер доступен для чтения.
• Вам нужно шифровать резервные копии, и вы не хотите покупать сторонние инструменты резервного копирования.
• Вы используете log shipping (доставку журналов) в качестве инструмента для отчетности, и у вас есть хитрые требования к правам доступа. В 2014 появились новые роли уровня сервера, которые облегчают эту задачу.
• Вам нужно улучшить производительность, но без изменения кода. И есть много времени для тестирования. Вам помогут изменения в Cardinality Estimator (CE), хотя и не для всех запросов. Все равно придется потратить время, чтобы найти медленные запросы и подумать, что с ними можно сделать.

В SQL Server 2014 также было представлено несколько технологий, которые уже никого не удивляют сегодня: In-Memory OLTP (непригодный для использования в то время), Buffer Pool Extensions, файлы данных в Azure blobs, резервное копирование по URL и Delayed Durability.

Вам нужен SQL Server 2016, если ...

• Вы являетесь независимым поставщиком программного обеспечения (ISV). В 2016 SP1 множество Enterprise-функций стали доступны в редакции Standard. Это означает, что вы можете разработать одну версию приложения, которое работает как для небольших клиентов с редакцией Standard, так и для больших с редакцией Enterprise.
• Вам нужен известный и хорошо документированный продукт. Довольно легко найти готовые обучающие материалы и нанять людей, которые знают, как использовать инструменты этой версии.
• Вы используете Standard Edition, потому что он поддерживает 128 Гб оперативной памяти (и даже может выйти за рамки этого для некоторых внутренних нужд, например, для планов запросов).
• Вы не хотите обновляться до 2025–2026 годов. У этой версии срок поддержки дольше, чем у SQL Server 2012/2014, так что вы сможете продержаться на ней дольше.
• У вас есть требования по соответствию (compliance) для нового приложения. Я специально говорю здесь о новых приложениях, т.к. в SQL Server 2016 добавлены Always Encrypted, Dynamic Data Masking, Row Level Security и Temporal Tables — технологии, которые облегчат вам защиту данных. Защита данных все еще остается непростой задачей, но становится легче.
• Вы хотите использовать columnstore-индексы. Это минимальная версия, с которой их можно использовать, потому что они стали обновляемыми и могут иметь индексы columnstore и rowstore в одной таблице. Здесь отличное сравнение того, что изменилось в columnstore за эти годы.
• Вам нужен мониторинг планов запросов, и вы не можете позволить себе сторонний инструмент. Query Store предоставляет вам довольно интересные возможности. Хотя его не используют так часто, как хотелось бы. И если бы завтра я снова стал фултайм DBA, то первое, что я бы стал изучать - это Query Store (и PowerShell).

Вам нужен SQL Server 2017, если ...

• Вы готовы устанавливать обновления каждые 30-60 дней, потому что для новых версий, таких как эта, обновления выходят часто, и они исправляют некоторые существенные проблемы. Пройдет время, прежде чем выйдет 2019 и обновления 2017 будут выходить реже (помните, что больше нет Service Pack, только Cumulative Updates).
• У вас есть цель с нулевым RPO (время восстановления) и финансовые риски. В 2017 для Always On Availability Groups добавлен новый параметр minimum commit replica, который позволит вам гарантировать, что несколько реплик получили коммиты.
• Вы хотите, чтобы будущие обновления были проще. В 2017 появились распределенные группы доступности (Distributed Availability Group) с различными версиями SQL Server в ней. DAG сегодня не слишком надежен и хорошо документирован, но мне нравится эта идея, в качестве задела на будущее, для более легкого обновления. (До этого обновления AG были абсолютно ужасны, и зачастую вместо обновления проще было построить новый кластер и мигрировать на него.)
• Вам нужны высокопроизводительные columnstore-запросы. Появилось много интересных вещей для выполнения запросов в пакетном режиме (batch mode).
• Вы решительно настроены использовать SQL Server под Linux. А если серьезно, то просмотрите Release notes for SQL Server 2017 on Linux и прочитайте для каждого накопительного обновления исправленные ошибки. Некоторые из проблем с кластеризацией меня действительно шокировали.
• Вы решительно настроены на использование машинного обучения и R в SQL Server. Я знаю, что это модно для тех, кто работает с данными, но помните, что вы тратите на лицензии SQL Server от $2000 до $7000 за ядро.

Да, я знаю, я здесь не написал "вы хотите очень известный, хорошо документированный продукт". Но это не потому, что продукт плохой. Просто он относительно новый по сравнению с 2012/2014/2016, и, кстати, гораздо сложнее найти готовое хорошее обучение по таким темам, как Distributed Availability Groups или SQL Server под Linux, а также нанять людей, которые знают, как их использовать.

Это не плохие технологии, это отличные технологии. Просто сейчас они еще на ранней стадии развития, так что сложно получить хорошие практики использования. Не невозможно, просто сложно.

Вам нужен SQL Server 2019, если ...

• Вы хотите максимально возможный срок поддержки — до 2030 года. Разве не было бы здорово не переустановить SQL Server целое десятилетие?
• Вы готовы устанавливать обновления каждые 30-60 дней. Для новых версий, таких как эта, обновления выходят часто, и они исправляют некоторые существенные проблемы (помните, что больше нет Service Pack, только Cumulative Updates).
• Вы готовы учиться через эксперименты, а не через документацию. По мере того как вы доберетесь до новейших возможностей, ваше время на эксперименты и обучение будет увеличиваться.
• У вас нет проблем с тестированием нагрузки и производительности. SQL Server 2019 добавляет много интересных улучшений в производительности, когда вы включаете режим совместимости с 2019. Но это также принесет большие изменения в ваши текущие планы запросов. Если говорить в числах, то 99% ваших запросов станут быстрее, а 1% медленнее. Знаете ли вы, что попадет в этот 1%? И что вы собираетесь делать, чтобы уменьшить снижение их производительности? Вы не можете просто протестировать медленные запросы, вы также должны протестировать и быстрые запросы, чтобы убедиться, что они не станут недопустимо медленными.
• Вы используете много пользовательских функций. SQL Server 2019 может их значительно ускорить , хотя вам стоит это протестировать.
• Вы используете много табличных переменных и можете изменять код — они тоже становятся лучше.

Microsoft сделала ставки на новые технологии: кластеры больших данных (Big Data Clusters), высокая доступность в контейнерах и поддержка Java. Тем не менее, я просто не могу придумать аргументы в пользу того, чтобы сегодня (в декабре 2019 года) установить SQL Server 2019 только ради этих технологий. Если эти технологии вам действительно требуются (а это не просто ваше желание их попробовать), то вы уже должны изучать SQL Server 2019 в своих тестовых лабораториях. И, скорее всего, вы уже используете другие версии SQL Server.

Так какой ответ правильный ?

Когда я смотрю на этот список сегодня, то SQL Server 2017 мне видится довольно подходящим вариантом для большинства. Это хороший баланс новых функций, стабильности и длительного срока поддержки. Сейчас во многих организациях, где люди перегружены работой и не могут обновлять сервера каждый год, я вижу экземпляры SQL Server 2017 с мониторингом того, как идет релиз SQL Server 2019 и планированием его развертывания в 2021 году.