NewSQL системи

NEWSQL СИСТЕМИ

доц. д-р Цветанка Георгиева-Трифонова

СЪДЪРЖАНИЕ

Същност на NewSQL системите

История

Характеристики на NewSQL системи

Категории

F1 – разпределена релационна система за бази от данни,

която скалира

Модел на данните. Йерархична схема

Разпределени заявки

Съединяване на йерархични таблици

Protocol Buffers

2 2 Цветанка Георгиева Моделиране на информационни системи

СЪЩНОСТ НА NEWSQL СИСТЕМИТЕ

NewSQL

клас от съвременните релационни системи за управление

на бази от данни, които:

предоставят същата мащабируема производителност

като NoSQL система за онлайн обработка на

трансакции (OLTP);

поддържат ACID трансакции, подобно на традиционна

система за база от данни.


ИСТОРИЯ

Терминът NewSQL

се използва за първи път от 451 Group анализатор

Matthew Aslett през 2011 в статия.

Много корпоративни системи, които обработват персонални

данни (например, финансови системи и системите за

обработка на поръчки) се нуждаят от:

възможност за мащабиране;

ACID трансакции.

Възможни решения (преди NewSQL) за тези организации:

закупуване на по-мощен единичен възел-машина;

разработване на потребителски мидълуер, който

разпределя заявки над традиционните СУБД възли.


ХАРАКТЕРИСТИКИ НА NEWSQL СИСТЕМИ

Въпреки че NewSQL системите се различават според

вътрешната си архитектура, те имат две общи

характеристики:

всички поддържат релационния модел на данните;

използват SQL като основен интерфейс.


ХАРАКТЕРИСТИКИ НА NEWSQL СИСТЕМИ (2)

Приложенията, към които са насочени тези NewSQL системи,

се характеризират с голям брой трансакции, които:

са краткотрайни;

осъществяват достъп до малко подмножество на данните

чрез използване на индекс (т.е. без сканиране на таблици

и разпределени съединения на таблици);

са повтарящи се (т.е. изпълняват се същите заявки, но с

различни входни стойности).

Една от първите известни NewSQL системи е системата за

бази от данни на H-Store.


КАТЕГОРИИ

Нови архитектури (new architectures)

Проектирани са с разпределена архитектура, включват

компоненти като разпределен контрол на

едновременната работа, обработка на разпределени

заявки.

Примерни системи от тази категория са:

Google Spanner, Clustrix, VoltDB, MemSQL, Pivotal's

SQLFire, GemFire XD, SAP HANA, FoundationDB, NuoDB,

Infinitum, TransLattice, ActorDB, Trafodion.


КАТЕГОРИИ (2)

SQL машина (SQL engine)

Представляват високо-оптимизирани машини за SQL;

Осигуряват програмен интерфейс за SQL, но също и

възможност за ефективно скалиране.

Примери за такива системи са:

Infobright, TokuDB, InfiniDB.


КАТЕГОРИИ (3)

Transparent sharding

Разполагат с междинно ниво за автоматично разделяне

на базата от данни между множество възли в

разпределената система.

Примери за такива системи са:

dbShards, Scalearc, ScaleBase.


F1 – РАЗПРЕДЕЛЕНА РЕЛАЦИОННА СИСТЕМА ЗА

БАЗИ ОТ ДАННИ, КОЯТО СКАЛИРА

F1

разпределена релационна система за бази от данни,

създадена от Google, за да поддържа AdWords;

комбинира достъпността, мащабируемостта на NoSQL

системите като BigTable и съгласуваността,

използваемостта на традиционните SQL бази от данни;

наследник на BigTable;

част от Google платформата.

CockroachDB е проект с отворен код, който има за цел да

пренесе характеристиките на F1 извън Google.


F1 – РАЗПРЕДЕЛЕНА РЕЛАЦИОННА СИСТЕМА ЗА

БАЗИ ОТ ДАННИ, КОЯТО СКАЛИРА (2)

Основните характеристики на F1 са:

Мащабируемост;

Достъпност;

Съгласуваност;

Системата осигурява ACID трансакции.

Използваемост.

Системата осигурява пълна SQL поддръжка.

Името F1 е взаимствано от генетиката, където Filial 1 hibrid е

първата генерация на потомство, получено от кръстосване

на съществено различни родителски видове.


F1 – МОДЕЛ НА ДАННИТЕ

Йерархична схема

Таблиците в схема на F1 са организирани в йерархия;

Таблиците не могат да бъде произволно разделени:

таблицата-наследник трябва да има външен ключ към

таблицата-родител като префикс на първичния си ключ.

Пример

Схемата AdWords съдържа:

таблица Customers с първичен ключ CustomerID.

таблица-наследник Campaign с първичен ключ,

състоящ се от CustomerID, CampaignID.

таблица-наследник AdGroup с първичен ключ,

състоящ се от колоните CustomerID, CampaignID,

AdGroupID. 12 12 Цветанка Георгиева Моделиране на информационни системи

F1 – ЙЕРАРХИЧНА СХЕМА


F1 – ЙЕРАРХИЧНА СХЕМА (2)

Ред в коренната таблица в йерархията се нарича коренен

ред;

Редовете в таблицата-наследник, съответстващи на даден

коренен ред, се клъстерират заедно с този коренен ред;

Редовете наследници се съхраняват под техния родителски

ред, подредени според първичния ключ;

Извличането на редовете от AdGroups за даден клиент

(например CustomerID=1) се осъществява чрез една

заявка към таблицата AdGroups, вместо съединяване на

таблици;

За съединяване на таблиците е необходимо да се извърши

само сливане на сортирани редове.


F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ

F1 SQL поддържа:

Централизираното изпълнение

използва се за заявки, типични за OLTP (т.е.

осъществяващи достъп до малко данни) и изцяло се

изпълняват на един F1 сървър.

Разпределеното изпълнение

използва се за заявки, типични за OLAP.

Оптимизаторът на заявки определя кой режим на

изпълнение е подходящ за дадена заявка.


F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ (2)

При следната примерна заявка се прилага разпределено

изпълнение:

Извлича редовете в AdClick за определена дата;

Намира съответстващите редове в AdGroupCreative,

както и в Creative;

Пресмята броя на показванията, групирани според

рекламна кампания, регион и език. 16 16 Цветанка Георгиева Моделиране на информационни системи


Възможен план за изпълнение на заявката:

Сканиране на таблицата AdClick;

Намиране на съответните редове в таблицата

AdGroupCreative чрез използване на индекс;

Обединяване (repartition) на данните;

Намиране на съответните редове в Creative;

Обединяване;

Групиране и прилагане на агрегатната функция.



План за изпълнение на

разпределена заявка;

Правоъгълниците със заоблени

ъгли представят обработки,

които се изпълняват на отделни

машини.


F1 – СЪЕДИНЯВАНЕ НА ЙЕРАРХИЧНИ ТАБЛИЦИ

Моделът на данните позволява ефективно съединяване на

родителската таблица с нейна таблица-наследник

посредством общия им префикс в първичния ключ;

Например, съединяване на таблицата Customer с

таблицата Campaign;

Данните се връщат чрез обхождане в дълбочина, подредени

по префикса на първичния ключ;

F1 използва алгоритъм за съединяване и сливане, наречен

клъстерно съединяване (cluster join).


F1 – PROTOCOL BUFFERS

Моделът на данните във F1 поддържа колони на таблици,

които съдържат структурни типове данни.

Тези типове използват схема и двоичен формат,

предоставени от библиотеката с отворен код Protocol Buffers

на Google.

Protocol Buffers дефинира типове на колони, които могат да

бъдат:

задължителни (required);

опционални (optional);

повтарящи се (repeated).



F1 реализира разширение на SQL, което разглежда

стойностите на колони от тип Protocol Buffers като обекти на

клас и осигурява достъп до всички данни в тях.

Например, следната заявка извлича CustomerID и цялото

съдържание на колона Info от тип Protocol Buffers за

клиентите, чийто код на държавата е US.



Тази заявка илюстрира два аспекта на поддръжката на

Protocol Buffers:

Заявката използва израз за пътя до отделните полета

c.Info.country_code;

F1 SQL позволява извличане на цялото съдържание на

колона от тип Protocol Buffers – c.Info.



Наличието на повтарящи се полета (repeated fields)

предотвратява използването на таблица-наследник, когато

съответните редове-наследници са сравнително малко на

брой.

По този начин се избягва сортирането и съединяването при

извличане на редове от двете таблици.

Основната разлика между таблица-наследник и повтарящо

се поле е, че таблицата-наследник съдържа изрично

дефиниран външен ключ към родителската таблица, докато

повтарящото се поле има неявен външен ключ към колоната

от тип Protocol Buffers, която го съдържа.



F1 SQL поддържа достъп до повтарящите се полета чрез

използване на вид съединение PROTO JOIN, което се

основава на неявния външен ключ.

Например, нека таблицата Customer има Protocol Buffers

колона Witelist, която на свой ред съдържа повтарящо се

поле feature.

Освен това стойностите в това поле feature са от тип

Protocol Buffers, всяка от които представлява статуса на

конкретната характеристика за родителския ред в таблицата

Customer.



Заявка, която съединява таблицата Customer с нейната

виртуална таблица-наследник Whitelist.feature по

неявно зададения външен ключ.

След това се извършва филтриране на резултата по

стойността на полето f.status в Whitelist.feature и

връща полето f.feature.



F1 SQL позволява изпълняване на подзаявки за

повтарящите се полета в Protocol Buffers.

Следната заявка има:

подзаявка за пресмятане на броя на

Whitelist.feature;

подзаявка, за която е приложен EXISTS, за избира

клиентите, които имат поне една характеристика със

статус, различен от ENABLED.


ЛИТЕРАТУРА

Katarina Grolinger, Wilson A Higashino, Abhinav Tiwari, Miriam

AM Capretz, Data management in cloud environments: NoSQL

and NewSQL data stores, Journal of Cloud Computing:

Advances, Systems and Applications, 2013

Jeff Shute, Radek Vingralek, Bart Samwel, Ben Handy, Chad

Whipkey, Eric Rollins, Mircea Oancea, Kyle Littlefield, David

Menestrina, Stephan Ellner, John Cieslewicz, Ian Rae, Traian

Stancescu, Himani Apte, F1: A Distributed SQL Database That

Scales, In Proceedings of the VLDB Endowment, 2013, Vol. 6,

No. 11


Data & Analytics

NewSQL системи