Comments 66
Насколько я знаю, Microsoft SQL Server стоит очень дорого. Интересно было бы узнать, какие ключевые преимущества есть у него по сравнению с другими распространенными серверами баз данных, в том числе доступными бесплатно?
Легко интегрируется с MS Office.
Чистых преимуществ у MSSQL не так много, но если компания в целом широко использует MS-стек, то порой нет смысла переходить на другие бд. Что-то типа SQL Server Reporting Services, Power Bi и тд. Можно всю инфраструктуру перевести на Linux, без получения зоопарка операционных систем.)
Не надо покупать дорогой windows server.
в том числе доступными бесплатно?
MSSQL это продукт класса Oracle, DB2 и т.п. а доступные бесплатно - это не полные аналоги таких БД
p.s.приемуществ не назову, я далек от БД корпоративного класса, только чуть с ораклом пересекался
стоит очень дорого.
Это несущественный аргумент в том секторе где он применяется, его конкуренты стоят или также или дороже
Ну лично мне кажется их T-SQL очень удобным.
Если сравнивать с постгре, то у майков все интуитивно понятно.
Ещё оптимизатор очень хороший. Как пример, Я слышал, что в PostgresSQL долгое время были (пофиксили или нет?) проблемы с "проваливанием" WHERE условий внутрь nested view и под запросов - в MSSQL это работает с 90х годов.
Можно какой-нибудь пример?
Переменные в запросах, конечно, очень хороши. Но если в постгресе писать процедуры, то разницы почти нет. С другой стороны, MS SQL не умеет генерить временные ряды без извращений.
Если не использовать рекурсию в cte, и ограничиться только t-sql, то да, такие запросы чертовски тяжело понять. Я делал так только пару раз и то потому там нельзя было дописать option maxrecursion, но нормальная практика всетаки в этом случае это использование managed кода
Держите магию.
select value from (select row_number() over () as value from sys.objects cross join sys.objects) as t where value < @your_number
В таком виде, наверное, не сработает,пишу по памяти с телефона, но общий смысл должен быть ясен. Если чисел не хватит, можно ещё кросс джойнов добавить, за эталон взяв пустую базу, как базу с минимальным количеством объектов.
Не все там так интуитивно) Если мне не изменяет память, в табличных функциях есть прикол с тем что нужно описать возвращаемую таблицу.. но при этом нельзя использовать для этого табличные типы, хотя это просто очевиднейшее решение.
Можно начать отсюда: SQL Server as key-value store versus Redis
Он быстрее, надёжнее и проще в эксплуатации. Почитайте у @Tzimie про большие нагруженные базы в MSSQL.
Сквозная отладка в продуктах стэка МС. Отлаживая микросервис на локальном ноуте можно по step into попасть на удалённый сервис, а оттуда в код хранимки на сервере БД и поотлаживать его.
Можно прямо в процесс СУБД интегрировать свои сборки на дот нете
боюсь что БД выбирают далеко не по показателю удобства программистов ;)
прошу прощения, а если переписать этот механизм на Раст, поидее будет безопаснее отлаживать по step_into наверно
Можно прямо в процесс СУБД интегрировать свои сборки на дот нете
Я как dotnet программист чертовски не люблю использование managed кода процедур или функций. Это резко сужает круг тех кто понимает "что тут блт происходит"
Я как разработчик БД на MS SQL ещё больше не люблю использование managed кода процедур, т.к. утечка памяти в таком коде нормально не дебажится и в непредсказуемый момент кладёт сервер с высокой вероятностью на всех версиях, на которых я работал с managed кодом.
Попытка запихнуть в базу то, чего там быть не должно, часто заканчивается плачевно.
Он хотя бы бекапится из коробки четырьмя разными способами, а потом из них даже восстанавливается.
Постгрес тоже неплохо бэкапится "из коробки" (если "коробкой" считать прописывание pg_dump в crontab пользователя postgres), и даже восстанавливается, и даже на другую версию (из двоичных дампов не пробовал, но из текстовых - в десятках разных проектов). Другой момент, что создание always-on кластера в PG было сопряжено с разными шаманствами, но я не DBA, а просто "админ широкого профиля", в такие дебри не забирался =)
Начнем с того, что pg_dump – это не бэкап. pg_dump'ом Вы сделаете копию базы только для этого инстанса, без списка ролей, табличных пространств и глобальных объектов. Т.е. (простыми словами) сделав pg_dump на сервере foo Вы имеете ненулевую вероятность того что "бэкап" не восстановится (да даже просто не проверите целостность сделанного бэкапа) на сервере bar. Также pg_dump не умеет в инкерментальные копиии. Для настоящего бэкапа в PostgreSQL испольхуют pg_dumpall и (или) pg_basebackup. Но есть нюанс™ – эти две утилиты бэкапят все базы из инстанса без разбора.
Как уже написали, дамп базы - не совсем то. Дифференциальный бекап вы не сделаете, и логами до нужного момента не догоните. Бекап бинарный, с компрессией, внутри него не данные таблиц, а страницы базы данных. Плюс портабельность базы, здесь detach, там attach, и бекап не нужен.
Он хотя бы бекапится из коробки
Это ведь шпилька в адрес какой-то из свободных СУБД? Можете для тех, кто не в теме рассказать подробней, в чём проблема с бэкапами в PostgreSQL/MySQL?
Как сделать backup базы данных postgresql из коробки?
Через zfs snapshot — это из коробки? Если что, вопрос не риторический был, мне искренне интересно, какие там подводные камни.
Вот вы сделали снэпшот, а дальше?
Это не из коробки (не средствами postgresql), и это не бекап (а снепшот файловой системы). Всё равно что в винде сделать persistent vss snapshot и забрать оттуда файлы. База даже скорее всего будет консистентной, если отработает vss writer, но это всё же не бекап.
Бекап - когда вы пишете:
BACKUP DATABASE [MYDB] ....
А восстановление
RESTORE DATABASE [MYDB] FROM DISK=...
при это можете сделать первое восстановление, и продолжить из другого файла:
RESTORE DATABASE [MYDB] FROM DISK= WITH NORECOVERY
Можете восстановить, перевести базу в Read Only и посмотреть внутри, всё ли вас устроило?
RESTORE DATABASE [MYDB] WITH STANDBY = N'D:\MSSQL\DATA\MYDB_STANDBY01.tuf'
А если не устроило, догнать её вперед логом:
RESTORE LOG [MYDB] FROM DISK = N'D:\MYDB_2024210090041.trn' WITH FILE = 1, STANDBY = N'D:\MYDB_2016120816_7.tuf'
Поверьте, если не обсуждать цену, то с точки зрения администратора SQL Server - приятная и надежная в работе СУБД, простая в обслуживании, с хорошим инструментарием управления. Например генерация кода T-SQL в Management Studio - очень удобно.
Для примера простой сценарий. База данных 20Tb, прирост в месяц 1%, 200Gb. Задача - обеспечить восстановление базы хотя бы на конец каждого дня. В SQL Server такое задание сделает встроенный wizard за 1 минуту, и вы израсходуете на 7 недельных копий примерно 11Tb пространства.
А, теперь понятно, что именно вы имеете в виду под "бэкапом из коробки".
Поверьте, если не обсуждать цену, то с точки зрения администратора SQL Server - приятная и надежная в работе СУБД
Да я даже не спорю. Мне было интересно, что вы имеете в виду под проблемами с бэкапом, а вы, кажется, решили, что я заранее с чем-то не согласен.
Это не из коробки, и это не бекап
Ну, это почти из коробки (apt install zfsutils-linux). Но вообще, я имел в виду, что для PostgreSQL это штатный способ бэкапа, прямо одобренный в документации (с оговоркой "если вы доверяется реализации атомарных снапшотов в файловой системе").
Мне очень нравится этот подход: он определяет границу, после которой с бэкапом базы можно работать как просто с любыми файлами. Это сильно уменьшает количество магии в процедуре, увеличивает понимание происходящего и позволяет действовать привычным инструментарием.
Задача — обеспечить восстановление базы хотя бы на конец каждого дня
Я сам такие большие базы не поднимал, но если рассуждать теоретически, подход с ZFS должен отлично показать себя в таком сценарии: снапшоты создаются быстро, не дублируют старые данные, а переиспользуют общие блоки, поэтому эффективность хранения будет очень хорошей. И можно спокойно удалить любой снапшот, на консистентность оставшихся это никак не повлияет. И после того, как снапшот создан, он уже иммутабелен, можно не торопясь отправить его файлы в холодное хранилище любым удобным способом (в другом комментарии я предлагал для этого restic).
Есть, конечно же, и недстатки, но мне кажется, для многих они не особо критичны:
Снапшотится весь инстанс целиком, не отдельная БД.
Чтобы восстановиться из снапшота, придётся ненадолго остановить постгрес.
У меня консоль сказала что нет такой команды на сервере. А постгресс есть.
pg_basebackup, потом tar
Если хочется сделать бэкап только одной из баз - её нужно заранее вынести на отдельный инстанс.
Проблема начинаются если хочется сделать не просто бэкап, а дифференциальный бэкап. Его из коробки и правда не сделать.
Как вы верно говорите, это бекап кластера в сборе, и надо придерживаться схемы один инстанс - 1 база. Рядом стоит инстанс SQL Server, в котором около 1000 мелких баз (еще и с auto close), и он бекапится (и восстанавливается ручками) встроенным заданием, которое даже ротацию обеспечивает. Кто-то настроил 10 лет назад, так и работает.
А к bg_basebackup немного не хватает pg_baserestore, чтобы не возиться с каталогом данных.
Восемнадцатая версия - уже есть dif backup
А потом tar? Давайте поговорим про это когда база 90 терабайт. Вы собираетесь бэкап материализовать а потом упаковывать??? Вот спасибо.
SQL Express абсолютно бесплатный и даёт достаточно щедрые лимиты из коробки. Основное преимущество его в том, что, если вы вошли в зоопарк решений от Microsoft примерно вначале нулевых, когда это было ещё популярно, то вам уже, скорее всего уже не выбраться.
В то время MsSQL был действительно чем-то прорывным и очень удобным. Настолько, что на нём даже писали полноценный Тьюринг-код.
Томик "SQL Server 2000" на 500+ страниц был долго моей настольной школьной книгой. Такого трепета и уважения к базам данных я не испытывал ни до, ни после.
Жаль, что книга оказалась намного лучше самого продукта... Но это уже другая история :)
Каждый выход MS SQL добавляет что-то новое. Сегодня это JSON, Vectors, AI. Бывает что-то из нового исчезает бесследно как StreamInsight например, но в основном всё же приживается. Расширен лимит баз для Express-версии до 50 ГБ (было 10). Давно ждали. Но исчез SSRS, а было удобно. Всё перешло на PowerBI. В CTP и RC альтернативы не было, а как дальше будет не понятно. Написано, что весь SQL Express ADV теперь часть регулярной Express-версии. Логично предположить, что будет какой-то облегчённый PowerBI. Написано так (https://learn.microsoft.com/ru-ru/sql/sql-server/what-s-new-in-sql-server-2025?view=sql-server-ver17)
Выпуск Express теперь включает все функции, ранее доступные в выпуске Express с расширенными службами.
С другой стороны, про консолидацию SSRS в PowerBI сказано, что только Enterprise и Standard (https://learn.microsoft.com/ru-ru/sql/reporting-services/reporting-services-consolidation-faq?view=sql-server-ver17).
C MS SQL скучно не бывает. Будем посмотреть...
В 2025 версии они повысили лимит размера базы SQL Express с 10 ГБ до 50 ГБ. Хороший подарок!
Скажите, а SQL Express всё ещё только одно ядро процессора использует?
Вроде 4 уже разрешены
Это уже очень давно не так (и, возможно, никогда такого не было).
2016-м сервере уже было "lesser of 1 socket or 4 cores"
В Express еще нет параллельных планов выполнения 1 запроса. Но это, как правило, "слава богу", т.е. наоборот на полных редакциях периодически приходится max_dop ограничивать.
Дорого, но ощутимо дешевле остальных.
Чаще всего выбора не было. К нужному ЛПР приходит вежливый молодой человек, зовет к себе на яхту, где без лишних ушей поясняет, что если ли тот внедрит вот это решение на своем предприятии, у него волшебным образом возникнет отель в хорошем месте Европы, например... Дальше решение продавливается всеми правдами и неправдами на реактивной тяге. Видел живой пример, и это даже не гос, чистый забугорный частник - ЛПР получил "от хорошего друга" небольшой отель и дом в Австралии за успешное внедрение на группу заводов конски дорого промоборудования сименса.
Мало кто покупал большие коробочные продукты, потому что была осознанная необходимость в них. Чаще их впаривали "нерыночными методами". Плюс это кровавый ынтерпрайз с хорошей поддержкой и экосистемой, аналогов которого буквально 1-2 штуки.
Он дорогой, но корпораты часто берут именно за предсказуемость и поддержку. MS SQL стабилен, много лет обкатан под высокие нагрузки и хороший по части безопасности. Но для большинства проектов реально хватает того же Postgres
После перехода с MS на PG развернуть эталонную копию превратилось из секунд (до минуты) до около получаса на одной и той же базе.
Это нельзя напрямую сравнивать, одно хорошо для одного другое для другого. Ну например как ауди седан сравнить с нивой. И у того и у другого 4 колеса, руль и бибикалка. И кто-то может сразу сказать ну это несравнимо, но я посмотрел бы на вас на этой ауди весной в сибири.
МС кстати стоит не так чтобы дорого (давайте сравним с ораклом и их весёлыми новыми лицензиями). А получаете за эти деньги гарантированную поддержку. Да, эта поддержка счас индусы и пробиться к нормальному спецу обычно нужно около месяца, но компании как правило оценивают то что их проблему решат (или заявляют что решат), а не будет "ну не знаю, я ставил и у меня работает".
Опять же возвращаясь к машинам - это просто удобно. Ты точно знаешь, что если так написано, то оно так и будет работать и тебе не надо спускаться до несчастных .h файлов пытаясь понять какой параметр заваливает это всё добро. Ну для примера, зная вот эти приколы никсов, я взял дистрибутив астры и дистрибутив постгре, поставил на виртуалке, протестировал конфиги, сделал абсолютно тоже самое у заказчика, но там скрипты архивации с валом работают не так. В чём разница? Да хз, цветок-цветок, фрукт-фрукт.
Это очень удобно, потому что отвязывает от винды при разработке.
История о том, как мелкомягкие украли взяли наработки изначально мультиплатформенного Sybase, выпустили под своим именем SQL Server только под виндой, а теперь снова пришли в *nix, потому что винда в качестве сервера больше никому не нужна не пользуется спросом.
Вообще-то SQL Server 6.5 вполне себе существовал и для Novell Netware (на секундочку это середина 90-х). А так да, с 7 версии Microsoft сказал, что свой SQL Server будут пилить Windows only. И тянулось это до 2017 года.
Вообще-то на сегодняшний день главная ставка у микрософта на клауд, учитывая что у них вообще свой есть - Azure, слыхали? (в отличии кстати от всех конкурентов среди субд) Так я вообще не очень понимаю зачем им вкладываться не в облачные версии
Похоже, SUSE у них просто вылетела по остаточному принципу. Трафик ушёл в RHEL и Ubuntu, вот они и сфокусировались
Если взглянуть на проблемы базы данных шире, то скорее всего концептуально они уже в большей мере трансформировались в некий большой роутер нежели то для чего они изначально были задуманы. То есть вряд ли имеются потребности писать код SQL с уровнем вложенности условий с десяток и хитрым акртангенсом от даты рождения регистрируемого юзера. На первый план выходит ограничение пропускной способности канала, масштабируемость с резервируемостью и простотой обращения с обслуживанием. Скорее всего это превратится в некий агрегат микросервисов с оптимальным распределением данных за счёт кеширования и хеширования, включая алгоритмы на основе нейросетей, индексацию сжатой информации. Скорее всего это будет некий asyncio с объектным хранилищем с дополнительными атрибутами свойств, включая поведение предикатов, фактически, имитируя SQL на уровне байткода, и являющийся расширением языка общего назначения. Потому как если взглянуть на состав трафика из 90-х и тот что сейчас, то получается что БД уже без буквы Б, то есть смысл структурирования человеком уже уходит на второй план.
Embrace, Extend, Extinguish, говорите?..
В начале 90-х выбирал платформу для своего первого интернет-магазина. К этому моменту довольно плотно сидел на Microsoft и понял, что это приводит к очень большому расходу времени и денег.
Microsoft непрерывно выкатывал обновления API, каждый год нужно было покупать новый MSDN, MS Visual Studio и изучать все заново. При этих обновлениях каких-то особых прорывов в функциональности не ощущалось, и часть API всегда была не документирована.
А после известного "No more VBX Controls" как-то совсем расхотелось и дальше сидеть на игле Microsoft)
Очень рад что избавился от Vendor lock-in, перейдя на платформу Linux!
Microsoft назвала внедрение SQL Server в Linux «феноменальным» и прекратила поддержку дистрибутива SUSE