MS SQL сервер

    В прошлом посте я много всего написал про Microsoft, и в основном все не очень хорошее. Но на самом деле это не так. Он просто другой, он просто очень сильно отличается от open source RDBMS с которыми я раньше имел дело. Если образно сравнивать MS SQL с MySQL, то MySQL это как советская армейская машина - типа УАЗ. Относительно простая, все настройки хорошо документированы - но чтобы из изменить нужно лезть в конфиг. В принципе если его прокачать и правильно использовать - то он умеет все то же что умеет MS SQL, но все это разбросано по разным местам и требует тщательной подгонки друг к другу. MS SQL - это как иномарка среднего класса, с автоматической коробкой передач. У тебя есть некоторое количество настроек, аккуратно выведенных на переднюю панель. Ты даже можешь управлять работой MS SQL, но на очень простом уровне. Что-то типа  - переключить коробку в режим "спорт" (OLTP ) или езда по бездорожью с прицепом (OLAP). Правда на самом деле под капотом есть куча  скрытых настроек(а-ля блок управления двигателем), совершенно не документированных, но которые вы можете менять через редактирования ini файлов, но уже на свой страх  и риск. В обем самое то - для комфортной езды сертифицированных админов.

        На последок пару полезных ссылок про MS-SQL Server:

1. http://technet.microsoft.com/en-us/library/hh231298.aspx - детальная информация по конфигурирования MS SQL сервера. Ввиду общей убогости документации Microsoft, найти этот источник удалось далеко не сразу.

2.  http://technet.microsoft.com/en-us/library/hh230806.aspx - информация по настройке Analysis Services. Для тех кто не в курсе - Analysis Services - это как бы реинкорнация MS SQL в теле OLAP

3. Hardware Sizing a Tabular Solution (SQL Server Analysis Services) - о том как рассчитывать требуемый размер RAM для нормальной работы Tabular Models.

4.  Performance Tuning of Tabular Models in SQL Server 2012 Analysis Services

5.  http://technet.microsoft.com/en-us/library/cc280449.aspx - про сжатие данных в MS SQL

6. Data Compression: Strategy, Capacity Planning and Best Practices

7. Про PDW или Parallel Data Warehouse

8. Microsoft White Papers for SQL Server 2012

Go Lang

Вчера нашел одно место в стандартной библиотеке Go( а именно в пакете database/sql), которое можно бы прооптимизировать. Зарепортил им Issue 7086, думал сейчас патч пришлю. Хер там был. Через 2 часа его прокомментировал Дмитрий Вьюков, сегодня с утра Bradfitz уже прислал патч. Оперативно работают ребята, что тут скажешь. Молодцы! В общем решил что перейду на девелоперскую версию - хватит на релизах сидеть.

Про данные, много данных. Или просто DWH

         Раньше мне как-то не приходилось сталкиваться в плотную с Data warehouse. Все с OLTP базами работал,  и прямо скажем OLAP не вызывал  у меня особого интереса.  Но не так давно на голову мне свалился DWH, один из двух наших DWH.  Тот что сделан на соплях. Так что пришлось с разбега окунуться во все это.  

          В общем новый анекдот от Microsoft: in-memory data warehouse. Они похоже реально верят что оперативка является бесконечным ресурсом. И очень дешевым. В MS SQL Server 2012 они всячески продвигают свое новое решение - tabular modeling. Если в кратце - это новый тип моделей, которые работают на  xVelocity(VertiPaq) analytics engine. Они называют его предметом искуства (дословно: state of art), изредка при этом упоминая что это IN MEMORY SOLUTION.  Справшивается - зачем строить решения для бизнес аналитики на in-memory движке ?  У вас в DWH полтора гига данных ?? или может быть целых два ??? По моему DWH это минимум пол терабайта данных. Если у вас их меньше - держите их в OLTP базе и не трахайте мозг себе и другим. Вам больше не нужен DWH. 

          Но когда построением DWH занимаются "менеджеры" они легко ведутся на этот маркетинг.  И компания оказывается в заложниках MS решений, и вынуждена покупать сервера с сотнями гигабайт оперативной памяти, просто для того чтобы все днные туда поместились. Иначе все - перестанет работать игрушка для MD.  Но кто-нибуть подумал что данные в DWH добавляются быстрее чем 64 килобайта в год, как об этом думают в Microsoft.

                Но даже если вы выберете другой тип моделей - multidimensional models или tabular models in DirectQuery mode - не все так хорошо как вы думаете.  Вы все равно остаетесь в заложниках одного сервера.  MS SQL это  SMP решение, и без танцев с бубнами вы не сможете распределить данные по нескольким серверам. Это значит что масштабироваться вы все равно сможете только вертикально - покупать все более и более дорогие сервера. Скажем до 10TB вы сможете держать на одном MS SQL instance, но потом ценник на сервера улетит в небеса. Вообще у Microsoft есть ответ и в этом случай - PWD, Parallel Data Warehouse. Но это уже совсем другие деньги, так сказать.  Хотя они и считают его бюджетным - по сравнению с Oracle Exadata, Teradata - оно конечно выглядит бюджетным, но вообще ценник кусается. 

             А выше идут специализированные аапаратно-программные решения от Oracle, IBM и узко специализированных вендоров. В решениях такого класса самые ресурсоемкие операции - типа сжатия/распаковки данных и маршрутизации данных между нодами реализованы в железе, на FPGA.  Естественно никакая софтовая реализация по скорости с FPGA тягаться не может.

           Но самое парадоксальное что я выяснил - есть open source решения которые могут  успешно конкурировать с решениями от Microsoft/Oracle/Teradata практически во всех сегментах, кроме последнего. Это Hadoop. Бесплатное, работает на дешевых серверах - бери и ездий. Для статистического анализа можно использовать язык R, который стал де-факто стандартом для статистов.  Единственное - runtime для R, который поддерживает параллельную обработку данных в Hadoop является проприетарным. Но я думаю там ценник совсем другого уровня, по сравнения с Oracle/Microsoft.