Осо­бен­но­сти вы­бо­ра со­вре­мен­ных СУБД

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Кон­стан­тин Се­лез­нев

Рас­про­стра­не­но мне­ние, что раз­ра­бот­чи­ки при­ло­же­ния по­чти все­гда мо­гут вы­брать под­хо­дя­щую СУБД, поль­зу­ясь фор­маль­ны­ми кри­те­ри­я­ми, од­на­ко на прак­ти­ке все ока­зы­ва­ет­ся слож­нее — ра­ци­о­наль­ных кри­те­ри­ев по­чти нет.

Рас­про­стра­не­но мне­ние, что раз­ра­бот­чи­ки при­ло­же­ния по­чти все­гда мо­гут вы­брать под­хо­дя­щую СУБД, поль­зу­ясь фор­маль­ны­ми кри­те­ри­я­ми, а глав­ной про­бле­мой мог­ла быть лишь незре­лость си­стем клас­са NOSQL. Од­на­ко на прак­ти­ке все ока­зы­ва­ет­ся слож­нее — ра­ци­о­наль­ных кри­те­ри­ев по­чти нет.

Клю­че­вые сло­ва: ре­ля­ци­он­ные СУБД, те­сти­ро­ва­ние Keywords: benchmark, NOSQL, Relational DBMS

На про­тя­же­нии дол­го­го вре­ме­ни до­ми­ни­ро­ва­ли ре­ля­ци­он­ные СУБД. Сам по се­бе ре­ля­ци­он­ный под­ход ока­зал­ся про­стым и удоб­ным, что обес­пе­чи­ло его рас­про­стра­не­ние сре­ди раз­ра­бот­чи­ков, а про­из­во­ди­те­ли смог­ли вы­пу­стить зре­лые про­дук­ты, при­год­ные для ши­ро­ко­го ис­поль­зо­ва­ния: Oracle Database Server, IBM DB2, Microsoft SQL Server, Teradata, Postgresql, MYSQL и Mariadb. Воз­мож­но­сти ре­ля­ци­он­ных СУБД пол­но­стью со­от­вет­ство­ва­ли тре­бо­ва­ни­ям при­ло­же­ний то­го вре­ме­ни, од­на­ко по­яв­ле­ние ин­фор­ма­ци­он­ных хра­ни­лищ и мно­го­мер­но­го ана­ли­за дан­ных раз­де­ли­ло при­клад­ные ин­фор­ма­ци­он­ные си­сте­мы на OLTP и OLAP, а для нужд по­след­них по­яви­лись спе­ци­а­ли­зи­ро­ван­ные СУБД, хо­тя и со­от­вет­ству­ю­щие идео­ло­гии ре­ля­ци­он­но­го под­хо­да, но на уровне ре­а­ли- за­ции име­ю­щие су­ще­ствен­ные от­ли­чия: сек­ци­о­ни­ро­ва­ние, по­ко­ло­ноч­ное хра­не­ние, сжа­тие дан­ных и т. д. Даль­ней­шее раз­ви­тие тех­но­ло­гий баз дан­ных бы­ло сти­му­ли­ро­ва­но по­яв­ле­ни­ем прин­ци­пи­аль­но но­вых при­клад­ных за­дач, свя­зан­ных с вы­со­ко­на­гру­жен­ны­ми си­сте­ма­ми, боль­ши­ми дан­ны­ми, по­то­ко­вой ана­ли­ти­кой, со­ци­аль­ны­ми се­тя­ми и проч. Каж­дый но­вый класс за­дач тре­бо­вал прин­ци­пи­аль­но но­вых СУБД, и ре­ля­ци­он­ные си­сте­мы ока­за­лись непри­ме­ни­мы — из­лиш­няя функ­ци­о­наль­ность и уни­вер­саль­ность при­ве­ли к слиш­ком ака­де­мич­ной ар­хи­тек­ту­ре, пло­хо адап­ти­ру­е­мой под тре­бо­ва­ния кон­крет­ных при­ло­же­ний [1]. В но­вых СУБД уже на уровне ар­хи­тек­ту­ры не бы­ло уни­вер­саль­но­сти ре­ля­ци­он­но­го под­хо­да SQL, бо­га­то­го функ­ци­о­на­ла, обя­за­тель­ной под­держ­ки ACID и др. К се­го­дняш­не­му дню по­яви­лось боль­шое ко­ли­че­ство раз­лич­ных си­стем клас- са NOSQL [2], спо­соб­ных ре­шать са­мые раз­но­об­раз­ные за­да­чи, но и ре­ля­ци­он­ные си­сте­мы впи­та­ли в се­бя идеи NOSQL, по­ро­див си­сте­мы NEWSQL [3], со­че­та­ю­щие в се­бе до­сто­ин­ства ре­ля­ци­он­но­го и нере­ля­ци­он­но­го под­хо­дов.

Мож­но ли на­звать это ре­нес­сан­сом? С од­ной сто­ро­ны, по­сле дол­го­го за­ти­шья на­блю­да­ет­ся бур­ное раз­ви­тие тех­но­ло­гий баз дан­ных и по­яв­ля­ет­ся боль­шое ко­ли­че­ство но­вых си­стем. Те­ку­щий мо­мент мож­но срав­ни­вать с «до­ре­ля­ци­он­ным» рын­ком, ко­гда су­ще­ство­ва­ло мно­же­ство са­мых раз­но­об­раз­ных па­ра­дигм, в част­но­сти иерар­хи­че­ские и се­те­вые СУБД, а боль­шое ко­ли­че­ство но­вых СУБД объ­яс­ня­ет­ся из­на­чаль­ной неэф­фек­тив­но­стью ре­ля­ци­он­ных си­стем в кон­крет­ных слу­ча­ях.

Ес­ли про­во­дить па­рал­ле­ли меж­ду эта­па­ми раз­ви­тия СУБД и ис­то­ри­че­ски­ми эпо­ха­ми, то ре­ля­ци­он­ные СУБД вполне со­от­вет­ству­ют сред­не­ве­ко­вью, ко­гда до­ми­ни­ро­ва­ла од­на идея. В этом есть свои плю­сы и ми­ну­сы. С од­ной сто­ро­ны, гла­вен­ство ре­ля­ци­он­ных СУБД поз­во­ли­ло об­ка­тать и по­лу­чить зре­лые ре­а­ли­за­ции, адап­ти­ро­ван­ные для прак­ти­че­ско­го при­ме­не­ния. С дру­гой сто­ро­ны, оно пре­пят­ство­ва­ло в то вре­мя раз­ви­тию аль­тер­на­тив­ных под­хо­дов — пред­по­ла­га­лось, что су­ще­ству­ет срав­ни­тель­но стро­гая клас­си­фи­ка­ция СУБД, а нуж­ная си­сте­ма мо­жет быть вы­бра­на на ос­но­ве чет­ких кри­те­ри­ев. Се­год­ня тех­но­ло­гии СУБД всту­пи­ли в эпо­ху ре­нес­сан­са, взяв­шую, од­на­ко, по инер­ции те­зис из сред­не­ве­ко­вья: вы­бор СУБД мо­жет быть ло­ги­че­ски обос­но­ван и до­ка­зан, а раз­ра­бот­чик при­ло­же­ния по­чти все­гда мо­жет вы­брать под­хо­дя­щую ему си­сте­му, и глав­ной про­бле­мой бу­дет лишь незре­лость мно­гих си­стем клас­са NOSQL. Од­на­ко на прак­ти­ке все ока­за­лось слож­нее.

ВЫ­БОР СУБД КАК ПРО­ЦЕСС

При всей сво­ей эле­гант­но­сти идея ра­ци­о­наль­но­го вы­бо­ра СУБД под кон­крет­ную при­клад­ную за­да­чу об­ре­че­на на про­вал — невоз­мож­но вы­ра­бо­тать еди­ные об­ще­при­ме­ни­мые кри­те­рии, и при­чин здесь несколь­ко. Во-пер­вых, при вы­бо­ре необ­хо­ди­мо срав­ни­вать свя­зан­ные, но не со­по­ста­ви­мые па­ра­мет­ры. Во-вто­рых, ко­ли­че­ство оце­ни­ва­е­мых па­ра­мет­ров мо­жет ока­зать­ся слиш­ком ве­ли­ко. На­ко­нец, са­ми по се­бе па­ра­мет­ры срав­не­ния ча­сто вы­гля­дят слиш­ком рас­плыв­ча­то.

При­мер срав­не­ния свя­зан­ных, но не со­по­ста­ви­мых кри­те­ри­ев — оцен­ка ско­ро­сти ра­бо­ты двух СУБД. На пер­вый взгляд, все про­сто: на раз­лич­ных на­груз­ках вы­пол­ня­ет­ся те­сто­вый про­гон, а за­тем на ос­но­ве по­лу­чен­ных ре­зуль­та­тов при­ни­ма­ет­ся окон­ча­тель­ное ре­ше­ние [4]. Но как быть, ес­ли при од­ной на­груз­ке вы­иг­ры­ва­ет од­на си­сте­ма, а при дру­гой — дру­гая. Вы­бор ослож­ня­ет­ся, ког- да од­на из си­стем ра­бо­та­ет мед­лен­нее, но за­то луч­ше мас­шта­би­ру­ет­ся, тре­буя мень­ше ре­сур­сов.

Еще боль­шие слож­но­сти на­чи­на­ют­ся при со­по­став­ле­нии функ­ци­о­на­ла. Ра­зу­ме­ет­ся, все срав­ни­ва­е­мые ва­ри­ан­ты долж­ны пол­но­стью удо­вле­тво­рять те­ку­щим тре­бо­ва­ни­ям при­ло­же­ния, но при этом как оце­ни­вать «до­ве­сок» неис­поль­зу­е­мых воз­мож­но­стей? Обыч­но он у каж­дой си­сте­мы свой, и мо­жет ока­зать­ся, что на дан­ный мо­мент он не ну­жен, но впо­след­ствии по­вли­я­ет на раз­ви­тие все­го при­ло­же­ния. Со­от­вет­ствен­но, нуж­но вы­би­рать СУБД ис­хо­дя не толь­ко из те­ку­щих по­треб­но­стей, но и из пер­спек­тив раз­ви­тия при­ло­же­ния.

СУБД сле­ду­ет рас­смат­ри­вать не толь­ко как со­став­ную часть при­клад­ной си­сте­мы, но и как ин­стру­мент раз­ра­бот­чи­ка, и тут по­яв­ля­ют­ся та­кие кри­те­рии срав­не­ния, как про­сто­та, удоб­ство, по­нят­ность, пред­ска­зу­е­мость и т. д., ко­то­рые, од­на­ко, нель­зя од­но­знач­но оце­нить фор­маль­но. Един­ствен­ное, что мож­но до­ба­вить, — это связь удоб­ства ис­поль­зо­ва­ния си­сте­мы и ее рас­про­стра­нен­но­сти. Как пра­ви­ло, в Ин­тер­не­те при­сут­ству­ет мас­са ма­те­ри­а­лов по ши­ро­ко рас­про­стра­нен­ным СУБД, что об­лег­ча­ет ра­бо­ту про­грам­ми­стов при ре­ше­нии ка­ких-ли­бо про­блем. Од­на­ко про­дук­ты Open Source — это не уни­вер­саль­ная па­на­цея, по­сколь­ку на­ли­чие ис­ход­но­го ко­да са­мо по се­бе не га­ран­ти­ру­ет ни удоб­ства ис­поль­зо­ва­ния, ни пред­ска­зу­е­мо­сти по­ве­де­ния си­сте­мы. Еще один до­вод в поль­зу Open Source — на­ли­чие со­об­ще­ства, но ни од­но со­об­ще­ство не да­ет сто­про­цент­ной га­ран­тии опе­ра­тив­ной тех­ни­че­ской под­держ­ки, осо­бен­но в слу­ча­ях кри­ти­че­ски важ­ных при­ло­же­ний (управ­ле­ние про­из­вод­ством, бан­ков­ский сек­тор и т. п.).

Каж­дый из упо­мя­ну­тых кри­те­ри­ев срав­не­ния мо­жет быть под­верг­нут кри­ти­ке, и раз­ра­бот­чи­ки при­клад­ных си­стем ча­сто вы­би­ра­ют СУБД ис­хо­дя из соб­ствен­ных субъ­ек­тив­ных пред­по­чте­ний и в ко­неч­ном сче­те дей­ству­ют ир­ра­ци­о­наль­но: «нра­вит­ся — не нра­вит­ся». Все осталь­ные кри­те­рии, в том чис­ле ре­зуль­та­ты те­сти­ро­ва­ния и проб­ной экс­плу­а­та­ции, ис­поль­зу­ют­ся как вспо­мо­га­тель­ные до­во­ды. С од­ной сто­ро­ны, та­кая си­ту­а­ция не нор­маль­на — раз­ра­бот­ка ПО все боль­ше ста­но­вит­ся стро­гим про­цес­сом, каж­дый шаг ко­то­ро­го чет­ко ре­гла­мен­ти­ро­ван и обос­но­ван. За­каз­чик при­клад­ной си­сте­мы пла­тит день­ги и по­то­му име­ет пра­во по­лу­чить ра­зум­ные обос­но­ва­ния каж­до­го при­ня­то­го тех­ни­че­ско­го ре­ше­ния. С дру­гой сто­ро­ны, раз­ра­бот­чик при­клад­ной си­сте­мы от­ве­ча­ет за ко­неч­ный ре­зуль­тат и дол­жен иметь воз­мож­ность при­ни­мать ин­ту­и­тив­ные ре­ше­ния, ко­то­рые мо­жет под­кре­пить толь­ко соб­ствен­ным опы­том и ощу­ще­ни­я­ми.

СУБД КАК ЧАСТЬ ПРО­ЕК­ТА

Ес­ли за­да­ча вы­бо­ра уни­вер­саль­ной СУБД не име­ет од­но­знач­но­го ре­ше­ния, то ра­ди­каль­ным вы­хо­дом мо­жет быть со­зда­ние си­сте­мы, спе­ци­аль­но пред­на­зна­чен­ной для кон­крет­но­го при­ло­же­ния. Ес­ли несколь­ко лет на­зад по­доб­ное ре­ше­ние ка­за­лось аб­сурд­ным, то те­перь оно ста­но­вит­ся все бо­лее рас­про­стра­нен­ным яв­ле­ни­ем (см. табл. 1).

Труд­но пред­ло­жить од­но­знач­ные кри­те­рии в поль­зу при­ня­тия ре­ше­ния о необ­хо­ди­мо­сти со­зда­ния но­вой спе­ци­а­ли­зи­ро­ван­ной СУБД под нуж­ды кон­крет­но­го про­ек­та, тем не ме­нее мож­но при­ве­сти ар­гу­мен­ты «за» и «про­тив» (см. табл. 2).

Не­ма­ло­важ­ное вли­я­ние на ре­ше­ние о необ­хо­ди­мо­сти и це­ле­со­об­раз­но­сти раз­ра­бот­ки но­вой СУБД ока­зы­ва­ют та­кие субъ­ек­тив­ные фак­то­ры, как до­ве­рие меж­ду за­каз­чи­ка­ми при­ло­же­ния и раз­ра­бот­чи­ка­ми, пред­ла­га­ю­щи­ми со­здать но­вую СУБД.

По­пыт­ки со­здать си­сте­му без при­вяз­ки к кон­крет­ной при­клад­ной за­да­че или их клас­су прак­ти­че­ски об­ре­че­ны на про­вал — в усло­ви­ях силь­ной сег­мен­та­ции тех­но­ло­гий СУБД очень слож­но сфор­му­ли­ро­вать тре­бо­ва­ния к бу­ду­щей си­сте­ме. Ес­ли они пол­но­стью сов­па­дут с неко­то­рым сег­мен­том, то но­вая СУБД бу­дет вы­нуж­де­на кон­ку­ри­ро­вать с уже су­ще­ству­ю­щи­ми ре­ше­ни­я­ми, име­ю­щи­ми боль­шую из­вест­ность, вос­тре­бо­ван­ность, до­ку­мен­ти­ро­ван­ность, на­деж­ность. Все это го­во­рит в поль­зу уже су­ще­ству­ю­щих си­стем, да­же ес­ли по тех­ни­че­ским ха­рак­те­ри­сти­кам они бу­дут про­иг­ры­вать но­вой, а ес­ли тре­бо­ва­ни­ям к но­вой СУБД уже от­ве­ча­ют несколь­ко го­то­вых си­стем, то вряд ли со­зда­ва­е­мая си­сте­ма по­лу­чит ши­ро­кое рас­про­стра­не­ние.

Неко­то­рые со­вре­мен­ные СУБД (на­при­мер, Vertica и Voltdb) ста­ли ре­зуль­та­том ис­сле­до­ва­тель­ских про­ек­тов, в рам­ках ко­то­рых был со­здан про­то­тип бу­ду­щей си­сте­мы (C-store — про­то­тип Vertica, H-store — про­то­тип Voltdb), про­ве­рен­ный за­тем на ре­аль­ных практических за­да­чах. Од­на­ко для мас­со­во­го со­зда­ния но­вых СУБД та­кой путь невоз­мо­жен: да­ле­ко не каж­дая ком­па­ния го­то­ва фи­нан­си­ро­вать по­доб­ные ис­сле­до­ва­тель­ские про­ек­ты.

ИРРАЦИОНАЛЬНЫЙ МИР СО­ВРЕ­МЕН­НЫХ СУБД

Тех­но­ло­гии баз дан­ных всту­па­ют в ир­ра­ци­о­наль­ную эпо­ху, ко­гда лю­бое важ­ное ре­ше­ние в ко­неч­ном сче­те ос­но­вы­ва­ет­ся на субъ­ек­ти­виз­ме и все­гда мо­жет быть под­верг­ну­то со­мне­нию. Един­ствен­ный од­но­знач­ный кри­те­рий — эко­но­ми­че­ская вы­го­да.

Кри­ти­ке се­год­ня под­вер­га­ет­ся и са­ма идея СУБД как от­дель­но­го ин­стру­мен­та. Мно­го­об­ра­зие но­вых за­дач об­ра­бот­ки дан­ных при­ве­ло к со­зда­нию огром­но­го ко­ли­че­ства раз­лич­ных про­дук­тов, пред­на­зна­чен­ных для ре­ше­ния прин­ци­пи­аль­но раз­ных, несо­по­ста­ви­мых друг с дру­гом за­дач. В этой си­ту­а­ции воз­ни­ка­ет во­прос: ка­кие из про­дук­тов яв­ля­ют­ся СУБД, а ка­кие нет?

В ре­ля­ци­он­ную эпо­ху от­вет на этот во­прос был од­но­знач­ным и ос­но­вы­вал­ся на 12 пра­ви­лах Код­да, но со­вре­мен­ные СУБД не обя­за­ны ис­поль­зо­вать ре­ля­ци­он­ную мо­дель, под­дер­жи­вать пу­стые зна­че­ния, предо­став­лять воз­мож­но­сти для ра­бо­ты со сло­ва­рем ба­зы дан­ных, обес­пе­чи­вать фи­зи­че­скую неза­ви­си­мость дан­ных и т. д. Каж­дое из сфор­му­ли­ро­ван­ных Код­дом пра­вил мо­жет быть оспо­ре­но, а дру­гих об­ще­при­знан­ных опре­де­ле­ний СУБД се­год­ня нет.

Од­на­ко на­уч­но-тех­ни­че­ское со­об­ще­ство не спе­шит рас­ста­вать­ся с тер­ми­ном «СУБД». Ста­тус раз­ра­бот­чи­ка СУБД весь­ма пре­сти­жен, по­это­му со­зда­те­ли лю­бо­го бо­лее или ме­нее уни­вер­саль­но­го ре­ше­ния в об­ла­сти об­ра­бот­ки дан­ных спе­шат к на­зва­нию сво­е­го про­дук­та при­пи­сать фор­му­ли­ров­ку «СУБД» или «плат­фор­ма». С эко­но­ми­че­ской точ­ки зре­ния ста­тус раз­ра­бот­чи­ка СУБД поз­во­ля­ет ком­па­ни­ям по­зи­ци­о­ни­ро­вать­ся на кон­крет­ном рын­ке и раз­ви­вать­ся сра­зу по двум на­прав­ле­ни­ям: по­став­ка соб­ствен­ной СУБД, ока­за­ние со­пут­ству­ю­щих услуг по тех­ни­че­ской под­держ­ке, а так­же ре­а­ли­за­ция при­клад­ных си­стем на ее ос­но­ве; раз­ра­бот­ка спе­ци­а­ли­зи­ро­ван­ных ре­ше­ний или до­ра­бот­ка име­ю­ще­го­ся про­дук­та под за­про­сы кон­крет­но­го при­ло­же­ния.

Оба на­прав­ле­ния до­пол­ня­ют друг дру­га. С од­ной сто­ро­ны, на­ли­чие соб­ствен­но­го про­дук­та поз­во­ля­ет за­яв­лять о вы­со­кой ком­пе­тен­ции в об­ла­сти СУБД. С дру­гой, вы­пол­не­ние за­каз­ных ра­бот да­ет воз­мож­ность со­зда­вать спе­ци­а­ли­зи­ро­ван­ные ре­ше­ния, по­вы­шать свою ква­ли­фи­ка­цию и впо­след­ствии раз­ви­вать про­дукт на ос­но­ве по­лу­чен­но­го опы­та.

Из­ме­не­ния в тех­но­ло­ги­ях баз дан­ных при­во­дят к смене биз­нес-мо­де­лей, ко­то­ры­ми ру­ко­вод­ству­ют­ся раз­ра­бот­чи­ки СУБД. Ни­ше­вые уз­ко­спе­ци­а­ли­зи­ро­ван­ные си­сте­мы ста­но­вят­ся вос­тре­бо­ва­ны все ча­ще, и раз­ра­бот­чи­ком СУБД ста­но­вит­ся уже не тот, у ко­го есть го­то­вый к ис­поль­зо­ва­нию про­дукт, а тот, кто спо­со­бен со­здать но­вую спе­ци­а­ли­зи­ро­ван­ную си­сте­му с ну­ля. По­ка это не силь­но вли­я­ет на об­ще­при­знан­ных ли­де­ров, пред­ла­га­ю­щих уни­вер­саль­ные СУБД для ре­ше­ния ши­ро­ко­го кру­га за­дач, и еще до­ста­точ­но дол­го ли­де­ры бу­дут со­хра­нять свои по­зи­ции, ин­тен­сив­но впи­ты­вая ин­но­ва­ци­он­ные тех­но­ло­гии. Вме­сте с тем но­вые тех­но­ло­гии бу­дут пре­ро­га­ти­вой срав­ни­тель­но неболь­ших ком­па­ний, про­дви­га­ю­щих свои спе­ци­а­ли­зи­ро­ван­ные ре­ше­ния ли­бо ра­бо­та­ю­щих по биз­нес-мо­де­ли «раз­ра­бот­ка СУБД под за­каз».

***

Из­ме­не­ния в об­ла­сти тех­но­ло­гий баз дан­ных и боль­шое чис­ло ни­ше­вых ре­ше­ний при­ве­ли к транс­фор­ма­ции ланд­шаф­та СУБД — на рын­ке се­год­ня вос­тре­бо­ва­ны раз­ра­бот­чи­ки, спо­соб­ные со­зда­вать спе­ци­а­ли­зи­ро­ван­ные си­сте­мы с ну­ля, что све­ло на нет важ­ность объ­ек­тив­ных кри­те­ри­ев вы­бо­ра си­сте­мы управ­ле­ния ба­за­ми дан­ных. С дру­гой сто­ро­ны, раз­ви­тие тех­но­ло­гий СУБД про­ис­хо­дит не толь­ко под вли­я­ни­ем со­зда­ва­е­мых поль­зо­ва­тель­ских при­ло­же­ний — мно­гие ре­во­лю­ци­он­ные тех­но­ло­гии по­яв­ля­лись ис­клю­чи­тель­но в рам­ках ис­сле­до­ва­тель­ских или рис­ко­ван­ных ком­мер­че­ских про­ек­тов, и здесь вос­тре­бо­ва­ны объ­ек­тив­ные кри­те­рии вы­бо­ра.

ЛИТЕРАТУРА

1. M. Stonebraker. «One Size Fits All»: An Idea Whose Time Has Come and Gone. URL: http://dl.acm.org/citation.cfm?id=1054024 (да­та об­ра­ще­ния: 18.09.2017).

2. Вен­кат Гу­ди­ва­да, Да­на Рао, Ви­джай Ра­г­ха­ван. Ре­нес­санс СУБД: про­бле­ма вы­бо­ра // От­кры­тые си­сте­мы.субд. — 2016. — №3. — С. 12–17. URL: https://www.osp.ru/os/2016/03/13050249 (да­та об­ра­ще­ния: 18.09.2017).

3. M. Stonebraker. New SQL: An Alternative to NOSQL and Old SQL for New OLTP Apps. URL: https://cacm.acm.org/blogs/blogcacm/109710-new-sql-an-alternative-tonosql-and-old-sql-for-new-oltp-apps/fulltext (да­та об­ра­ще­ния: 18.09.2017).

4. Ан­дрей Ни­ко­ла­ен­ко. Эта­лон­ные те­сты СУБД: что бы­ло, что ста­ло, что бу­дет // От­кры­тые си­сте­мы.субд. — 2017. — №2. — С. 35–39. URL: https://www.osp.ru/os/2017/02/13052225 (да­та об­ра­ще­ния: 10.09.2017). Кон­стан­тин Се­лез­нев (konstantin_seleznyov@relex.ru) — ве­ду­щий ин­же­нер-про­грам­мист, груп­па ком­па­ний «РЕЛЭКС» (Во­ро­неж).

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.