Comments 105
К сожалению это пока не Open Source, но последняя версия 17 релиз кандидат похудела сразу на 200 Мб
У них там цельнотянутый шелл visual studio внутри лежит, причём довольно старой версии.
ну и да, нет главного — бенчей, на многогигабайтных базах, и на сложных запросах. вон у меня мускул с базой в пару десятков ГБ вполне себе нормально крутится, порядка 80 строк в секунду пишет в таблички, регулярные выборки с агрегацией (zabbix) — и это все на RAID1 из HDD, по IOPS запас еще приличный. и чего-то мне кажется, что мсскл в таком режиме сложится…
Это такой тонкий троллинг SQL Server'а?
я не могу представить, почему инсталлер весит 2 ГБ (если там нет в довесок IDE либо кучи файлов справки на разных языках). та же постгря весит на порядок меньше… потому и интересуюсь — что в мсскл инсталлере такого особенного?
и да, главной причины попробовать — бенчей, демонстрирующих явное преимущество платного решения в hiload/big data — почему-то в статье нет.
Я не про инсталяр удивлялся, а про
и чего-то мне кажется, что мсскл в таком режиме сложится
По поводу инсталятора — в инсталятор MSSQL зашиты еще помимо самой базы данных различные сервисы SSAS, SSIS и прочие, которых естественно нет по умолчанию в инсталяре PostgreSQL (кстати я так на вскидку не могу назвать аналоги SSIS и SSAS в PotgreSQL, может кто подкинет ссылку?). Они не обязательны к установке и почему их нельзя вынести в отдельные инсталяторы это уже вопрос к Microsoft.
Еще раз повторюсь, я не говорю, что какая-то реляционная база данных лучше других (при прочих равных я всегда выберу PostgreSQL или SQLite для своих проектов), каждая из них отлично решает поставленные перед ней задачи и в зависимости от этих задач предпочтительнее (но ни в коем случае не обязательно) использовать ту или иную базу данных.
Я не про инсталяр удивлялся, а про
и чего-то мне кажется, что мсскл в таком режиме сложится
сугубо на основе ощущений от прочих продуктов, тесно завязанных на экосистему винды. что IIS, что всякое 3rd-party ПО типа Directum производительностью не особо блещут.
По поводу инсталятора — в инсталятор MSSQL зашиты еще помимо самой базы данных различные сервисы SSAS, SSIS и прочие, которых естественно нет по умолчанию в инсталяре PostgreSQL (кстати я так на вскидку не могу назвать аналоги SSIS и SSAS в PotgreSQL, может кто подкинет ссылку?)
после беглого прочтения — возникло чувство, что это сродни конструкторам модулей импорта и анализа для непрограммистов. спорное решение, оптимальностью, уверен, в результате даже не пахнет — хотя может кому-то и сгодится, особенно в махровом энтерпрайзе…
после беглого прочтения — возникло чувство, что это сродни конструкторам модулей импорта и анализа для непрограммистов
SSIS — это конструктор модулей экспорта-импорта для программистов. Движок, который позволяет создавать скрипты заливки и преобразования данных между разными источниками. Есть такой класс инструментов, называется ETL. Это один из их представителей, и пожалуй, один из самых доступных.
С производительностью у него всё в порядке, а вот инструментарий так себе, как по мне, громоздкий и неудобный. Вместо корявого редактора многомегабайтных XML-скриптов там намного уместнее был бы какой-нибудь скриптовый язык.
SSAS — это OLAP-движок, тоже вполне себе хороший. Всё это можно заменить специализированными инструментами, конечно. Но вот в этой сфере с бесплатным опенсурсом как раз довольно туго, решения предлагают в основном крупные вендоры и за крупные деньги. Набор таких инструментов в комплекте с MS SQL в этом плане является весьма приятной плюшкой.
Я ни в коем случае не заставляю, может давно просто прыгали? Последняя версия уже ближе к озеру.
Открыл пост, чтобы написать такой же комментарий, но вы меня опередили )))
но на рынке труда намного больше вакансий с MSSQL
Просто "ещё никого не увольняли за выбор продуктов Microsoft, Oracle и IBM", что наряду с откатами влияет на решения менеджмента.
… и тут мы пришли в linux-сообщество, в белом фраке… Серьезный такой первый аргумент.
ИМХО, вполне годный аргумент. Идеологические войны идут в основном между сисадминами, а директора обычно больше интересуются финансовой стороной. Если какой-то нужный компании продукт требует MS SQL в качестве СУБД, и есть возможность сэкономить на лицензии серверной винды, либо уже имеется Linux-инфраструктура, это может оказаться решающим преимуществом.
Но ведь это не причина, чтобы «попробовать MS SQL прямо сейчас», верно?
Ну так СУБД, это ведь не конечный продукт. Целевая аудитория СУБД — это как раз и есть те пользователи, которые либо производят/продают софт на данной платформе, либо занимаются его внедрением/поддержкой, либо являются покупателем такого софта. Во всех этих случаях предложение «попробовать» вполне уместно. Если вы продаёте клиентам софтину, которая может использовать MS SQL в качестве хранилища, вы вообще один из первых побежите пробовать новую конфигурацию, т.к. от этого непосредственно зависят ваши продажи.
стоимость sql server enterprise 2016: 16300 € за 2 ядра, умножаем на 8, получаем 130400 €.
Вывод: те кто берет sql server на стоимости windows экономить не станут, поэтому цена в данном случае не критерий.
Цены сильно округленные, но общую картину дают. Зачем брать именно enterprise? Потому что именно в этой редакции всё самое вкусное: партиционирование и онлайн перестройка индексов. Без них можно и на постгре данные хранить, если сильно замороченное BI не нужно.
Ну партициорование и онлайн перестройка индексов самое вкусное спорное утверждение, тем более что в SQL Server 2016 с выходом SP1 партициорование входит в стандартную редакцию.
Самое важное отличие редакции для бизнеса (enterprise) от стандартной по моему скромному мнению — это ограничение на использование ресурсов сервера, в стандартной версии они достаточно жесткие для больших баз данных: 4 сокета или 24 ядра и всего 128 ГБ ОЗУ. И именно ограничение по ОЗУ становится самым не приятным моментов ввиду активного продвижения In-Memory OLTP (In-Memory Optimization)
Я вроде ничего сильно кошмарного не припомню.
https://habrahabr.ru/company/etagi/blog/314000/
https://habrahabr.ru/post/280872/
https://habrahabr.ru/post/188096/
https://habrahabr.ru/post/301370/
Оцените количество ручной работы при развертывании. Просто развертывании, планирование оставляем за скобками. По сравнению с «щелк-щелк-щелк, и работает» у MS. И это я даже на комментарии на тему правильности реализации, возможных косяков и т.п. не обращаю внимания. «Так» это или «не так», пусть каждый для себя сам решает. Более того, я и сам могу назвать сценарии, где это неважно. Но читать, что MS SQL — это по сравнению с PostgreSQL «болото», тем не менее, немного смешно.
Неужели в MS SQL (я правда этого не знаю) этот вопрос настолько тривиален, что решается путём «щёлк-щёлк и работает»
Кстати, да. Я был приятно удивлен, но именно так. Правда, несколько лет назад я был неприятно удивлен, что отказоустойчивый кластер MS SQL из двух нод унёс с собой в могилу базы без возможности их восстановления, и пришлось несколько часов всё заново поднимать из бэкапов, но это уже другая история.
Обычно, в форме есть кнопочки генерации SQL команд на основании изменений которые сделаны в форме.
Команды таким образом можно сохранить и использовать как душе угодно.
Зато на виртуалках без жестких требований к RPO можно ничего не настраивать, так как потеряется лишь 600 мс транзакций перед бекапом ВМ без нарушения целостности БД.
Да хотя бы оптимизатор запросов. Вот недавно только всплыло: https://habrahabr.ru/company/ruvds/blog/315766/#comment_9924306
И чем бы мне в той задаче помогло партиционирование?..
Не пойдет, в таблице могут быть незакомиченные вставки — их удалять не надо. Если бы у меня была возможность монопольного доступа к базе — я бы всю таблицу целиком грохнул (после того как прочитал) и пересоздал бы ее заново.
Возможно у вас change_log это не change_log, а что-то для хранения незакомиченных данных. Хозяин — барин.
Задача — простая. Перенести 20 миллионов записей из одной таблицы (в которую параллельно дописывают новые записи) в другую базу.
Разумеется, любая операция записи может проводиться в транзакции, а транзакция проходит не мгновенно.
Хорошо, объясняю подробнее. Есть оперативная БД, есть аналитическая. Нужна ETL-обработка, которая бы переносила данные из одной БД в другую раз в сутки. Для этого в оперативную БД добавили триггеры и таблицу change_log, чтобы отслеживать произошедшие изменения.
Из-за серии ошибок в ETL-обработках они не работали довольно долго, к тому же за ошибками никто не следил (потому что аналитика еще не написана, данные в аналитической БД складируются на будущее), из-за чего в оперативной БД в этой самой таблице скопилось 20 миллионов записей. Когда меня кинули на этот проект — ETL никак не могла перенести записи из-за тайм-аута при получении данных.
Первой попыткой было ограничение числа записей, переносимых за 1 операцию. Это позволило бы в цикле разобрать накопившуюся очередь — и в SQL Server даже сработало бы. Но в Postgres не оказалось способа переносить данные "по частям" не теряя при этом изменения, которые идут параллельно.
Поэтому в итоге пришлось делать отдельные ветки для переноса старых данных и свежих.
- Остановить перенос данных
- Приостановить оперативную обработку (очень ненадолго)
- Cклонировать change_log в другую таблицу (если есть место)
- Очистить change_log (truncate-ом или пересоздав таблицу)
- Возобновить оперативную обработку
- Неспеша перенести клон, обработать его в аналитической БД и дропнуть в оперативной
- Возобновить перенос данных (в change_log накопятся новые данные, но, вероятно (опять не знаю подробностей) немного
Что касается партиционирования, на мой взгляд, оно могло бы помочь в ежесуточном переносе данных. Дропать суточные партиции полюбому легче чем выискивать вчерашние данные в длинном логе.
delete… in (select… limit) продолжаю считать крайне неудачной идеей. Например, не вижу как он поможет с пресловутыми незакомиченными данными. Ну и delete 20 миллионов записей это в любом случае очень плохо. Просто замусоривание REDO-лога (ну или дары богу вакуума в Постгресе)
Так я о том и говорю, что в Postgres нужно делать что-то еще — в то время как в MS SQL довольно простое исправление запроса позволяет ему разбираться с любыми объемами данных.
delete… in (select… limit) продолжаю считать крайне неудачной идеей.
Такой она и оказалась (из-за не очень умного оптимизатора запросов, предпочитающего Hash и Merge там, где нужен Nested Loops).
Например, не вижу как он поможет с пресловутыми незакомиченными данными.
Очень просто — они не попадают в выборку и переносятся в следующий день.
Эта операция не более затратна с точки зрения журналирования, чем создание тех же записей :) То есть с точки зрения амортизационного анализа — delete вместо truncate просто удваивает ресурсы, требуемые для вставки.
Я же говорю про время работы. Merge Join сам по себе неплох — но операция Sort перед ним означает чтение всей таблицы целиком, что не вписывается ни в какой тайм-аут.
При нормальном режиме работы там такого большого количества записей никогда не накопится. А время выполнения разовой операции никому не интересно — пусть хоть месяц крутится, лишь бы количество записей в таблице в течении этого месяца уменьшалось, а не росло.
Вот чтобы не капали на мозги — и надо обходиться без приостановки оперативной обработки :)
Если понадобится — я просто удалю в БД информацию о прошлой выгрузке — после чего следующий запуск ETL автоматически пойдет по альтернативному пути. Это куда проще и веселее, чем пересоздавать таблицу вручную.
Какова сейчас ситуация с MS SQL под Linux? Был снова добавлен уровень абстракции системных вызовов в обратную сторону (SQL->NT->Linux)?
На ваш вопрос довольно подробно отвечено в статье SQL Server on Linux – How I think they did it!
2012: «Кинули» (извините, другого слова не подберу) пользователей SQL Enterprise Server+CAL, даже тех, у кого была подписка на SA: продолжать использовать можно (даже новую версию, если есть SA), но новые CAL (по истечении текущего контракта SA, у кого он был, и немедленно, у кого не было) купить нельзя. Вложены огромные деньги в десятки и сотни лицензий, фирма растёт, а для новых сотрудников купить дополнительные лицензии нельзя. И это ведь не лицензии на непосредственную работу с базой данных, сидит сотня операционистов, заполняет в своей программе какое-нибудь поле, а это поле (даже через 5 промежуточных серверов) попадает в SQL Server — всё, пользователю нужна CAL.
2014: Подняли цены почти в 2 раза, заодно сменив систему лицензирования с per-processor на per-core (то же, что в 2016 сделали с Windows Server). Теперь, купив «безлимитную» лицензию, вы должны докупать ещё по кусочку «безлимита» после обновления сервера, если в новом сервере больше ядер. А как весело в Microsoft смеялись с этой идеи ещё в 2013!
2016: Теперь, простите, «кинули» пользователей SQL Server Business Intelligence (2012-2014). Сценарий ещё хуже, чем в 2012 — можете использовать, но ни новых CAL нельзя купить (несчастным владельцам SA разрешили, с барского плеча, докупить ещё не более 25% CAL), ни новую версию использовать. Формально — можно использовать Enterprise Server+CAL 2016, но она не даёт, насколько я понимаю, исключения из правил мультиплексирования, а без этого исключения SQL BI — бессмысленна. Там, где для SQL 2014 BI нужно пару десятков SQL BI CAL для начальства, просматривающего аналитику, может понадобиться тысяча-другая SQL Enterprise CAL за счёт мультиплексирования, но сколько б их не было надо, их в продаже нет с 2012 года.
Так что покупая Microsoft SQL Server, можно быть уверенным только в том, что назад лицензию не отберут. Можно ли будет завтра докупить лицензий для новых сотрудников, перейти на новую версию, обновить процессор — лотерея, и никакая подписка SA ничего не значит.
Ого, спасибо за развернутый комментарий, много полезной информации. Вы случайно не занимаетесь закупками лицензиями? Если да, и у вас есть немного свободного времени, не могли бы вы кратко описать стоимость покупки лицензий для SQL Server в России?
Подняли цены почти в 2 раза, заодно сменив систему лицензирования с per-processor на per-core (то же, что в 2016 сделали с Windows Server).
Во-первых, модель с Per Processor на Per Core поменялась уже в 2012, а не в 2014. Во-вторых, цены MS, конечно, подняла. Но не вдвое, и не связи с переходом на новую версию. Винить MS в обрушении курса рубля, думаю, всё-таки не стоит. :)
Сам факт плясок с лицензированием я не оспариваю, но остальным читателям всё-таки рекомендую не воспринимать описание проблем выше как истину в последней инстанции.
Про цены я, по географическим причинам, могу говорить только в американских или канадских долларах, курс российского рубля не отслеживаю.
С ними ещё и договариваться можно? Или там с их дилерами?
Вот это штука, которая на первых порах вызывает большой когнитивный диссонанс, что со здоровенной корпорацией можно торговаться больше, чем с магазином одежды. Да, можно. За одну лицензию чего-нибудь вы особых условий себе вряд ли выторгуете, но если вы покупаете большой пакет софта, то плюшек можно получить много.
Вы заявляете, что в официальных Licensing Guides написана неправда?
Откройте, на выбор, любую версию 2012, 2014 и увидите там:
As of July 1, 2012, Microsoft no longer offers the SQL Server Enterprise Edition under the Server+CAL license model. Current customers with active SA coverage for existing SQL Server 2008 R2 Enterprise Edition server licenses should consider the following when transitioning to SQL Server 2012:
● SQL Server 2012 Enterprise Edition server licenses ceased to be available on price lists after June 30, 2012.
● Enterprise Agreement (EA) and Enrollment for Application Platform (EAP) customers with active agreements
on this date can continue purchasing new licenses until the end of their current agreement term.
А вот цитаты из документа 2016 года:
Existing SQL Server 2016 Enterprise Edition server licenses continue to have tremendous value, and with the
availability of ongoing SA coverage, customers licensed under the Server+CAL model can retain access to the
latest product enhancements and advanced capabilities of Enterprise Edition. As such, there are no
programmatic conversions to core licenses.
…
SQL Server 2014 was the last version of the SQL Server Business Intelligence Edition. Customers with active SA coverage on qualifying Business Intelligence Edition server licenses on June 1, 2016 are eligible to upgrade to and use SQL Server 2016 Enterprise (Server+CAL) software with those licenses.
● During the current term of SA coverage (effective on or before June 1, 2016), customers who are
licensing SQL Server 2014 Business Intelligence Edition can, for a given deployment, upgrade to and use
the SQL Server 2016 Enterprise Edition (Server+CAL) software in place of the licensed SQL Server 2014
edition. Note: Customers who upgrade to SQL Server 2016 software are subject to current version
Enterprise Edition server license product terms. [А условия использования Enterperise Server+CAL не содержат исключения для мультиплексирования.]
● Customers with Enterprise Agreements effective on or before June 1, 2016 can continue to acquire
additional SQL Server 2014 Business Intelligence server licenses—and upgrade those licenses to SQL
Server 2016—through the end of their current enrollment term, as long as the number of new licenses
acquired does not exceed more than 25% of the number of qualifying licenses acquired as of May 1,
2016.
Мир уже не будет прежним, если на сайте МС пишут такое
Это выглядит странным из-за самого факта наличия MS SQL под LinuxНе вижу ни чего странного, MS давно развивает интеграцию с Linux
+ из-за общепринятой практики установки программ на Windows.А при чем тут установка программ в Windows, когда речь про установку программ в Linux
При том, что это установка программы от MS.
Собственно шок от того, что MS решила стать именно приличным производителем ПО под Linux, не просто софт написали и делайте что хотите и(или) «запустите наш бинарник», а начала полноценно вписываться в экосистему.
В SQL Server 2016 можно с помощью хранимой процедуры sp_execute_external_script
выполнять R скрипты, также Microsoft выпустила собственную версию языка R, которая доступна в 2-х видах — Microsoft R Open (MRO) и Microsoft R Server (MRS).
SSMS становится просто вне конкуренции среди аналогичных коммерческих и бесплатных продуктов.
С выходом DataGrip от JetBrains спорное утверждение.
Да. Теперь по заверениям Microsoft они также хорошо тестируются и готовы для использования на проде как и SP.
Прежде чем использовать это в своем проекте нужно 1000 раз подумать, завтра тебе нужен будет ещё один сервер и цена может опять вырасти в несколько раз.
В пункте 2 ссылка на статью где этот вопрос подробно разобран со ссылками на Microsoft: https://www.littlekendra.com/2016/07/12/is-user-acceptance-testing-covered-under-developer-edition/
Customers cannot use the software in a production environment, and any test data that was used for design, development or test purposes must be removed prior to deploying the software for production use.
So be very careful if your User Acceptance Testing environment is used to “stage” data that is later restored to production. Per the 2014 rules, that is a production system.
В общем тестировать можно, главное не использовать потом для восстановления на проде.
Еще из приятного — ставите галку установить R Server — на этапе установке инсталлер запросится в интернет. Надо откатываться назад до этапа конфигурации убирать галку и снова с песней.
После этого говорить о том, что это делается для корп окружения (которое с самого начала кремния сидело за прокси), наверное рановато.
Там это где? В SQL Server 2016 или в SQL Server VNext под Linux? В SQL Server 2016 все хорошо, VNext под Linux пока нет возможности протестровать, возможно кто-то уже опробовал в корпоративной среде?
10 причин почему именно сейчас стоит попробовать Microsoft SQL Server