Рэляцыйныя базы дадзеных, структураваныя па вызначаным алгарытме дазваляюць аператыўна кіраваць і кантраляваць большасць працэсаў інфармацыйных сістэмах па ўсім свеце. Кампанія Microsoft распрацоўвае рашэнні для працы з базамі дадзеных з 1988 года. Першая версія СКБД MS SQL Server 1.0 з'явілася 29 красавіка 1989 года.

З рознай перыядычнасцю карпарацыя Microsoft мадэрнізавала SQL Server, былі прадстаўлены версіі 7.0, 2000, 2005, 2008 і 2008 R2. Пачынаючы з версіі MS SQL Server 2012 з'явіліся новыя фічы, якія значна палегчылі працу з базамі дадзеных, мадэрнізавалі бізнес працэсы. У апошніх версіях SQL Server з'явіліся зручныя інструменты, як Business Intelligence (BI), для бізнес-аналітыкі, з'явіліся абноўленыя, удасканаленыя інструменты Management Studio, у тым ліку сродкі для працы з хмарнай асяроддзем SQL Azure. Усе інавацыі былі ўключаныя ў новы рэліз MS SQL Server 2014. Аб новых магчымасцях MS SQL Server 2014, выгодзе штодзённай працы, спрошчаных працэдурах сінхранізацыі, размеркавання нагрузкі і павышэння надзейнасці распавёў праграміст, аналітык кампаніі Softpoint, Аляксандр Дзянісаў.

- Добры дзень Аляксандр, дзякуй, што надалі час.

Добры дзень.

- Раскажыце, якія перадумовы развіцця ІТ, для з'яўлення MS SQL Server 2014?

Галоўная перадумова, галоўная інавацыя, якая з'явілася менавіта ў SQL Server 2014, гэтае рашэнне праблемы прадукцыйнасці OLTP, сістэм апрацоўкі анлайн транзакцый. Справа ў тым, што апошнія, мабыць, гадоў 20, асноўны ўпор у развіцці SQL сістэм быў зроблены на тое каб хутка атрымаць дадзеныя, зрабіць якія-небудзь справаздачы, перакампанаваць дадзеныя і атрымаць нешта цікавае. Зараз зразумела, што дадзеныя мы можам здабываць досыць хутка, а вось у працэсе вялікага інфармацыйнага патоку могуць узнікаць праблемы.

Ну і, уласна, галоўная інавацыя ў SQL Server 2014 - гэта спецыяльны новы рухавічок, які дазваляе аператыўна абслугоўваць масіўныя патокі ўводу інфармацыі. Гэта сотні аператараў або вялікае кол-у падключэнняў з сайтаў: інтэрнэт-крамы, рытэйл-розніца, склады і т.п. Нарэшце-то, высоконагруженных інфармацыйныя сістэмы атрымалі падтрымку. Тут трэба адзначыць, што выйгрыш ад ўкаранення In-Memory OLTP пачынаецца ў базах дадзеных аб'ёмам ад 200 Гб. Калі база менш 200 Гб, то ў вас, хутчэй за ўсё, няма такіх аб'ёмаў, дзеля якіх была б мэтазгодная міграцыя на новы рухавічок.

- Калі праецыраваць на кол-ць карыстальнікаў або зваротаў, праведзеных дакументаў?

Вядома, аб'ём - гэта хутчэй ўскосная велічыня. У першую чаргу варта арыентавацца на інфармацыйны паток. Гэта значыць, мы зараз можам пачаць працу з базай 10Гб, а праз месяц яна вырасце да 50Гб. Фармальна мы не трапляем пад крытэрыі, але, аналізуючы, мы разумеем, што гэта менавіта той выпадак, калі неабходна ўкараняць гэтыя тэхналогіі, так як інфармацыйны паток значна павялічваецца ў досыць кароткі прамежак часу. Груба кажучы, ад 150-200 карыстальнікаў, адначасова актыўна працуюць з базай менавіта на ўвод дакумента. Зразумела, што карыстальнік карыстачу розніца. Хтосьці актыўна заносіць у базу першасную бухгалтэрыю, а хто-то выгружае нейкія цяжкія справаздачы. Гэта значыць, адзін аналітык з запытам цяжкага справаздачы супастаўны прыкладна з дзесяткам простых аператараў, таму што ў яго запыты значна аб'ёмнымі, цяжэй.

Па дадзеных Microsoft (www.microsoft.com/ru-ru)

- Якія ключавыя адрозненні MS SQL Server 2014 ад больш ранніх версій?

Самая галоўная ключавая тэхналогія - гэта новы рухавічок. Тое, што раней, у Community Preview называлася Hekaton. Зараз гэты рухавічок проста называецца In-Memory OLTP, то ёсць сістэма апрацоўкі анлайн транзакцый. Праца з дадзенымі пры гэтым адбываецца цалкам у аператыўнай памяці. Гэта зусім новы рухавічок апрацоўкі дадзеных, які сфакусаваны на тым, што ўсе дадзеныя захоўваюцца выключна ў аператыўнай памяці. Натуральна, усё гэта разлічана на сур'ёзныя сістэмы, якія працуюць 24/7 і практычна ніколі не выключаюцца. Серверы працуюць пастаянна. Як толькі сервер выключаецца, напрыклад, адбываецца пазаштатная сітуацыя - адразу ўзнікае праблема страчанага часу, бо патрабуецца зноўку разгарнуць і падрыхтаваць сістэму. Адпаведна, такі доўгі запуск робіць тэхналогію неўжывальныя да сістэм, якія, груба кажучы, ўключаюцца ў 8 раніцы, калі першы бухгалтар прыходзіць. Гэты новы рухавічок аптымізаваны менавіта на хуткае атрыманне даных, на хуткую апрацоўку і хуткую выдачу, то ёсць сфакусаваны на тым, што дадзеныя практычна не запісваюцца на жорсткі дыск, а захоўваюцца ў аператыўнай памяці, з гэтага вынікаюць новыя прыёмы працы, новыя прынцыпы, якія адрозніваюцца ад таго, што было раней, ад таго да чаго прывыклі праграмісты.

- аб'ём аператыўнай памяці павінен быць больш?

Натуральна, трэба зыходзіць з таго, што ўсе гэтыя аператыўныя дадзеныя з якімі сістэма збіраецца працаваць, павінны змяшчацца ў аператыўнай памяці. Гэта значыць, нядаўна быў падыход такі: захоўваць дадзеныя на цвёрдым дыску, прачытаць хутка маленькую порцыю, якая патрэбна для аператыўнай працы, апрацаваць яе ў аператыўнай памяці і адправіць назад на жорсткі дыск. Аператыўная памяць была «маленькім акном» для тых дадзеных, якія падаюцца прама цяпер. У новай версіі «аператыўка» лічыцца асноўным сховішчам інфармацыі, усе дадзеныя In-Memory OLTP захоўваюцца менавіта ў аператыўнай памяці. Таксама трэба зыходзіць з таго, а якая ў нас табліца 2, 4, 10 ГБ? Яна ўся павінна там змяшчацца. Пры гэтым мы гаворым толькі пра адну табліцу, аптымізаваную для працы ў памяці, і трэба не забываць, што старыя табліцы - гэта амаль 90% усяго аб'ёму, на працу якіх таксама трэба закласці аб'ём аператыўнай памяці.

- якія павінны быць характарыстыкі аператыўнай памяці, кэш, частата?

Звычайная серверная аператыўная памяць. Гэта значыць для сервераў гэта ўжо даўно ўсё прыдумана, аператыўка з кантролем памылак, павялічаная хуткасць. У прынцыпе, калі ёсць нейкія праблемы, сістэма не паспявае, можна падумаць аб паскоранай аператыўцы, але звычайнай сервернай аператыўнай памяці павінна хапіць.

- Якая ўзаемасувязь працы з прыкладаннямі, якія новыя магчымасці адкрываюцца з SQL Server 2014?

На самай справе з пункту гледжання механізмаў аналізу дадзеных (Analysis Servises і Business Intelligence) мала што памянялася. У SQL Server ўжо даўно ёсць зручныя магчымасці інтэграцыі з тым жа MS Office.

"Business Intelligence - скарочана BI. Інструмент для перакладу ў зручную, зразумелую форму неструктураваных дадзеных, інфармацыі для аналітыкі бізнес працэсаў. Метад дазваляе вызначыць важныя фактары эфектыўнасці работы, прагназаваць вынік розных шляхоў развіцця."

З новых магчымасцяў можна адзначыць прылады для працы з шматмерным масівамі дадзеных (OLAP-кубы) з дапамогай знешніх сродкаў. Праўда, пад знешнімі сродкамі тут маюцца на ўвазе выключна публікацыі на партале SharePoint. Для ўладальнікаў такіх парталаў гэта сапраўды вельмі цікавая магчымасць - можна фармаваць складаныя справаздачы прама з браўзэра.

- Якія выгады для OLTP сістэм з устаноўкай MS SQL Server 2014?

Самыя галоўныя выгады заключаюцца ў наяўнасці рухавічка In-Memory OLTP, сістэмы апрацоўкі запісы ў аператыўнай памяці. Галоўнае, тут трэба ўлічваць той факт, што спатрэбіцца змяніць, перапісаць частка кода прыкладання, якое працуе з базай дадзеных. Гэта значыць новыя аб'екты патрабуюць іншага падыходу да працы, іншага падыходу да запісу. Напрыклад, няма паняцця блакавання, зусім іншая апрацоўка памылак, але калі ўсё гэта зрабіць, што не так складана, як гучыць, то паскарэнне ў працы можа быць значнае. У Microsoft на стэндах гэта было да 100 разоў, я асабіста на тэстах назіраў паскарэнне раз у 20, у параўнанні з працай звычайных баз, звычайных табліц. Гэта значыць, нейкія крытычныя задачы стаяць таго, каб перанесці на рухавічок MS SQL Server 2014, выкарыстоўваць новыя тэхналогіі, і аддача будзе прыкметная.

- калі разглядаць рост прадукцыйнасці на прыкладзе папулярнай платформы 1С?

Цяпер няма. Як я ўжо казаў, патрэбна падтрымка з боку прыкладнога прыкладання, а калі будзе такая падтрымка ў 1С інфармацыі няма. Усё ж такі 1С забяспечвае працу адначасова з некалькімі рухавікамі СКБД, неабходна падтрымліваць нейкую сумяшчальнасць, пераноснасць прыкладнога кода.

З іншага боку, у платформе 1С ёсць такі аб'ект як «знешні крыніца дадзеных»: можна паспрабаваць звязаць In-Memory табліцу з гэтым аб'ектам, перапісаць логіку працы з вонкавым крыніцай, запаўненне, перезаполнение ... У прынцыпе, гэта складана, але магчыма, праўда на практыцы я такіх рашэнняў яшчэ не бачыў. Пры гэтым выйгрыш абяцае быць істотным. Нейкія крытычныя рэчы, як рэшткі склада ці нейкія дадзеныя, якія змяняюцца аператыўна, можна перанесці на новы рухавічок.

- змены кода прыкладання тыповыя або індывідуальныя?

Змяняецца сам прынцып працы з базай дадзеных. Кампанія Microsoft падрабязна распавядае, што і дзе памянялася. Іншая справа, што для падтрымкі з боку 1С трэба змяняць логіку, якая схаваная «пад капотам»: у праграміста 1С няма настолькі нізкаўзроўневага доступу ў механізмы платформы. Застаюцца альтэрнатыўныя сродкі. Можна ўсталяваць табліцу ў выглядзе вонкавага крыніцы дадзеных без агучаных вышэй абмежаванняў, які падключаюцца, як іншыя аб'екты. Так з гэтым іншым аб'ектам можна рабіць усё неабходнае.

- Якая працэдура ўстаноўкі SQL Server 2014 з нуля?

Уладальнікам старых версій SQL Server варта ўлічыць, што немагчымая адначасовая праца SQL Server 2014 і SQL Server 2005 на адным серверы. У першую чаргу гэта закране нейкіх тэставых сервераў, я не магу ўявіць сітуацыю, калі для працоўных бізнес-сістэм СКБД ня разнесеныя па розных серверам.

У астатнім ніякіх складанасцяў няма. Досыць зручны майстар ўстаноўкі, перад устаноўкай правярае ўсе характарыстыкі сістэмы, калі патрэбна ўстаноўка якіх-небудзь бібліятэк дадаткова, то майстар вызначае і ўстанаўлівае іх. У прынцыпе, у звычайных умовах ўсё зводзіцца да шматразовага націску кнопкі «далей». Таксама можна ўспомніць стандартныя рэкамендацыі, калі ў вас высоконагруженных сістэма, то хутчэй за ўсё вы ўжо ўсё гэта ведаеце. Пазначу, што файлы дадзеных, файлы логаваў транзакцый і файл Temp-DB лепш разносіць па розных дыскаў, гэта значыць максімальна распараллелить працу з дыскавай падсістэмай.

"Temp-DB - сістэмная база дадзеных, глабальны рэсурс, даступны ўсім карыстальнікам, падлучаным да дадзенага SQL Server."

- Ці ёсць асаблівасці ў іхных сістэмах Server 2014 з 2012 \ 2008 \ 2005 года, што лепш і якія выгоды?

Калі абнаўляць з 2005, то могуць спатрэбіцца дапрацоўкі. Справа ў тым, што MS SQL Server падтрымлівае сумяшчальнасць толькі на 2 резиза таму. Для SQL 2014 гэта азначае, што без праблем запусцяцца базы з SQL 2012 і SQL 2008 (у тым ліку і 2008 R2). У вось з SQL 2005 i раней могуць быць праблемы: прыйдзецца падымаць рэжым сумяшчальнасці базы. Зменіцца паводзіны нейкіх каманд, магчыма прыйдзецца перапісаць нейкія «хранимки», гэта значыць у такім выпадку патрабуецца ўважліва глядзець і аналізаваць, што зменіцца.

- Пры гэтым рост прадукцыйнасці будзе істотны?

Існуе прыкладныя эмпірычныя правіла, замеренный ўжо не аднойчы, што з кожным новым рэлізам рост прадукцыйнасці 15-20% толькі за кошт аптымізацыі кода СКБД новай версіі. Гэта значыць, мы нічога не змянілі на платформе прыкладання, да прыкладу, 1С, проста абнавілі версію базы дадзеных, і па гэтай прычыне атрымліваем прырост прадукцыйна ў раёне 15-20%.

- Калі, груба гаварыць з пераходам MS SQL Server2005 года на SQL 2014 рост прадукцыйнасці 50-60%?

Так груба вядома не атрымаецца, працэнты на працэнты накладваюцца, але, прыкладна, працэнтаў да 40%, можна выйграць з абнаўлення 2005 да 2014 года.

- Атрымліваецца, што з MS SQL Server 2012 прасцей за ўсё абнавіць версію і толькі за кошт новага кода SQL 2014 інфармацыйная сістэма атрымае прырост прадукцыйнасці да 20%?

Так, вядома. У гэтай схеме, як раз тыя самыя 15-20%, пра якія казаў.

- Калі кампанія падтрымлівае актуальную версію SQL Server, вы рекомендуете перайсці на SQL 2014?

Так, можна ўжо пераходзіць. Часу прайшло дастаткова. Гэта значыць MS SQL Server 2014 стабільная база дадзеных, дапрацаваная, з моманту рэлізу прайшло паўтара года. Да гэтага ж яшчэ былі Community Preview, Beta, Alfa версіі. Цяпер гэта ўжо гатовае і стабільнае сервернае праграмнае забеспячэнне.

- Пры ўсталёўцы SQL Server 2014 у воблаку \ гібрыднай асяроддзі, якія плюсы, мінусы?

Гэта вельмі цікавая тэма, таму што цяпер Microsoft сфакусаваны на сваіх хмарных тэхналогіях, я лічу, што гэта правільна. Пачнем з таго, што сапраўды воблачнае тэхналогія Microsoft высока інтэграваная ва ўсе праграмныя рашэнні кампаніі. Пачынаючы ад аперацыйных сістэм, тыя ж самыя Windows 8, 10, далей Office і базы дадзеных.

Наогул, вядома, інтэграцыя з воблакам пачалася яшчэ ў 12 SQL Server, але тады хмарныя тэхналогіі былі ў зачаткавым стане, цяпер жа можна казаць пра тое, што розніца паміж лакальным і хмарным захоўваннем дадзеных практычна сцёртая.

Калі раней мы хацелі неяк звязаць воблака з базамі дадзеных, трэба было рабіць нейкія нетрывіяльныя аперацыі ледзь не на файлавым узроўні, то цяпер усё гэта падтрымліваецца з рухавічка СКБД, мы можам падключыць базы дадзеных, якія размяшчаюцца ў воблаку, мы можам рабіць рэплікацыю паміж базамі дадзеных у воблаку, мы можам рабіць рэзервовае капіраванне ў воблаку. Чым гэта добра? Тым, што воблака - гэта арандаваная інфраструктура, за работу якой «галава ўжо не баліць». За працу інфраструктуры адказвае сам Microsoft. Дадзеныя реплицируются, капіююцца, як мінімум 6-ть раз. Дзве асноўных копіі захоўваюцца ў двух розных месцах, на двух розных серверах, якія фізічна могуць быць разнесеныя наогул па розных кантынентах, і плюс яшчэ тры рэзервовыя копіі, то ёсць верагоднасць збою нікчэмная малая. Атрымліваецца, што карыстальнікі могуць зрабіць банальнае сховішча рэзервовых копій, якія ніколі не згубяцца і будуць заўсёды даступныя. Іншы варыянт, мы можам выкарыстоўваць воблака, як рэзервовы сервер. Можна арандаваць віртуальную машыну, альбо саму базу дадзеных падняць у воблаку, наладзіць рэплікацыю, альбо выкарыстоўваць тэхналогію AlwaysOn. Калі раптам у нас нешта адбываецца на асноўнай пляцоўцы з нашым серверам, мы заўсёды можам разлічваць на воблака, як на рэзервовы варыянт. Пры гэтым бізнэс карыстальнікі будуць працаваць, у той час, як адміністратары і праграмісты працуюць над ліквідацыяй праблем, аварый на асноўнай пляцоўцы.

- Атрымліваецца AlwaysOn уключаны пры рэжыме працы ў воблаку?

Нельга казаць пра тое, што ён па змаўчанні ўключаны, усё-ткі рэплікацыя дадзеных у воблака гэта сур'ёзнае рашэнне, не толькі тэхнічнае, але і арганізацыйнае. Магчымасць падлучэння аблокі SQL Azure ў якасці паўнавартаснай Ноды AlwaysOn ёсць і зрабіць гэта досыць проста. Варыянты такія: па-першае, можна выкарыстаць убудаваны рухавічок базы дадзеных SQL Azure, гэта значыць у нас няма «виртуалки», у нас проста нейкая база дадзеных працуе ў воблаку. Другі варыянт - проста выкарыстоўваць віртуальную машыну, на якой разгорнуты SQL Server. Уласна, калі мы выкарыстоўваем віртуальную машыну, можна паставіць SQL Server, які ў нас стаіць на прадакшну, тут наогул ніякіх праблем няма. Гэта значыць, мы да гэтай машыне падлучальны AlwaysOn і ў нас усё адразу працуе. Калі ж мы выкарыстоўваем убудаваны рухавічок віртуальнай базы дадзеных, то варта сказаць, што SQL Azure мае шэраг абмежаванняў. Досыць шмат абмежаванняў, на самай справе. Не ўсякая база дадзеных зможа адразу зарабіць на SQL Azure. Спатрэбіцца правесці аўдыт, нешта перарабіць, дарабіць і падагнаць пад патрабаванні аблокі, для таго каб гэтыя базы дадзеныя працавалі разам. Гэта абавязкова трэба ўлічваць.

- У гэтай архітэктуры магчыма выкарыстоўваць рашэнне DATA CLUSTER?

Так, вядома. DATA CLUSTER працуе ўжо на ўзроўні пасля AlwaysOn. Гэта значыць рашэнню ўсё роўна, дзе размяшчаюцца Ноды. Рэальныя або віртуальныя Ноды, Azure ці нешта яшчэ - для DATA CLUSTER няма ніякай розніцы.

Фактычна ж, калі мы, напрыклад, мяркуем выкарыстоўваць AlwaysOn ў звязку з платформай 1С, то выкарыстанне DATA CLUSTER аказваецца адзіным магчымым варыянтам. Як вядома, 1С «са скрынкі» не працуе сумесна з AlwaysOn. Гэта значыць няма ніякай магчымасці размяркоўваць нагрузку па некалькіх серверамі. І ці будзе працаваць, ці не будзе працаваць, дакладных каментароў ад вендара няма. У прынцыпе гэта лагічна, бо 1С працуе з некалькімі базамі дадзеных, і факусавацца на адной з баз дадзеных для іх няма ніякага сэнсу. Важна памятаць, што падтрымкі AlwaysOn на многіх платформах няма, у тым ліку і 1С, таму адзіная магчымасць працаваць - гэта выкарыстоўваць DATA CLUSTER.

- Як ўзаемадзейнічае MS SQL Server 2014 з іншымі праграмамі, які працэс стварэння адной універсальнай асяроддзя? Напрыклад, з Excel і іншымі праграмамі?

Разам з SQL Server ідзе вельмі магутная кампанента бізнес-аналітыкі - Business Intelligence (BI), якая дазваляе, у тым ліку, інтэграваць дадзеныя з СКБД ў прыкладання Office.

У тым жа Excel апошняй версіі з'явілася Шмат цікавых сродкаў Працы в е базамі дадзеных. Business Intelligence, дазваляе Ў адным Справаздача ўвязаць некалькі крыніц дадзеных, у тым ліку І дадзеныя атрымліваюцца в е SQL Server. Ёсць шмат цікавых магчымасцяў, напрыклад, убудаваны парсер вэб-сайтаў: можна ў якасці крыніцы дадзеных паказаць любы сайт з табліцай дадзеных. Тая ж самая статыстыка, дэмаграфічныя дадзеныя. Можна рабіць вельмі цікавыя рэчы, напрыклад, звязваць дадзеныя аб продажах, якія захоўваюцца ў базе дадзеных па рэгіёнах, з дадзенымі, напрыклад, Расстат, якія размешчаны на сайце. Патрабуецца паказаць адрас URL, дзе захоўваюцца дадзеныя. Потым у канструктару Business Intelligence (BI) ўвязваем гэтыя дадзеныя, робім справаздачу па карэляцыі, як і якія дадзеныя ўплываюць на продажу. Вядома, прыклад моцна ўтрыраваць, але схему і магчымасці паказвае.

- А як павінна адбывацца сувязь, паміж табліцамі, базамі? Дадзеныя павінны быць рэляцыйныя?

Так, сувязь адбываецца паміж рэляцыйнымі дадзенымі, а адкуль яны - не так важна. Гэта можа быць табліца Excel і база дадзеных, можа быць іншы ліст Excel, можа быць табліца з сайта. Ёсць нават коннекторы да соц. сетках. Гэта больш пра атрыманне кантактнай інфармацыі. Атрымліваецца, любая крыніца дадзеных, які ўяўляюць сабой табліцу, можна ўвязаць і выкарыстоўваць у Business Intelligence.

- Ці павінны быць пэўныя маркеры, злучныя дадзеныя?

Дадзеныя ў калонках. Гэта не абавязкова складаныя Guid, ID, іншыя параметры, можна банальна, на прыкладзе продажу, злучыць па назве рэгіёну. У нас ёсць у ўліковага базе назву рэгіёну і, напрыклад, у Расстат ёсць назва рэгіёну. Злучаем радкі і ўсё.

- Раскажыце, якія магчымасці рэзервовага капіявання ў MS SQL Server 2014?

Асноўныя магчымасці засталіся тыя ж самыя, вядома з дапрацоўкай. З кардынальных змен магу адзначыць, што, нарэшце, адмовіліся ад «магнітнай плёнкі, стужкі». Праўда, наўрад ці хто-то гэтым карыстаецца цяпер.

Пачынаючы з SQL Server 2012 CU1 з'явілася магчымасць рабіць рэзервовыя копіі наўпрост ў воблака. Раней мы паказвалі шлях, куды захоўваць рэзервовую копію, лакальны шлях. Зараз мы можам замест лакальнага шляху пазначыць URL аблокі. Так рэзервовая копія будзе сыходзіць адразу на сайт.

Акрамя гэтага, калі такая схема не задавальняе, ёсць альтэрнатыўная магчымасць - спецыяльная служба, якая робіць супастаўленне з тэчкай на лакальным дыску і копіямі ў воблаку. Служба будзе сачыць за з'яўленнем новых файлаў і аўтаматычна адпраўляць файлы рэзервовай копіі ў воблака. Пры гэтым у SQL мы нічога не мяняем, проста наладжвальны гэтую службу.

- праз інтэрфейс SQL Server 2014?

Не, гэта не Management Studio, асобная кампанента, якая ідзе ў складзе MS SQL Server 2014, асобнае акно. У прынцыпе, гэтую службу можна нават асобна спампаваць з сайта Microsoft і выкарыстоўваць з больш старымі версіямі СКБД, якія не падтрымліваюць бэкап наўпрост ў воблака.

- Якія магчымасці размеркавання нагрузкі прадастаўляе MS SQL Server 2014?

Тэхналогія AlwaysOn, пра якую ўжо згадваў, з'явілася яшчэ ў мінулым рэлізе - MS SQL Server 2012.

Гэта рашэнне дазваляе аб'яднаць некалькі сервераў у адну адмоваўстойлівасці групу. Калі адзін з сервераў «падае», то тут жа адбываецца пераключэнне на іншы сервер, на якім ужо знаходзяцца актуальныя дадзеныя. Сінхранізацыя адбываецца ў рэальным часе, такім чынам, час чакання, Down-Time, складае парадку некалькіх хвілін. Акрамя рашэння праблемы адмоваўстойлівасці, карыстальнікі могуць перанакіроўваць запыты счытвальныя дадзеныя, з асноўнага сервера на «копіі» сервераў, якія падлучаныя ў «групу даступнасці». Атрымліваецца, што мы разгружаем асноўную ноду ад цяжкіх запытаў.

Больш за тое, мы можам задаць розныя налады для гэтых сервераў - напрыклад, мы аптымізуем асноўны сервер на хуткую запіс дадзеных, а дадатковыя Ноды аптымізуем для фарміравання вялікіх справаздач.

У SQL Sever 2012 можна было зрабіць групу да 4-х нод, а ў MS SQL Server 2014 можна аб'яднаць да 8-мі нод. Пры гэтым кожны сервер можа быць, як звычайны, так і віртуальны, напрыклад, Azure, у воблаку Microsoft.

- Атрымліваецца павышаецца стабільнасць, адмоваўстойлівасць?

У прынцыпе, адмоваўстойлівасць і стабільнасць мы маглі павысіць і 2-3 машынамі. У новай версіі SQL Server палепшыліся магчымасці гарызантальнага маштабавання - зараз размеркаваць нагрузку можна паміж 8 серверамі, замест 4 у мінулай версіі.

Так. Таксама паўтаруся, выкарыстанне тэхналогіі DATA CLUSTER моцна спрашчае працэс размеркавання запытаў па нодам - ​​усё выконваецца наладамі кластара без неабходнасці што-небудзь мяняць у бізнес-дадатку.

- Ваша агульнае меркаванне па MS SQL Server 2014?

Не ўсе новаўвядзенні змаглі абмеркаваць. Хачу адзначыць наступнае:

1) Вылучу самую галоўную «бомбу»: In-Memory OLTP. За гэтым сапраўды будучыню. Вядома, зараз у гэтай тэхналогіі шмат абмежаванняў, для яе выкарыстання спатрэбіцца перарабляць код прыкладання. Гэта - першы крок у новым кірунку і сам кірунак адкрывае вельмі цікавыя перспектывы

2) Таксама ў 2014 версіі працягнулася лагічнае развіццё тэхналогій, як AlwaysOn. Развіццё ў «шырыню», магчымасць павелічэння колькасці падлучаных нод. Таксама лагічнае развіццё, з'явілася магчымасць сінхранізацыі з хмарным сэрвісам.

3) Зусім нічога не паспеў расказаць пра тэхналогію пашырэння буфернага кэша за кошт SSD. На самай справе вялікая частка сённяшняй гутаркі ставіцца да буйных сістэмах, для якіх актуальная самая дарагая ліцэнзія - Enterprise - якая падтрымлівае ўсё новыя тэхналогіі СКБД.

Пашырэнне буфернага кэша - гэта тое, што будзе цікава кліентам SMB - малы і сярэдні бізнес - тым, для каго купляць версію Enterprise занадта дорага.

Дык вось, вяртаючыся да тэхналогіі. Вельмі частая праблема для рабочых сервераў - недахоп аператыўнай памяці для працы з кэшам. Справа ў тым, што пры счытванні дадзеных з жорсткага дыска СКБД змяшчае іх у кэш ў аператыўнай памяці і пры паўторным звароце да такіх дадзеных счытванне вырабляецца ўжо з аператыўкі, а значыць - у сотні разоў хутчэй, чым з жорсткага дыска. Праблема ў тым, што аператыўная памяць не гумавая і не можа змясціць у сябе ўсё іграць дадзеныя, асабліва калі запыты неэфектыўныя і ствараюць залішнія чытання. У выніку старонкі «выцясняюцца» з памяці, пры паўторным звароце да такіх старонках СКБД зноў вымушана звяртацца да цвёрдай кружэлкі, прадукцыйнасць рэзка падае.

У SQL Server 2014, пачынаючы з рэдакцыі Standard, можна павялічыць аб'ём кэша за кошт падключэння SSD. Пры правільным падборы абсталявання гэта дазволіць пазбегнуць падзення прадукцыйнасці пад высокімі нагрузкамі. Калі шчыра, да выбару SSD варта падысці адказна - я рабіў выпрабаванні на віртуальнай машыне Azure з вылучаным SSD. Падобна на тое, хуткасць такога дыска была недастаткова высокай і ў выніку я, наадварот, атрымаў запаволенне выканання запыту.

4) Для спецыялістаў, якія працуюць з BI будзе цікава, што цяпер можна ствараць змяняемыя табліцы, якія змяшчаюць індэкс па слупкам (Columnstore Index). Такія індэксы значна паскараюць выбарку па «табліцах фактаў» (напрыклад, вынікі масавага соц. Апытання, нейкія аналітычныя дадзеныя і да т.п.). Упершыню такія індэксы з'явіліся ў SQL 12, тады табліца, якая змяшчае такі індэкс не магла быць зменена. Цяпер жа можна стварыць Columnstore Index і працягваць дадаваць у табліцу дадзеныя.

Абагульняючы, магу сказаць, што з'явілася шмат новых невялікіх, але зручных зменаў. Пераход на SQL Server 2014 - гэта праца на перспектыву. Упэўнены, праца з In-Memory OLTP акупіцца і прынясе свой плён. Таксама многія тэхналогіі SQL 2012 значна развіліся. Нават не укладваючыся ў развіццё In-Memory OLTP, можна атрымаць значны выйгрыш і дадатковыя магчымасці.

Не будзем забываць і пра цікавыя тэхналогіях, якія з'явіліся яшчэ ў папярэдніх рэдакцыях SQL Server. Напрыклад, у SQL 2012 з'явілася магчымасць онлайн-перастраенні індэксаў базы дадзеных без блакавання што абслугоўваецца табліцы. Калі казаць коратка, то для абслугоўвання індэксаў існуе 2 аперацыі: перастраенне індэксаў і рэарганізацыя. Дык вось, рэарганізацыю заўсёды можна было рабіць онлайн, не замінаючы працы карыстальнікаў, эфект ад такой аперацыі быў горш, чым ад перастраенні. А вось перастраенне заўсёды цалкам блакавала табліцу, і ў выніку атрымліваецца ідэальны вынік, максімальная прадукцыйнасць азначніка. Дык вось, у 2005-2008 SQL Server гэта заўсёды блакавала карыстальнікаў, у 2012 версіі Enterprise з'явілася магчымасць онлайн перастраенні індэксаў без блакавання карыстальнікаў. Натуральна, тэхналогія засталася і ў SQL Server 2014, атрымала цікавае развіццё. Цяпер, калі ў нас ёсць партиционированный індэкс, можна перастраенне кожнай часткі індэкса паасобку - гэта дазваляе больш гнутка планаваць час абслугоўвання БД і эфектыўна размяркоўваць рэсурсы: напрыклад, «аператыўную» частка індэкса, да якой ставяцца дакументы за апошні месяц, можна перабудоўваць часцей, чым астатнія часткі.

- Дзякуй Аляксандр за падрабязныя адказы, на пытанні. Дзякуй за інтэрв'ю.

эпілог:

У бліжэйшы час MS SQL Server 2014 стане асноўным інструментам для бізнесу і ўстаноў у частцы арганізацыі працы інфраструктуры сервераў. Базы дадзеных пад кіраваннем праграмнага забеспячэння MS SQL Server 2014 дазволяць развівацца ў нагу з часам, атрымліваючы магчымасць размеркавання інфармацыі на фізічных серверах, а таксама інфраструктуры ў воблаку Microsoft, у залежнасці ад бягучых патрэбаў і задач.

Універсальнасць - галоўнае годнасць MS SQL Server 2014. Зьяўляюцца новыя магчымасці пабудовы архітэктуры, павышэння адмоваўстойлівасці, а ў спалучэнні з праграмным кластарам DATA CLUSTER і павышэнне прадукцыйнасці і эфектыўнасці працы OLTP сістэм, для бягучых задач і для фарміравання аналітычнай інфармацыі.

Версія MS SQL Server 2014 эканоміць час праграмістаў і адміністратараў. Лагічнае развіццё з улікам вопыту эксплуатацыі мінулых версій і водгукаў спецыялістаў, на аснове версіі 2008 і 2012, спрыяла аптымізацыі працоўнага працэсу.

Цікавыя артыкул: