компьютеры

MS SQL Server на Линуксе

Обещают к 2017 году.

http://www.nytimes.com/2016/03/08/technology/microsoft-opens-its-corporate-data-software-to-linux.html

Забавно. Хотя, вообще, ничего нового в интересе к разным операционным системам у Микрософта нет.

Так, все эти современные Windows 7, 8, 10 -- на самом деле растут из Windows NT. А та растёт из OS/2. В самом начале она так и называлась -- Microsoft OS/2.


Потом Микрософт и Ай-Би-Эм посрались, и дерево OS/2 дало две ветви -- IBM OS/2 и Microsoft Windows NT. Потомков последней мы, собственно, в основном и видим каждый день.

А ещё была менее известная операционная система Microsoft Xenix. Причём это был вполне себе UNIX. Ибо был лицензирован у AT&T и SCO.


Многопользовательская операционная система, со всеми бильярдами и профурсетками, как положено на UNIX. Предполагалась как бизнес-ОС для компаний. Но Микрософт решили, что продукт не принесёт нужной прибыли, и к концу 1980х отказались от его дальнейшего развития.

А теперь, видим, граждане возвращаются к корням. И снова нежно любят Фрюниксы.

А я что? А я целиком "за". Я сомневаюсь, что Микрософт ставят задачу отожрать часть рынка у Postgres -- как самой мощной из бесплатных СУБД для Фрюниксов. Скорее всего, острие этого копья направлено на отжирание рынка у Оракла. И пусть будет больше вариантов нормальных человеческих СУБД на Фрюниксах, и это правильно, и это хорошо.

Это называется дрочить в присядку.

Почему? Нормальный бизнес, проба входить на различные рынки. У всех компаний были и удачные, и неудачные заходы на новые рынки.

Designed to fail. Это как на вегетарианском рынке мясом торговать.

лучше бы они допилили sql server до того чтоб его можно было scale out (блин, не знаю как это правильно перевести)
"Масштабировать".

А что не так с масштабированием сиквела?
может быть все так, но я ни разу не видел удачного решения - по типу как это сделано в Elastic, Solr или в другиx noSql системаx - просто добавляешь shards и все работает
конечно, там везде eventual consistency, им проще

надо будет попробовать еще раз, что-нибудь типа Distributed Partitioned Views или Data-Dependent Routing

Edited at 2016-03-08 03:51 pm (UTC)
А мужики то не в курсе. Впрочем о чём ещё можно говорить с человеком приводящим NoSQL в качестве примера?
ну как бы тоже xранилище данныx

какие проблемы?
eventual consistency меня бы вполне устроило (с обработкой ошибок итд)
Ну, значит, задачи у тебя такие, что устраивает. А кому-то надо строго -- транзакции и согласованность.

Я к тому, что, по-моему, тут сравнение яблок с апельсинами.
ничуть

это просто важная фича, которой сегодня нет в продукте

мс однажды профукало появление интернета, оракл - облачные сервисы; это может быть еще одной версией теx же граблей

люди, делающие большую систему, упираются в бутылочное горлышко плоxо масштабируемой дб

конечно, есть костыли типа микросервисов (каждый со своей бд) но это подxодит не всегда
> это просто важная фича, которой сегодня нет в продукте

Какой фичи сейчас нет в SQL Server? Масштабируемости? IMHO, это просто от неумения готовить. У нас в конторе как-то нормально всё обкручивается.

Если же тебе нужна масштабируемость из серии "нажать две кнопки" -- то, извини, да, этого нет. Как нету ACID в тех БД, которые поддерживают "нажать две кнопки".
буду рад увидеть что ошибался

дано - бд (Sql server 2012) из 60 таблиц, связей между ними довольно много (от 2 до 12 "xвостов" растет из каждой таблицы)

в большинстве таблиц (порядка 50) данные будут изменяться

количество записей в каждой таблице - от несколькиx сотен тысяч то несколькиx миллионов

всего одномоментно с системой будет работать порядка 2000 юзеров

между бд и клиентом (angularjs) сидит web.api 2 + entity framework6

насколько реально масштабировать эту базу?
Реально -- надо смотреть архитектуру приложения.

ЕМНИП (систему дизайнил не я) у нас есть RW мастер-сервер и RO копии через реплицирование. Последние отвечают на запросы клиентов, а все обновления в базе идут через мастер-сервер.

Сделать так, чтобы "все читали и все писали" -- такого да, не сделаешь -- ACID сломается :) Ну, а там, где его нет -- отчего же, можно и так.
<< есть RW мастер-сервер и RO копии через реплицирование >>

да, это стандартный xод
при этом (при большом количестве апдейтов) из RW мастер-сервера получается самое узкое место

о том и толкую

вот когда они смогут соединить два RW мастер-сервера в один кластер, тогда будет им щастье
Microsoft SQL provides multi-master replication through peer-to-peer replication. It provides a scale-out and high-availability solution by maintaining copies of data across multiple nodes. Built on the foundation of transactional replication, peer-to-peer replication propagates transactionally consistent changes in near real-time

Об этом речь?
> вот когда они смогут соединить два RW мастер-сервера в один кластер, тогда будет им щастье

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

И самая главная -- это сложность разрешения конфликтов и потенциальное возникновение аномалий и несогласованности данных. И этот пирожок тоже можно испечь, если хочется, но он будет вкусным только когда обновления достаточно редки.

Мне неизвестна СУБД, где есть ACID и где штатно есть работа в таком режиме, и это рекомендовано производителем -- так и делать.

Даже тот же Оракл.

Во-вторых, ЕМНИП, SQL Server лицензируется поядерно. С горизонтальным масштабированием, таким образом, резко растут затраты на лицензии.

Дешевле и лучше SQL Server, если система подизайнена правильно, масштабировать вертикально. И он очень хорошо отвечает на денежные вливания. Там же главный затык -- скорость диска. Мы используем Fusion-io для хранения данных на мастер-сервере. Стоит конских денег, но работает с такой скоростью, что только свист стоит (скорость чтения вообще какая-то дикая, 2, что ли, гигабайта в секунду). Узким местом мастер-сервер для нас не является. Для нас узкое место -- скорость, с которой присылаются обновления для базы данных от клиентов.

А несколько мастер-серверов... Ну прикинь, между ними пропала связь. И два клиента, пока связи нет, обновят одну и ту же запись на разных серверах. Связь вернулась. И кто прав? Как теперь решать? И ладно если там фигня какая-то типа статуса в социальной сети. А если там финансовые записи? Серьёзные проблемы...

Edited at 2016-03-08 09:33 pm (UTC)
А несколько мастер-серверов... Ну прикинь, между ними пропала связь. И два клиента, пока связи нет, обновят одну и ту же запись на разных серверах. Связь вернулась. И кто прав? Как теперь решать? И ладно если там фигня какая-то типа статуса в социальной сети. А если там финансовые записи? Серьёзные проблемы...
Ну собственно для этого и придумали транзакции: нет связи, не возможно проверить статус записи перед апдейтом - роллбак
Т.е. при обрыве связи вся работа должна встать колом?
Вообще-то да. Потому что наличие транзакций подразумевает, что данные согласованы на ВСЕХ копиях БД. Тут сделать этого невозможно, поэтому база данных тебя обязана послать, когда ты в неё пишешь.
гм, ну давайте подумаем, например вместо того, чтобы положить на твой счет заработанные за месяц деньги сервер этого не сделает, точнее сделает, но так что впоследствии между записями будет конфликт, и так как по мнению банка 10-12000 баксов это мелочевка копеечная, то денег ты так и не получишь.
Или например вместо того, чтоб закосячить таким образом система не даст завершится транзикции из за отсуствия связи с мастер-сервером.
Итак, ваше решение, уважаемый
Какой вариант выберем?
Я вообще-то другое спросил, но походу мы живём в разных эльфийских странах. Отсутствие связи, как по мне, это вполне нормальная ситуация. И когда это превращается в форс-мажор с остановкой всего бизнеса, тогда такая технология просто идёт в пешее эротическое сходу.
Файбер между важными серверами, через которые бегает реально дорогие данные, это такие небольшие деньги, на общем фоне, что вероятнее всего он будет иметь резервирование. Так что да, возможно угол зрения разный.


Когда один сервер в мадриде, второй во Владивостоке, то какой файбер? :) В доке в технете, кстати, именно такая ситуация и нарисована на картинке в статье про p2p репликацию.
между мастер серверами для синхронизации должно быть как можно меньше времени. Причем для большиз баз уже критичны милисекунды. Поэтому их надо ставить в соседнии стойки. И это более критично, чем гонять пакеты вовне черех антарктику . Хотя конечно, если об архитектуре системы думали "эффективные менаджеры" , то может быть что угодно наворочено, не буду спорить.
Не, это конечно круто и всё такое. Но я вот читаю статью про p2p репликацию на технете, а там такое: The preceding illustration shows three participating databases that provide data for a worldwide software support organization, with offices in Los Angeles, London, and Taipei. Поэтому я и говорю что в реальном мире отсутствие связи между географически разнесёнными серверами должно рассматриваться как штатная ситуация, и работа из-за этого колом вставать не должна.
Понимаешь, там в статье всё же куча оговорок.

Вот тот пример с офисами в ЛА, Лондоне и Тайпее -- там же сразу написано, что обновления в базе делаются в один момент только из одного офиса, который работает. Все остальные ничего не пишут, только получают обновления от рабочего сервера.

Сразу писать всё и везде -- не взлетит, там руками надо будет постоянно руками конфликты разруливать.
> Ну собственно для этого и придумали транзакции

Я в курсе :)

Я просто к тому, что тут либо шашечки либо ехать -- либо нам надо транзакции, либо хотим мульти-мастерский кластер.
имxо, у ACID в недалеком будущем проблемы возникнут по-любому (уже сегодня куча компонентов раскидана по облаку, distributed transactions, горячий привет от MTS из 2001 года)

и когда-нибудь реальная ACID транзакция будет дорогим удовольствием - и включаться будет по особому распоряжению; типа разослать команды распределенным серверам, залочить записи, провести транзакцию, разлочить записи

а вертикально - да, мы к этому готовы
Часть и у pg с mysql отожрут, если выпустят express конечно.
Думаю, очень небольшую. MySQL нужен в-основном тем, кому надо простенько и быстренько. Тем, кому надо помощнее, может не хватить ограничений экспресса. ЕМНИП, там же 10 гигабайт лимит. Такой человек уже возьмёт постгрес.
10gb это всё же очень дохрена даже для среднего проекта. Я предсказывать не буду, но разброд и шатание новый качественный продукт таки привнесёт, и это, видать, хорошо :)