Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

NewSQL системи

530 Aufrufe

Veröffentlicht am

NewSQL е клас от съвременните релационни системи за управление на бази от данни, които се стремят да предоставят същата мащабируема производителност като NoSQL система за онлайн обработка на трансакции (OLTP), като едновременно с това поддържат ACID трансакции, подобно на традиционна система за база от данни.

Veröffentlicht in: Daten & Analysen
  • Als Erste(r) kommentieren

NewSQL системи

  1. 1. NEWSQL СИСТЕМИ доц. д-р Цветанка Георгиева-Трифонова
  2. 2. СЪДЪРЖАНИЕ  Същност на NewSQL системите  История  Характеристики на NewSQL системи  Категории  F1 – разпределена релационна система за бази от данни, която скалира  Модел на данните. Йерархична схема  Разпределени заявки  Съединяване на йерархични таблици  Protocol Buffers 22Цветанка Георгиева Моделиране на информационни системи
  3. 3. СЪЩНОСТ НА NEWSQL СИСТЕМИТЕ  NewSQL  клас от съвременните релационни системи за управление на бази от данни, които:  предоставят същата мащабируема производителност като NoSQL система за онлайн обработка на трансакции (OLTP);  поддържат ACID трансакции, подобно на традиционна система за база от данни. 33Цветанка Георгиева Моделиране на информационни системи
  4. 4. ИСТОРИЯ  Терминът NewSQL  се използва за първи път от 451 Group анализатор Matthew Aslett през 2011 в статия.  Много корпоративни системи, които обработват персонални данни (например, финансови системи и системите за обработка на поръчки) се нуждаят от:  възможност за мащабиране;  ACID трансакции.  Възможни решения (преди NewSQL) за тези организации:  закупуване на по-мощен единичен възел-машина;  разработване на потребителски мидълуер, който разпределя заявки над традиционните СУБД възли. 44Цветанка Георгиева Моделиране на информационни системи
  5. 5. ХАРАКТЕРИСТИКИ НА NEWSQL СИСТЕМИ  Въпреки че NewSQL системите се различават според вътрешната си архитектура, те имат две общи характеристики:  всички поддържат релационния модел на данните;  използват SQL като основен интерфейс. 55Цветанка Георгиева Моделиране на информационни системи
  6. 6. ХАРАКТЕРИСТИКИ НА NEWSQL СИСТЕМИ (2)  Приложенията, към които са насочени тези NewSQL системи, се характеризират с голям брой трансакции, които:  са краткотрайни;  осъществяват достъп до малко подмножество на данните чрез използване на индекс (т.е. без сканиране на таблици и разпределени съединения на таблици);  са повтарящи се (т.е. изпълняват се същите заявки, но с различни входни стойности).  Една от първите известни NewSQL системи е системата за бази от данни на H-Store. 66Цветанка Георгиева Моделиране на информационни системи
  7. 7. КАТЕГОРИИ  Нови архитектури (new architectures)  Проектирани са с разпределена архитектура, включват компоненти като разпределен контрол на едновременната работа, обработка на разпределени заявки.  Примерни системи от тази категория са:  Google Spanner, Clustrix, VoltDB, MemSQL, Pivotal's SQLFire, GemFire XD, SAP HANA, FoundationDB, NuoDB, Infinitum, TransLattice, ActorDB, Trafodion. 77Цветанка Георгиева Моделиране на информационни системи
  8. 8. КАТЕГОРИИ (2)  SQL машина (SQL engine)  Представляват високо-оптимизирани машини за SQL;  Осигуряват програмен интерфейс за SQL, но също и възможност за ефективно скалиране.  Примери за такива системи са:  Infobright, TokuDB, InfiniDB. 88Цветанка Георгиева Моделиране на информационни системи
  9. 9. КАТЕГОРИИ (3)  Transparent sharding  Разполагат с междинно ниво за автоматично разделяне на базата от данни между множество възли в разпределената система.  Примери за такива системи са:  dbShards, Scalearc, ScaleBase. 99Цветанка Георгиева Моделиране на информационни системи
  10. 10. F1 – РАЗПРЕДЕЛЕНА РЕЛАЦИОННА СИСТЕМА ЗА БАЗИ ОТ ДАННИ, КОЯТО СКАЛИРА  F1  разпределена релационна система за бази от данни, създадена от Google, за да поддържа AdWords;  комбинира достъпността, мащабируемостта на NoSQL системите като BigTable и съгласуваността, използваемостта на традиционните SQL бази от данни;  наследник на BigTable;  част от Google платформата.  CockroachDB е проект с отворен код, който има за цел да пренесе характеристиките на F1 извън Google. 1010Цветанка Георгиева Моделиране на информационни системи
  11. 11. F1 – РАЗПРЕДЕЛЕНА РЕЛАЦИОННА СИСТЕМА ЗА БАЗИ ОТ ДАННИ, КОЯТО СКАЛИРА (2)  Основните характеристики на F1 са:  Мащабируемост;  Достъпност;  Съгласуваност;  Системата осигурява ACID трансакции.  Използваемост.  Системата осигурява пълна SQL поддръжка.  Името F1 е взаимствано от генетиката, където Filial 1 hibrid е първата генерация на потомство, получено от кръстосване на съществено различни родителски видове. 1111Цветанка Георгиева Моделиране на информационни системи
  12. 12. F1 – МОДЕЛ НА ДАННИТЕ  Йерархична схема  Таблиците в схема на F1 са организирани в йерархия;  Таблиците не могат да бъде произволно разделени:  таблицата-наследник трябва да има външен ключ към таблицата-родител като префикс на първичния си ключ.  Пример  Схемата AdWords съдържа:  таблица Customers с първичен ключ CustomerID.  таблица-наследник Campaign с първичен ключ, състоящ се от CustomerID, CampaignID.  таблица-наследник AdGroup с първичен ключ, състоящ се от колоните CustomerID, CampaignID, AdGroupID. 1212Цветанка Георгиева Моделиране на информационни системи
  13. 13. F1 – ЙЕРАРХИЧНА СХЕМА 1313Цветанка Георгиева Моделиране на информационни системи
  14. 14. F1 – ЙЕРАРХИЧНА СХЕМА (2)  Ред в коренната таблица в йерархията се нарича коренен ред;  Редовете в таблицата-наследник, съответстващи на даден коренен ред, се клъстерират заедно с този коренен ред;  Редовете наследници се съхраняват под техния родителски ред, подредени според първичния ключ;  Извличането на редовете от AdGroups за даден клиент (например CustomerID=1) се осъществява чрез една заявка към таблицата AdGroups, вместо съединяване на таблици;  За съединяване на таблиците е необходимо да се извърши само сливане на сортирани редове. 1414Цветанка Георгиева Моделиране на информационни системи
  15. 15. F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ  F1 SQL поддържа:  Централизираното изпълнение  използва се за заявки, типични за OLTP (т.е. осъществяващи достъп до малко данни) и изцяло се изпълняват на един F1 сървър.  Разпределеното изпълнение  използва се за заявки, типични за OLAP.  Оптимизаторът на заявки определя кой режим на изпълнение е подходящ за дадена заявка. 1515Цветанка Георгиева Моделиране на информационни системи
  16. 16. F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ (2)  При следната примерна заявка се прилага разпределено изпълнение:  Извлича редовете в AdClick за определена дата;  Намира съответстващите редове в AdGroupCreative, както и в Creative;  Пресмята броя на показванията, групирани според рекламна кампания, регион и език. 1616Цветанка Георгиева Моделиране на информационни системи
  17. 17. F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ (4)  Възможен план за изпълнение на заявката:  Сканиране на таблицата AdClick;  Намиране на съответните редове в таблицата AdGroupCreative чрез използване на индекс;  Обединяване (repartition) на данните;  Намиране на съответните редове в Creative;  Обединяване;  Групиране и прилагане на агрегатната функция. 1717Цветанка Георгиева Моделиране на информационни системи
  18. 18. F1 – РАЗПРЕДЕЛЕНИ ЗАЯВКИ (5)  План за изпълнение на разпределена заявка;  Правоъгълниците със заоблени ъгли представят обработки, които се изпълняват на отделни машини. 1818Цветанка Георгиева Моделиране на информационни системи
  19. 19. F1 – СЪЕДИНЯВАНЕ НА ЙЕРАРХИЧНИ ТАБЛИЦИ  Моделът на данните позволява ефективно съединяване на родителската таблица с нейна таблица-наследник посредством общия им префикс в първичния ключ;  Например, съединяване на таблицата Customer с таблицата Campaign;  Данните се връщат чрез обхождане в дълбочина, подредени по префикса на първичния ключ;  F1 използва алгоритъм за съединяване и сливане, наречен клъстерно съединяване (cluster join). 1919Цветанка Георгиева Моделиране на информационни системи
  20. 20. F1 – PROTOCOL BUFFERS  Моделът на данните във F1 поддържа колони на таблици, които съдържат структурни типове данни.  Тези типове използват схема и двоичен формат, предоставени от библиотеката с отворен код Protocol Buffers на Google.  Protocol Buffers дефинира типове на колони, които могат да бъдат:  задължителни (required);  опционални (optional);  повтарящи се (repeated). 2020Цветанка Георгиева Моделиране на информационни системи
  21. 21. F1 – PROTOCOL BUFFERS  F1 реализира разширение на SQL, което разглежда стойностите на колони от тип Protocol Buffers като обекти на клас и осигурява достъп до всички данни в тях.  Например, следната заявка извлича CustomerID и цялото съдържание на колона Info от тип Protocol Buffers за клиентите, чийто код на държавата е US. 2121Цветанка Георгиева Моделиране на информационни системи
  22. 22. F1 – PROTOCOL BUFFERS  Тази заявка илюстрира два аспекта на поддръжката на Protocol Buffers:  Заявката използва израз за пътя до отделните полета c.Info.country_code;  F1 SQL позволява извличане на цялото съдържание на колона от тип Protocol Buffers – c.Info. 2222Цветанка Георгиева Моделиране на информационни системи
  23. 23. F1 – PROTOCOL BUFFERS  Наличието на повтарящи се полета (repeated fields) предотвратява използването на таблица-наследник, когато съответните редове-наследници са сравнително малко на брой.  По този начин се избягва сортирането и съединяването при извличане на редове от двете таблици.  Основната разлика между таблица-наследник и повтарящо се поле е, че таблицата-наследник съдържа изрично дефиниран външен ключ към родителската таблица, докато повтарящото се поле има неявен външен ключ към колоната от тип Protocol Buffers, която го съдържа. 2323Цветанка Георгиева Моделиране на информационни системи
  24. 24. F1 – PROTOCOL BUFFERS  F1 SQL поддържа достъп до повтарящите се полета чрез използване на вид съединение PROTO JOIN, което се основава на неявния външен ключ.  Например, нека таблицата Customer има Protocol Buffers колона Witelist, която на свой ред съдържа повтарящо се поле feature.  Освен това стойностите в това поле feature са от тип Protocol Buffers, всяка от които представлява статуса на конкретната характеристика за родителския ред в таблицата Customer. 2424Цветанка Георгиева Моделиране на информационни системи
  25. 25. F1 – PROTOCOL BUFFERS  Заявка, която съединява таблицата Customer с нейната виртуална таблица-наследник Whitelist.feature по неявно зададения външен ключ.  След това се извършва филтриране на резултата по стойността на полето f.status в Whitelist.feature и връща полето f.feature. 2525Цветанка Георгиева Моделиране на информационни системи
  26. 26. F1 – PROTOCOL BUFFERS  F1 SQL позволява изпълняване на подзаявки за повтарящите се полета в Protocol Buffers.  Следната заявка има:  подзаявка за пресмятане на броя на Whitelist.feature;  подзаявка, за която е приложен EXISTS, за избира клиентите, които имат поне една характеристика със статус, различен от ENABLED. 2626Цветанка Георгиева Моделиране на информационни системи
  27. 27. ЛИТЕРАТУРА  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 2727Цветанка Георгиева Моделиране на информационни системи
  28. 28. 2828Цветанка Георгиева Цветанка Георгиева-Трифонова, 2017 Някои права запазени. Презентацията е достъпна под лиценз Creative Commons, Признание-Некомерсиално-Без производни, https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode

×