Пројектовање база података

Transcription

1 [Р371] Пројектовање база података 11 [Р371] Пројектовање база података Саша Малков Саша Малков Универзитет у Београду Математички факултет Тема 13 Теорема CAP 2017/2018 [Р371] - Пројектовање база података - Саша Малков /18 - час 11 1 Својства (услови) CAP Конзистентност При прављењу дистрибуираних система (не само база података) као најважнији циљеви се истичу три важна својства CAP: конзистентност (consistency) расположивост (availability) прихватање раздвојености (partition tolerance) Конзистентан систем функционише као целина или не функционише уопште Сва читања, на свим чворовима, морају да дају исти резултат Резултат операције (читања) никада не зависи од чвора на коме се извршава Разликује се од истог термина у контексту особина трансакција (ACID) [Р371] - Пројектовање база података - Саша Малков /18 - час 11 2 [Р371] - Пројектовање база података - Саша Малков /18 - час

2 Расположивост Толеранција раздвојености Систем је увек расположив расположивост се практично дефинише као одзивност система у неким гарантованим границама (у овом контексту се разматра само време одзива) Систем обично није расположив управо када је потребан у време када је расположивост најпотребнија, онда је и најтеже остварива, зато што је тада систем највише оптерећен ако је систем расположив када није потребан, то нема значаја Ниједан скуп проблема, осим потпуног отказивања, не сме да произведе неисправан одзив система тј. систем мора да прихвата делимичне отказе комуникације и да наставља исправан рад (у овом контексту се разматра исправност одзива) Повремени прекиди комуникације међу чворовима су неизбежни Раздвојеност (partition) је стање комуникационе мреже у коме су делови система (обично услед квара) подељени на партиције (два или више раздвојених скупова чворова) између којих не постоји комуникација [Р371] - Пројектовање база података - Саша Малков /18 - час 11 4 [Р371] - Пројектовање база података - Саша Малков /18 - час 11 5 Хипотеза CAP Теорема CAP Eric Brewer, Berkley (2000) Није могуће дефинисати систем који задовољава све CAP услове (конзистентност, расположивост и толеранцију раздвојености). Могуће је дефинисати систем који задовољава изабрана два од ових услова. Доказали Gilbert, Lynch, MIT (2002) Доказ наилази на оспоравања, уз тврдње да је проблематичан због спорног начина формалног дефинисања CAP услова Представићемо само идеју доказа [Р371] - Пројектовање база података - Саша Малков /18 - час 11 6 [Р371] - Пројектовање база података - Саша Малков /18 - час

3 Теорема CAP (2) Теорема CAP (3) Претпоставке: нека имамо два чвора и на њима реплициран податак V: 1) нека на чвору 1 трансакција А ажурира V 2) промена се поруком М пропагира на чвор 2 3) нека на чвору 2 нешто касније трансакција В чита V на слици је представљено жељено понашање Претпоставимо да порука М није стигла на одредиште? у том случају се ради о раздвојености делова система У основи имамо три могућа понашања система: а) трансакција А се поништава значи да систем не прихвата раздвојеност својих делова б) трансакција А се успешно наставља (и затим завршава) значи да систем није конзистентан в) трансакција А чека на успешно слање поруке М значи да систем није расположив (непознато време одзива) У сваком од случајева није испуњен један од услова [Р371] - Пројектовање база података - Саша Малков /18 - час 11 8 [Р371] - Пројектовање база података - Саша Малков /18 - час 11 9 Компромиси Компромиси (2) При пројектовању (или конфигурисању) дистрибуираног система неопходно је направити неки компромис: одбацивање толеранције раздвојености одбацивање расположивости одбацивање конзистентности ублажавање услова (тј. одбацивање више строго дефинисаних услова) заснивање система на другачијем скупу услова пројектовање заобилазних путева Одбацивање толеранције раздвојености пристајемо да систем не ради у случају раздвојености један начин превазилажења је да све буде на једној машини алтернатива је да се вишеструким умрежавањем раздвојеност (а тиме и отказ система) сведе на најмању могућу меру обе алтернативе су веома скупе Имајући у виду да се дистрибурана решења користе само онда када су неопходна због обима података и послова, овај вид компромиса се ретко прави [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

4 Компромиси (3) Компромиси (4) Одбацивање расположивости у случају раздвојености не гарантује се време одзива проблем се редукује пажљивим пројектовањем система, тј. успостављањем што ниже спреге међу чворовима Систем који није расположив је практично неупотребљив због тога се овај приступ користи релативно ретко ако је конзистентност примарна ако је толеранција раздвојености незаобилазна тежи се ниској спрегнутости међу чворовима Одбацивање конзистентности допуштамо да исти упит даје различите резултате на различитим чворовима ако су разлике прихватљивије него ниска расположивост ако је учесталост појављивања сведена на прихватљиву меру тј. ако је цена неконзистентности прихватљива Конзистентност је један од основних услова за успешан рад база података Ипак, постоје случајеви када није примарна нпр. претраживачи ако се нешто не проналази на сваком чвору, то није велики проблем чак и продавнице ако се мали број производа прода по старој цени, неће пропасти фирма [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Измењен скуп услова - BASE Измењен скуп услова - BASE (2) Појмови из теореме почивају на уобичајеним концептима рада са базама података, тј. постоји зависност са особинама трансакција ACID Може се дефинисати и другачији скуп услова, мање оштар, у ком случају се све одговарајуће особине могу ускладити BASE уместо ACID BASE Basically Available не гарантује се расположивост одговора, већ само система ако не може да се добије одговор, бар ће се добити обавештење о томе Soft-state стање система може да се мења чак и када није у току ниједна трансакција, на пример ради остваривања конзистентности Eventually consistent жртвују се гарантована стална конзистентност и изолованост трансакција зарад расположивости систем ће у неком тренутку (eventually) постати конзистентан али ће радити и давати одговоре (потенцијално различите) и до тада [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

5 Измењен скуп услова - BASE (3) Компромиси (5) Суштина концепта је у одложеном усклађивању садржаја на различитим чворовима конзистентност се остварује, али не обавезно у оквиру исте трансакције (eventual consistency) садржај чворова се мења и ван одвијања трансакција, а у циљу њиховог усклађивања (soft state) ако систем није у потпуности расположив, чвор може да покуша да пружи мање поуздан или само делимичан одговор, уз одговарајућу информацију о томе (basically available) Пројектовање заобилазних путева пројектом система се могу у зависности од услова жртвовати различите ствари у зависности од врсте трансакција бира се шта се жртвује нпр. у случају продавнице није велики проблем ако цена производа привремено није уједначена осим ако се ради о веома скуупом производу или је учесталост одступања веома висока није проблем ако евидентиран број производа у магацину привремено не одговара стварном стању ако је купац унапред обавештен о таквој могућности ако се то не дешава често и не траје дуго У суштини се своди на BASE [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Закључак Пројектовање са BASE условима Чињеница да није могуће направити савршен дистрибуиран систем (у односу на скуп услова ACID) не значи да није могуће направити систем који задовољава реално прихватљиве захтеве (скуп услова BASE) Многи велики пословни системи данас користе дистрибуиране базе података, што потврђује да су релаксирани услоив често прихватљиви пажљивије ући у пројектовање и прецизније дефинисати захтеве У основи се своди на две нове активности: Функционална декомпозиција података у фрагменте ако претпостављамо да се већ пројектује дистрибуирана база података, овде само мало прецизније одређујемо услове за дефинисање фрагмената Имплементација трансакција у BASE условима операције се не мењају, али се мења време њиховог извршавања а тиме и начин имплементирања Одређивање услова репликације Постоје и другачији приступи овај је међу једноставнијим и вероватно међу најзаступљенијим [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

6 Пројектовање са BASE условима, пример Пројектовање са BASE условима (2) Фрагмент А: подаци о производима Фрагмент Б: подаци о продаји Декомпозиција скуп података се дели на фрагменте који представљају најмање могуће функционалне целине унутар којих морају да важе ACID услови међу којима је довољно да важе BASE услови Подела трансакција на синхрони и асинхрони део свака трансакција се лоцира у једном матичном фрагменту промене података у матичном фрагменту се имплементирају синхроно, тј. на уобичајен начин у оквиру трансакције промене података у другим фрагментима се у оквиру трансакције само евидентирају евиденција мора да задовољава ACID услове евидентиране потребне измене се у другим фрагментима спроводе асинхроно Одређивање услова репликације претпоставља се да међу репликама важе BASE услови синхронизација реплика се одвија асинхроно, ван трансакција Tрансакција ажурирања цене производа у режиму ACID: BEGIN TRANSACTION UPDATE Product SET Price = :new_price WHERE ProductID = :product_id UPDATE CartItem SET Price = :new_price WHERE ProductID = :product_id AND CartID in (SELECT CartID FROM Cart WHERE Status = OPEN ) END TRANSACTION Иста трансакција у режиму BASE, лоцирана у фрагменту А: BEGIN TRANSACTION UPDATE Product SET Price = :new_price WHERE ProductID = :product_id QUEUE ADD UPDATE CartItem SET Price = :new_price WHERE ProductID = :product_id AND CartID in (SELECT CartID FROM Cart WHERE Status = OPEN ) END TRANSACTION [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Последице описаног поступка Конфликти Сви упити у оквиру једног фрагмента су локално конзистентни у оквиру фрагмената су испоштована сва правила интегритета Резултати упита на различитим репликама су потенцијално неконзистентни више реплика може да да различите резултате Резултати логички повезаних упита на различитим фрагментима могу да буду неконзистентни Фрагмент је у основи расположив и у случају партиционисања функционалан је и може да одговара на неке упите Свака промена података се у неком тренутку пропагира и на реплике и на друге повезане фрагменте База података испуњава BASE услове Основни вид проблема код свих видова имплементације BASE скупа услова Различите врсте конфликата Основни облик ако се две реплике истог податка независно мењају, питање је која верзија је исправна и како успешно извести усклађивање Сложенији облик редундантан податак а не реплика [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

7 Разрешавање конфликата Литература за ову тему Више начина решавања: забрана мењања података у случају партиционисања умањена расположивост дефинисање хијерархија међу редундантним копијама конкретних врста података дефинисање примарних и секундарних фрагмената за све податке само на примарним се изводе трансакције у односу на те податке на секундарним се само пропагирају (одложене) измене у примеру са ценама, за цену је примарни фрагмент А не умањује употребљивост, али компликује имплементацију вишеструке верзије података (MVCC) алтернатива закључавању за сваку копију податка се води верзија повезано са концептима оптимистичких трансакција и оптимистичке репликације конфликти могу аутоматски да се препознају, али не и да се отклоне Lynch, Gilbert, Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services, ACM SIGACT News, Vol.33/2 (2002) Eric Brewer, Towards Robust Distributed Systems, PODC (2000) Dan Pritchett, BASE: An Acid Alternative, ACM Queue, 2008/ [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] Пројектовање база података Појам нерелационих база података Тема 14 Саша Малков Нерелационе базе података Релационим базама података су претходиле базе података засноване на другим моделима података хијерархијске мрежне... али се данас термин нерелационе базе података (углавном) не односи на њих [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

8 Појам нерелационих база података Слабости релационих база података Релационе базе података имају многе квалитете У савременом развоју софтвера термин нерелационе базе података се односи на системе за управљање колекцијама података које: немају строгу статичку структуру података немају исцрпну проверу услова интегритета не користе упитни језик SQL... каква је онда корист од њих? (нећемо их сада набрајати) Али ти квалитети имају цену: релативно висока цена читања због нередундантности и строге структуре података тј. због честог спајања података отежано дистрибуирање пре свега због ултимативне конзистентности података скупа промена структуре због повезаности структуре са употребом и оптимизацијама [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Пример: Глобалне веб апликације... Данашње глобално доступне апликације на вебу постављају унеколико специфичне изазове пред базе података: конкурентни корисници (трансакције или читања) милиони количина података дневна производња терабајта и петабајта података обрада свака активност корисника захтева неку обраду података макар због праћења навика корисника... оптерећење непредвидив пораст оптерећења неравномерно оптерећење велика динамичност непрекидно додавање нових могућности промена постојећих компоненти При дистрибуирању РБП перформансе не расту довољно брзо не расту ни близу линеарно а оптерећење расте чак и експоненцијално није једноставно додавати и склањати чворове Нормализована схема захтева споре операције спајања захтева врло пажљиво фрагментисање и реплицирање отежава мењање [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

9 ... РБП и теорема CAP Основне карактеристике РБП су настале ради обезбеђивања чврсте и стабилне структуре базе података Олакшица: Што је апликација већа, то је већи део те апликације обично бесплатан Ако је апликација бесплатна, може нешто да се жртвује Обично се релативно безболно подноси умерено жртвовање конзистентности Шта ако се нека од основних карактеристика релационих база података ослаби да би се превазишли проблеми које описује теорема CAP? Да ли се и остале онда доводе у питање... Питања која се природно постављају: Да ли је исплативо плаћати цену РБП, ако се при томе ипак одустаје од неких њихових квалитета? Да ли је исплативије одустати од још неких особина РБП? [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Компромиси Корак уназад? Свет РБП је бескомпромисно оријентисан према поузданости и конзистентности...добро, не баш сасвим... (нивои изолованости) У свету ДБП компромиси су неопходни...теорема CAP... У домену база података данас је најактивнија област управо развој различитих видова нерелационих СУБП (НРСУБП, НРБП)...тражи се права мера компромиса... НРБП су постојале пре релационих......да ли је, онда, њихово оживљавање корак уназад? Неки од савремених НРСУБП имају сличности са старим нерелационим моделима података...можда аутори нису читали старе чланке... Већина нема [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

10 Када се размишља нерелационо? Шта то значи у пракси? Разматрају се ефикасна нерелациона решења Неко може размишљати нерелационо зато што:...не познаје добро РБП, па мисли да РБП нису решење чак и када јесу...покушава да пронађе рупу на саксији...има проблем који не може да реши помоћу РБП ако је потребно да се оствари једноставније и ефикасније дистрибуирање података лако додавање чворова висока расположивост слободна (или бар флексибилнија) структура података ако је прихватљиво да се жртвује одређен ниво конзистентности аутоматска провера интегритета [Р371] - Пројектовање база података - Саша Малков /18 - час циљеви и жртве обично могу да се параметризују [Р371] - Пројектовање база података - Саша Малков /18 - час Дефиниција? Нема јединствене дефиниције, али може се рећи: НРБП је БП која: не почива на релационом моделу података или га се бар не држи чврсто лако се дистрибуира хоризонтално је скалабилна тј. лако подноси значајне промене схеме Друге честе карактеристике: без статичке схеме лака репликација једноставан API евентуална конзистентност почива на скупу услова BASE а не ACID претпоставља изузетно велике количине података [Р371] - Пројектовање база података - Саша Малков /18 - час NoSQL Често се НРБП означавају као NoSQL базе података изворно, одступање од SQL-а, као симбола РБП no SQL данас многе теже да имају језик налик на SQL......па се често тумачи као not only SQL [Р371] - Пројектовање база података - Саша Малков /18 - час

11 Типични проблеми и алт. решења Врсте нерелационих БП Сложене структуре података у специфичним доменима објектне базе података Висок ниво дистрибуирања различите нерелационе базе података Слободна или флексибилна структура података различите нерелационе базе података Неопходне изузетно високе перформансе меморијске базе података Огромне количине података ниске сложености различите врсте матричних база података Основне врсте нерелационих база података: парови кључева и вредности складишта широких колона складиште докумената графовске базе података објектне базе података табеларне базе података складиште торки вишевредносне мултимоделне XML базе података складишта садржаја (докумената, ресурса,...) системи за претраживања [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Базе парова кључева и вредности (1) Базе парова кључева и вредности (2) Енгл. key-value databases неки аутори одвајају посебно тзв. базе торки (енгл. tupple store) Структура: свака колекција података је једна хеш табела подацима се приступа искључиво на основу познатог кључа или секвенцијално вредности су у начелу једноставне или врло ниско стрруктуриране ако вредности имају високу сложеност, обично се БП класификује као база са проширивим слоговима или база докумената Доприноси: подржавају веома велике скупове података веома су брзе обично подржавају аутоматско реплицирање и хоризонтално партиционисање колекција Слабости: подразумева се висок ниво редундантности сложене структуре се имплементирају великим бројем колекција ако су подаци густо повезани, ефикасност драстично опада у основи немају механизме за очување интегритета често не обезбеђују чак ни атомичност трансакција не могу да се претражују по подацима сваки индекс је нова колекција података... услов тражења је искључиво фиксна вредност кључа или распон вредности кључа Примери: Redis, Memcached, Hayelcast, Riak, Voldemort, Oracle NoSQL,... [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

12 Базе са проширивим слоговима Базе докумената Енгл. wide-column databases, extensible record stores Енгл. document databases Структура: у основи слично као базе парова кључева и вредности вредност представља колекцију великог броја парова имена и вредности обично број парова бар начелно није ограничен све скупа изгледа као база парова кључева и вредности са две димензије Доприноси: подржавају веома велике скупове података и велике податке и велики број података веома су брзе осим у неким случајевима вредности са веома сложеном структуром већина подржава аутоматско реплицирање и хоризонтално партиционисање колекција Слабости: све као за базе парова кључева и вредности Примери: Cassandra, BigTable, Druid, Accumulo, HDFS (Hadoop Distributed File System), HBase Структура: у основи личи на базу парова кључева и вредности сваки документ представља вредност коме се додељује кључ документи се записују у структурираним (XML, YAML, JSON, BSON,...) или неструктурираним облицима (нпр. PDF) сваки документ има метаподатке обично неструктуриране или са врло флексибилном структуром тело документа (ако је структуриран) и метаподаци се аутоматски интерно структурирају корисник не мора ништа да зна о томе Доприноси: обично веома једноставан и ефикасан рад обично подржавају бар полуаутоматско реплицирање и хоризонтално партиционисање колекција често само репликација типа главни-подређени Слабости: релативно ограничен домен примене многе имплементације не омогућавају ад-хок упите и мењања података неке имплементације не трпе велику учесталост мењања података Примери: MongoDB, CouchDB, MarkLogic, RavenDB, Amazon DynamoDD, Google Cloud Datastore [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Графовске базе података Сложеност структуре података Енгл. graph databases Структура: базу чине чворови и везе међу њима нема чврсте схеме, подаци имају веома слободну структуру акценат је на односима између података, а не на структури података Доприноси: насупрот другим нерелационим БП, веома су ефикасне када су у питању уобичајене операције са графовима неке подржавају трансакције и ACID режим услова обично само репликација типа главни-подређени Слабости: релативно ограничен домен примене нису погодне ван свог домена Примери: Neo4J, OrientDB, ArangoDB, Allegro, Virtuoso, MS Azure Cosmos DB, Titan, GraphDB [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

13 Заступљеност Заступљеност (2) Претходни дијаграм би требало посматрати са резервом Од краја има много текстова о значајној улози графовских база у специфичним проблемима, али број примена вероватно није много већи од тога Базе докумената и базе са проширивим слоговима су већ довољно добро документоване и постоји веома велики број примена и мимо тога Класичне базе парова кључева и вредности се полако повлаче пред базама докумената и базама са проширивим слоговима [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Разноврсност модела Разноврсност модела (solidit, 2014) [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

14 Разноврсност модела Још? Разноврсност модела отежава стандардизацију и учење Код база докумената то представља нешто мањи проблем, зато што је већи део структуре базе података имплицитно одређен и корисник му не приступа непосредно Код база парова кључева и вредности имамо изузетно велику збрку Приметимо да су базе са проширивим слоговима најближе неком виду стандардизације Као и код претходног дијаграма, и овде има доста резерве неки од модела су међусобно слични и деле концепте Препознају се још неке категорије база података Вишедимензионе базе података Решеткасте базе података XML базе података Објектне базе података Научне базе података Вишемоделне - представљају спој више модела на пример: ArangoDB и друге... Прилично исцрпан преглед нерелационих база података постоји на страници: [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Apache Cassandra Основни појмови Нерелациони СУБП Примарно намењен за ДБП Динамична схема Почива на проширеном моделу каталога тј. база парова кључева и вредности Иницијално развијен од стране Facebook-а Пројекат отвореног кода Један од главних пројеката фондације Apache Међу најраспрострањенијим НРСУБП-овима Cassandra почива на моделу каталога Основни појмови су: колона фамилија колона суперколона фамилија суперколона кључ простор кључева Опрез: ови појмови су другачији него код РБП [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

15 Појмови (1) Појмови (2) Колона једна вредност, праћена временом последње измене појам колоне је близак појму атрибута код РБП тројка (име, вредност, време измене) { name: prezime, value: Petrović, timestamp: } поједностављен запис: prezime: Petrović Суперколона сложена вредност, без времена последње измене садржи једну или више колона не постоји еквивалент код РБП, нешто као сложени атрибут { name: licnipodaci, value: { ime: { name: ime, value: Goran, timestamp: }, prezime: { name: prezime, value: Petrović, timestamp: }, grad: { name: grad, value: Smederevo, timestamp: } } } [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Појмови (3) Појмови (4) Фамилија колона структура која може да садржи већи број редова (концептуално неограничено) пресликава кључ у ред ред = скуп колона ред је сличан суперколони појам фамилије колона је близак појму табеле код РБП концептуално представља каталог редова Autori : { ivoandric: { // pojednostavljen zapis, bez naziva i TS ime: Ivo, prezime: Andrić,... }, goranpetrovic: { ime: Goran, prezime: Petrović,... }, } Простор кључева структура која садржи више фамилија колона или суперколона концептуално одговара појму базе података или схеме код РБП [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

16 Проширени модел каталога Имена колона Cassandra има два нивоа угнеждености први ниво је обавезан чини га пар (име колоне, колона) један ред (слог, record) се састоји од произвољног броја парова парови су уређени само по имену колоне ред има облик каталога ред МОРА да има бар једну колону други ниво је опцион уместо да други елемент пара буде колона, то може бити колекција парова суперколона Имена колона представљају истовремено кључеве и вредности Сваки ред (или суперколона) може да садржи произвољно много колона називи колона могу да имају улогу вредности вредности колона могу да буду празне [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Пример: твитови Свака порука је посебан ред кључ реда је кодирано време писања поруке Пример: твитови (2) колоне одговарају атрибутима представљају различите елементе описа поруке Овај пример личи на једну табелу релационе базе: један ред фамилије колона одговара реду табеле једна колона одговара једном атрибуту реда редови имају уједначен формат, тј. колоне са истим називима (тако је у овом примеру, али НЕ МОРАЈУ да га имају) [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

17 Пример: твитови једног корисника Један ред чине кључеви порука једног корисника Свака порука представља посебну колону Пример: твитови једног корисника (2) означена је кодом времена писања колоне су уређене по имену, па тиме и по времену писања Вредности колона су празне потребан је само списак кључева порука Овај пример нимало не личи на табелу релационе базе података: један ред фамилије колона представља колекцију података једна колона одговара једном податку, а не атрибуту редови немају уједначен формат број колона није уједначен називи колона нису уједначени Овај пример више личи на индекс [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Пример: сви твитови са неким URI-јем Један ред чине подаци о порукама једног корисника Једна суперколона се односи на једну веб локацију назив означава веб локацију на коју се односи порука вредност је колекција колона које идентификују поруке називи колона су кључеви порука вредности су празне Пример: сви твитови са неким URI-јем (2) Овај пример још мање личи на табелу релационе базе података: један ред фамилије колона представља колекцију сложених података - суперколона једна суперколона представља колекцију колона, па чак ни структура суперколона није уједначена као и у претходном примеру, редови немају уједначен формат [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

18 Партиционисање CQL Свака фамилија колона је хоризонтално партиционисана Партиционисање се врши сецкањем (хеширање) по кључу, на одговарајући број партиција У првим верзијама подаци су се користили са семантиком фамилија колона, искључиво кроз интерфејс каталога Нове верзије имају унапређен упитни језик CQL3 Cassandra Query Language Намерно и именом и синтаксом личи на SQL Терминологија је приближена терминологији релационих база података олакшано моделирање и учење сада мало прикривена семантика [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час CQL Прављење простора кључева простор кључева = база података табела = фамилија колона индекс = фамилија колона која садржи колекцију кључева неке табеле и служи за брзо претраживање CREATE KEYSPACE Test1 WITH REPLICATION = { 'class' : SimpleStrategy', replication_factor' : 3 }; класа стратегије одређује начин реплицирања фактор репликације одређује колико реплика ће имати свака партиција [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

19 Стратегије репликације Брисање простора кључева SimpleStrategy подразумевана стратегија униформна у односу на чворове параметром репликације се одређује на колико чворова желимо да се понови свака реплика добра за основне примене NetworkTopologyStrategy напреднија стратегија омогућава оптимизацију у односу на центре података параметром репликације се одређује на колико чворова у сваком центру података желимо да се понови свака реплика боља за примену у пракси DROP KEYSPACE Test1 [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Промена простора кључева Употреба простора кључева ALTER KEYSPACE Test1 WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }; Еквивалент повезивању са базом података USE Test1 [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

20 Прегледање простора кључева Типови података Списак свих простора кључева DECRIBE KEYSPACES Опис простора кључева (списак и структура табела) DECRIBE KEYSPACE [<назив>] Ако се не наведе назив, описује се простор кључева који се тренутно користи Текстуални Нумерички Логички Колекције Универзални јединствени идентификатори Остало [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Типови података Типови података Нумерички bigint 64-битни означени број Текстуални ascii 8-битне ниске inet IP адреса у формату IPv4 или IPv6 text ниска у формату UTF8 timestamp форматирана ниска са датумом и временом varchar ниска у формату UTF8 counter 64-битни број посебне намене decimal децимални тип променљиве тачности (Java) double 64-битни покретни зарезieee-754 (Java) float 32-битни покретни зарезieee-754 (Java) int 32-битни означени број timestamp форматирана ниска са датумом и временом varint цео број произвољне прецизности/дужине (Java) Логички boolean логичка вредност, true или false [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

21 Типови података Колекције података list уређена листа са једним или више елемената list<int>, list<text> map JSON каталог у облику: { literal : literal, literal : literal... } map<uuid,int>, map<int,text> одговара листи колона set неуређен скуп са једним или више елемената set<int>, set<text> tuple група од 2 или 3 податка tuple<int,text,float> није допуштено да елемент колекције буде колекција, попут: list<list<...>> [Р371] - Пројектовање база података - Саша Малков /18 - час Типови података Остало blob произвољан низ бајтова Универзални јединствени идентификатори uuid јединствени ид. у стандардном формату UUID timeuuid јединствени ид. типа 1 [Р371] - Пројектовање база података - Саша Малков /18 - час Прављење табеле Прављење табеле (2) Намерно слично као у SQL-у CREATE TABLE student ( indeks text PRIMARY KEY, ime text, prezime text, smer text ); CREATE TABLE student ( indeks text, ime text, prezime text, smer text, PRIMARY KEY( indeks ) ); [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

22 Додавање података Мењање података INSERT INTO student ( indeks, ime, prezime, smer ) VALUES (' ', 'Petar', 'Petrovic', 'R1' ); INSERT INTO student ( indeks, ime, prezime, smer ) VALUES (' ', 'Ivan', 'Markovic', 'M1' ); INSERT INTO student ( indeks, ime, prezime, smer ) VALUES (' ', 'Tijana', 'Zivkovic', 'R1' ); UPDATE student SET smer = 'V1' WHERE indeks = ' ' [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Брисање података Читање података DELETE ime FROM student WHERE indeks = ' '; брише изабране колоне изабраних редова DELETE FROM student WHERE indeks = ' '; брише изабране редове TRUNCATE student; брише све редове SELECT * FROM student WHERE indeks=' '; SELECT * FROM student WHERE ime='tijana'; зависно од верзије и конфигурације, претраживање по колонама за које не постоји индекс није дозвољено [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

23 Прављење и брисање индекса Употреба колекција ALTER TABLE student ADD napomene list<text>; CREATE INDEX student_ime ON student (ime); CREATE INDEX student_prezime ON student (prezime); CREATE INDEX student_smer ON student (smer); DROP INDEX... постављање целе листе UPDATE student SET napomene = [ aaa', bbb' ] WHERE indeks = ' '; додавање елемената на почетак и крај је брза операција, не чита листу UPDATE student SET napomene = [ xxx' ] + napomene WHERE indeks = ' '; UPDATE student SET napomene = napomene + [ yyy ] WHERE indeks = ' '; [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час Употреба колекција (2) За вежбу... мењање елемената је спорије, зато што чита листу UPDATE student SET napomene[2] = 222' WHERE indeks = ' '; брисање елемената такође чита листу DELETE napomene[2] FROM student WHERE indeks = ' '; UPDATE student SET napomene = napomene - [ aaa ] WHERE indeks = ' '; Инсталирати и испробати СУБП Cassandra Размотрити могућности и посебно CQL прикривена структура индекса сличности и разлике у односу на SQL... [Р371] - Пројектовање база података - Саша Малков /18 - час [Р371] - Пројектовање база података - Саша Малков /18 - час

24 Литература за ову тему Sugam Sharma, An Extended Classification and Comparison of NoSQL Big Data Models, Arxiv, Званична веб страна пројекта Cassandra Званична документација за CQL DB-Engines Интернет... [Р371] - Пројектовање база података - Саша Малков /18 - час