Saluton al ĉiuj! Mia nomo estas Golov Nikolay. Antaŭe, mi laboris ĉe Avito kaj administris la Datumplatformon dum ses jaroj, tio estas, mi laboris pri ĉiuj datumbazoj: analiza (Vertica, ClickHouse), streaming kaj OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Dum ĉi tiu tempo, mi traktis grandan nombron da datumbazoj - tre malsamaj kaj nekutimaj, kaj kun ne-normaj kazoj de ilia uzo.
Mi nuntempe laboras ĉe ManyChat. Esence, ĉi tio estas noventrepreno - nova, ambicia kaj rapide kreskanta. Kaj kiam mi unue aliĝis al la kompanio, aperis klasika demando: "Kion nun devus preni juna noventrepreno de la DBMS kaj datumbaza merkato?"
En ĉi tiu artikolo, surbaze de mia raporto ĉe , mi respondos ĉi tiun demandon. Videoversio de la raporto estas havebla ĉe .
Ofte konataj datumbazoj 2020
Estas 2020, mi ĉirkaŭrigardis kaj vidis tri specojn de datumbazoj.
Unua tipo - klasikaj OLTP-datumbazoj: PostgreSQL, SQL-Servilo, Oracle, MySQL. Ili estis skribitaj antaŭ longa tempo, sed daŭre estas gravaj ĉar ili estas tiel konataj al la programista komunumo.
La dua tipo estas bazoj de "nulo". Ili provis malproksimiĝi de klasikaj ŝablonoj forlasante SQL, tradiciajn strukturojn kaj ACID, aldonante enkonstruitan sharding kaj aliajn allogajn trajtojn. Ekzemple, ĉi tio estas Cassandra, MongoDB, Redis aŭ Tarantool. Ĉiuj ĉi tiuj solvoj volis proponi al la merkato ion fundamente novan kaj okupis sian niĉon ĉar ili montriĝis ege oportunaj por certaj taskoj. Mi indikos ĉi tiujn datumbazojn per la tegmenta termino NOSQL.
La "nuloj" finiĝis, ni alkutimiĝis al NOSQL-datumbazoj, kaj la mondo, el mia vidpunkto, faris la sekvan paŝon - al administritaj datumbazoj. Ĉi tiuj datumbazoj havas la saman kernon kiel klasikaj OLTP-datumbazoj aŭ novaj NoSQL. Sed ili ne bezonas DBA kaj DevOps kaj funkcias per administrita aparataro en la nuboj. Por programisto, ĉi tio estas "nur bazo", kiu funkcias ie, sed neniu zorgas pri kiel ĝi estas instalita sur la servilo, kiu agordis la servilon kaj kiu ĝisdatigas ĝin.
Ekzemploj de tiaj datumbazoj:
- AWS RDS estas administrita envolvaĵo por PostgreSQL/MySQL.
- DynamoDB estas AWS-analogo de dokumentbazita datumbazo, simila al Redis kaj MongoDB.
- Amazon Redshift estas administrita analiza datumbazo.
Ĉi tiuj estas esence malnovaj datumbazoj, sed levitaj en administrita medio, sen la bezono labori kun aparataro.
Notu. La ekzemploj estas prenitaj por la AWS-medio, sed iliaj analogoj ankaŭ ekzistas en Microsoft Azure, Google Cloud aŭ Yandex.Cloud.
Kio estas nova pri ĉi tio? En 2020, nenio el ĉi tio.
Senservila koncepto
Kio estas vere nova sur la merkato en 2020 estas solvoj sen serviloj aŭ senserviloj.
Mi provos klarigi kion tio signifas uzante la ekzemplon de regula servo aŭ backend-apliko.
Por deploji regulan backend-aplikaĵon, ni aĉetas aŭ luas servilon, kopias la kodon sur ĝi, publikigas la finpunkton ekstere kaj regule pagas por lupago, elektro kaj datumcentraj servoj. Ĉi tiu estas la norma skemo.
Ĉu ekzistas alia maniero? Kun senservilaj servoj vi povas.
Kio estas la fokuso de ĉi tiu aliro: ne ekzistas servilo, eĉ ne luas virtualan petskribon en la nubo. Por disfaldi la servon, kopiu la kodon (funkciojn) al la deponejo kaj publikigu ĝin al la finpunkto. Tiam ni simple pagas por ĉiu voko al ĉi tiu funkcio, tute ignorante la aparataron kie ĝi estas ekzekutita.
Mi provos ilustri ĉi tiun aliron per bildoj.
Klasika deplojo. Ni havas servon kun certa ŝarĝo. Ni levas du okazojn: fizikajn servilojn aŭ petskribojn en AWS. Eksteraj petoj estas senditaj al ĉi tiuj instancoj kaj procesitaj tie.
Kiel vi povas vidi en la bildo, la serviloj ne estas forigitaj egale. Unu estas 100% uzata, estas du petoj, kaj unu estas nur 50% - parte neaktiva. Se alvenos ne tri petoj, sed 30, tiam la tuta sistemo ne povos elteni la ŝarĝon kaj komencos malrapidiĝi.
Senservila deplojo. En senservila medio, tia servo ne havas petskribojn aŭ servilojn. Estas certa aro da varmigitaj rimedoj - malgrandaj pretaj Docker-ujoj kun deplojita funkciokodo. La sistemo ricevas eksterajn petojn kaj por ĉiu el ili la senservila kadro levas malgrandan ujon kun kodo: ĝi prilaboras ĉi tiun apartan peton kaj mortigas la ujon.
Unu peto - unu ujo levita, 1000 petoj - 1000 ujoj. Kaj deplojo sur aparataj serviloj jam estas la laboro de la nuba provizanto. Ĝi estas tute kaŝita de la senservila kadro. En ĉi tiu koncepto ni pagas por ĉiu voko. Ekzemple, unu voko venis tage - ni pagis por unu voko, miliono venis po minuto - ni pagis por miliono. Aŭ en sekundo, ĉi tio ankaŭ okazas.
La koncepto de publikigado de senservila funkcio taŭgas por sennacia servo. Kaj se vi bezonas (ŝtatan) plenan servon, tiam ni aldonas datumbazon al la servo. En ĉi tiu kazo, kiam temas pri laboro kun stato, ĉiu statoplena funkcio simple skribas kaj legas el la datumbazo. Cetere, el datumbazo de iu el la tri tipoj priskribitaj komence de la artikolo.
Kio estas la komuna limigo de ĉiuj ĉi tiuj datumbazoj? Ĉi tiuj estas la kostoj de konstante uzata nubo aŭ aparatara servilo (aŭ pluraj serviloj). Ne gravas ĉu ni uzas klasikan aŭ administritan datumbazon, ĉu ni havas Devops kaj administranton aŭ ne, ni ankoraŭ pagas por luo de aparataro, elektro kaj datumcentro 24/7. Se ni havas klasikan bazon, ni pagas por mastro kaj sklavo. Se ĝi estas tre ŝarĝita sharded datumbazo, ni pagas por 10, 20 aŭ 30 serviloj, kaj ni pagas konstante.
La ĉeesto de konstante rezervitaj serviloj en la koststrukturo antaŭe estis perceptita kiel necesa malbono. Ankaŭ konvenciaj datumbazoj havas aliajn malfacilaĵojn, kiel limoj pri la nombro da konektoj, skallimigoj, geodistribuita konsento – ili iel povas esti solvitaj en certaj datumbazoj, sed ne ĉiuj samtempe kaj ne ideale.
Senservila datumbazo - teorio
Demando de 2020: ĉu ankaŭ eblas fari datumbazon senservilo? Ĉiuj aŭdis pri la senservila backend... ni provu fari la datumbazon senservila?
Ĉi tio sonas strange, ĉar la datumbazo estas plenplena servo, ne tre taŭga por senservila infrastrukturo. Samtempe, la stato de la datumbazo estas tre granda: gigabajtoj, terabajtoj, kaj en analizaj datumbazoj eĉ petabajtoj. Ne estas tiel facile levi ĝin en malpezaj Docker-ujoj.
Aliflanke, preskaŭ ĉiuj modernaj datumbazoj enhavas grandegan kvanton da logiko kaj komponantoj: transakcioj, integreckunordigo, proceduroj, interrilataj dependecoj kaj multe da logiko. Por sufiĉe multe da datumbaza logiko, malgranda stato sufiĉas. Gigabajtoj kaj Terabajtoj estas rekte uzitaj de nur malgranda parto de la datumbaza logiko implikita en rekte efektivigado de demandoj.
Sekve, la ideo estas: se parto de la logiko permesas sennacian ekzekuton, kial ne dividi la bazon en Stateful kaj Sennaciajn partojn.
Senservilo por OLAP-solvoj
Ni vidu kiel povus aspekti tranĉi datumbazon en Ŝtatajn kaj Sennaciajn partojn uzante praktikajn ekzemplojn.
Ekzemple, ni havas analizan datumbazon: eksteraj datumoj (ruĝa cilindro maldekstre), ETL-procezo, kiu ŝarĝas datumojn en la datumbazon, kaj analizisto, kiu sendas SQL-demandojn al la datumbazo. Ĉi tio estas klasika operacia skemo de datum-magazeno.
En ĉi tiu skemo, ETL estas kondiĉe farita unufoje. Tiam vi devas konstante pagi por la serviloj, sur kiuj la datumbazo funkcias kun datumoj plenigitaj per ETL, por ke estu io por sendi demandojn.
Ni rigardu alternativan aliron efektivigitan en AWS Athena Serverless. Ne ekzistas konstante dediĉita aparataro sur kiu elŝutitaj datumoj estas stokitaj. Anstataŭ ĉi tio:
- La uzanto sendas SQL-demandon al Athena. La Athena-optimumiganto analizas la SQL-demandon kaj serĉas la metadatuman vendejon (Metadatumoj) por la specifaj datumoj necesaj por efektivigi la demandon.
- La optimumigilo, bazita sur la kolektitaj datumoj, elŝutas la necesajn datumojn de eksteraj fontoj en provizoran stokadon (provizora datumbazo).
- SQL-demando de la uzanto estas efektivigita en provizora stokado kaj la rezulto estas resendita al la uzanto.
- Provizora stokado estas malbarita kaj rimedoj estas liberigitaj.
En ĉi tiu arkitekturo, ni nur pagas por la procezo de ekzekuto de la peto. Neniuj petoj - sen kostoj.
Ĉi tio estas funkcia aliro kaj estas efektivigita ne nur en Athena Serverless, sed ankaŭ en Redshift Spectrum (en AWS).
La ekzemplo de Athena montras, ke la senservila datumbazo funkcias pri realaj demandoj kun dekoj kaj centoj da Terabajtoj da datumoj. Centoj da Terabajtoj postulos centojn da serviloj, sed ni ne devas pagi por ili - ni pagas por la petoj. La rapideco de ĉiu peto estas (tre) malalta kompare kun fakaj analizaj datumbazoj kiel Vertica, sed ni ne pagas por malfunkciaj periodoj.
Tia datumbazo estas aplikebla por maloftaj analizaj ad-hoc-demandoj. Ekzemple, kiam ni spontanee decidas testi hipotezon pri iu giganta kvanto da datumoj. Athena estas perfekta por ĉi tiuj kazoj. Por regulaj petoj, tia sistemo estas multekosta. En ĉi tiu kazo, konservu la datumojn en iu speciala solvo.
Senservilo por OLTP-solvoj
La antaŭa ekzemplo rigardis OLAP (analizajn) taskojn. Nun ni rigardu OLTP-taskojn.
Ni imagu skaleblajn PostgreSQL aŭ MySQL. Ni levu regulan administritan petskribon PostgreSQL aŭ MySQL kun minimumaj rimedoj. Kiam la instanco ricevas pli da ŝarĝo, ni konektos pliajn kopiojn al kiuj ni distribuos parton de la legoŝarĝo. Se ne estas petoj aŭ ŝarĝo, ni malŝaltas la kopiojn. La unua okazo estas la majstro, kaj la ceteraj estas kopioj.
Ĉi tiu ideo estas efektivigita en datumbazo nomita Aurora Serverless AWS. La principo estas simpla: petoj de eksteraj aplikoj estas akceptitaj de la prokura floto. Vidante la ŝarĝon pliiĝi, ĝi asignas komputajn rimedojn de antaŭvarmigitaj minimumaj okazoj - la konekto fariĝas kiel eble plej rapide. Malebligaj okazoj okazas same.
Ene de Aŭrora ekzistas la koncepto de Aurora Capacity Unit, ACU. Ĉi tio estas (kondiĉe) petskribo (servilo). Ĉiu specifa ACU povas esti majstro aŭ sklavo. Ĉiu Kapacita Unuo havas sian propran RAM, procesoro kaj minimuma disko. Sekve, unu estas majstro, la ceteraj estas nur legeblaj kopioj.
La nombro de ĉi tiuj Aurora Kapaciunuoj funkcianta estas agordebla parametro. La minimuma kvanto povas esti unu aŭ nul (en ĉi tiu kazo, la datumbazo ne funkcias se ne ekzistas petoj).
Kiam la bazo ricevas petojn, la prokura floto altigas Aurora CapacityUnits, pliigante la rendimentajn rimedojn de la sistemo. La kapablo pliigi kaj malpliigi rimedojn permesas al la sistemo "ĵongli" rimedojn: aŭtomate montru individuajn ACU-ojn (anstataŭigante ilin per novaj) kaj disvolvu ĉiujn aktualajn ĝisdatigojn al la retiritaj rimedoj.
La Aurora Serverless-bazo povas grimpi la legan ŝarĝon. Sed la dokumentaro ne diras tion rekte. Eble sentas, ke ili povas levi plur-majstron. Ne ekzistas magio.
Ĉi tiu datumbazo taŭgas por eviti elspezi grandajn monsumojn por sistemoj kun neantaŭvidebla aliro. Ekzemple, dum kreado de MVP aŭ merkatado de vizitkartoj, ni kutime ne atendas stabilan ŝarĝon. Sekve, se ne ekzistas aliro, ni ne pagas por ekzemploj. Kiam neatendita ŝarĝo okazas, ekzemple post konferenco aŭ reklama kampanjo, amasoj da homoj vizitas la retejon kaj la ŝarĝo draste pliiĝas, Aurora Serverless aŭtomate prenas ĉi tiun ŝarĝon kaj rapide konektas la mankantajn rimedojn (ACU). Tiam la konferenco pasas, ĉiuj forgesas pri la prototipo, la serviloj (ACU) malheliĝas, kaj kostoj malaltiĝas - oportune.
Ĉi tiu solvo ne taŭgas por stabila alta ŝarĝo ĉar ĝi ne skalas la skribŝarĝon. Ĉiuj ĉi tiuj ligoj kaj malkonektiĝoj de rimedoj okazas ĉe la tiel nomata "skala punkto" - momento en kiu la datumbazo ne estas subtenata de transakcio aŭ provizoraj tabeloj. Ekzemple, ene de semajno la skalopunkto eble ne okazas, kaj la bazo funkcias per la samaj rimedoj kaj simple ne povas pligrandigi aŭ kontrakti.
Ne ekzistas magio - ĝi estas regula PostgreSQL. Sed la procezo aldoni maŝinojn kaj malkonekti ilin estas parte aŭtomatigita.
Senservilo laŭ dezajno
Aurora Serverless estas malnova datumbazo reverkita por la nubo por utiligi kelkajn el la avantaĝoj de Serverless. Kaj nun mi rakontos al vi pri la bazo, kiu estis origine skribita por la nubo, por la senservila aliro - Serverless-by-design. Ĝi tuj estis evoluigita sen la supozo, ke ĝi funkcios sur fizikaj serviloj.
Ĉi tiu bazo nomiĝas Snowflake. Ĝi havas tri ŝlosilajn blokojn.
La unua estas bloko de metadatumoj. Ĉi tio estas rapida en-memora servo, kiu solvas problemojn pri sekureco, metadatenoj, transakcioj kaj konsultoptimumigo (montrita en la ilustraĵo maldekstre).
La dua bloko estas aro de virtualaj komputilaj aretoj por kalkuloj (en la ilustraĵo estas aro de bluaj cirkloj).
La tria bloko estas datumstokado-sistemo bazita sur S3. S3 estas sendimensia objektostokado en AWS, kvazaŭ sendimensia Dropbox por komerco.
Ni vidu kiel funkcias Snowflake, supozante malvarman komencon. Tio estas, ekzistas datumbazo, la datumoj estas ŝarĝitaj en ĝi, ne ekzistas kurantaj demandoj. Sekve, se ne estas petoj al la datumbazo, tiam ni levis la rapidan en-memoran Metadatuman servon (unua bloko). Kaj ni havas S3-stokadon, kie tabelaj datumoj estas stokitaj, dividitaj en tielnomitajn mikrodiskojn. Por simpleco: se la tablo enhavas transakciojn, tiam mikrodiskoj estas la tagoj de transakcioj. Ĉiutage estas aparta mikrodisko, aparta dosiero. Kaj kiam la datumbazo funkcias en ĉi tiu reĝimo, vi nur pagas por la spaco okupita de la datumoj. Krome, la imposto por sidloko estas tre malalta (precipe konsiderante la gravan kunpremadon). La servo de metadatumoj ankaŭ funkcias konstante, sed vi ne bezonas multajn rimedojn por optimumigi demandojn, kaj la servo povas esti konsiderata shareware.
Nun ni imagu, ke uzanto venis al nia datumbazo kaj sendis SQL-demandon. La SQL-demando tuj estas sendita al la Metadatuma servo por prilaborado. Sekve, ricevinte peton, ĉi tiu servo analizas la peton, disponeblajn datumojn, uzantpermesojn kaj, se ĉio estas en ordo, ellaboras planon por prilabori la peton.
Poste, la servo komencas la lanĉon de la komputika areto. Komputila areto estas aro de serviloj, kiuj faras kalkulojn. Tio estas, ĉi tio estas areto, kiu povas enhavi 1 servilon, 2 servilojn, 4, 8, 16, 32 - tiom da kiom vi volas. Vi ĵetas peton kaj la lanĉo de ĉi tiu aro tuj komenciĝas. Ĝi vere prenas sekundojn.
Poste, post kiam la areto komenciĝis, la mikrodiskoj necesaj por procesi vian peton komencas esti kopiitaj en la areton de S3. Tio estas, ni imagu, ke por efektivigi SQL-demandon vi bezonas du sekciojn de unu tablo kaj unu el la dua. En ĉi tiu kazo, nur la tri necesaj sekcioj estos kopiitaj al la areto, kaj ne ĉiuj tabloj tute. Tial, kaj ĝuste ĉar ĉio situas ene de unu datumcentro kaj konektita per tre rapidaj kanaloj, la tuta transiga procezo okazas tre rapide: en sekundoj, tre malofte en minutoj, krom se ni parolas pri iuj monstraj petoj. Sekve, mikrodiskoj estas kopiitaj al la komputika areto, kaj, post kompletigo, la SQL-demando estas efektivigita sur ĉi tiu komputika areto. La rezulto de ĉi tiu peto povas esti unu linio, pluraj linioj aŭ tabelo - ili estas sendataj ekstere al la uzanto por ke li povu elŝuti ĝin, montri ĝin en sia BI-ilo aŭ uzi ĝin alimaniere.
Ĉiu SQL-demando povas ne nur legi agregaĵojn de antaŭe ŝarĝitaj datumoj, sed ankaŭ ŝargi/generi novajn datumojn en la datumbazo. Tio estas, ĝi povas esti demando, kiu, ekzemple, enmetas novajn rekordojn en alian tabelon, kio kondukas al apero de nova subdisko sur la komputika areto, kiu, siavice, estas aŭtomate konservita en ununura S3-stokado.
La scenaro priskribita supre, de la alveno de la uzanto ĝis la leviĝo de la areto, ŝarĝo de datumoj, plenumado de demandoj, akiro de rezultoj, estas pagita laŭ la rapideco por minutoj de uzado de la levita virtuala komputika areto, virtuala magazeno. La tarifo varias laŭ la AWS-zono kaj la grandeco de areto, sed averaĝe ĝi estas kelkaj dolaroj por horo. Areto de kvar maŝinoj estas duoble pli multekosta ol areto de du maŝinoj, kaj areto de ok maŝinoj estas ankoraŭ duoble pli multekosta. Opcioj de 16, 32 maŝinoj estas disponeblaj, depende de la komplekseco de la petoj. Sed vi pagas nur por tiuj minutoj, kiam la areto efektive funkcias, ĉar kiam ne estas petoj, vi iom deprenas viajn manojn, kaj post 5-10 minutoj da atendado (agordebla parametro) ĝi ekfunkcios memstare, liberigu rimedojn kaj fariĝu libera.
Tute realisma scenaro estas kiam vi sendas peton, la areto aperas, relative parolante, en minuto, ĝi kalkulas alian minuton, tiam kvin minutojn por fermi, kaj vi finas pagi por sep minutoj de funkciado de ĉi tiu areto, kaj ne dum monatoj kaj jaroj.
La unua scenaro priskribis uzi Snowflake en unu-uzanta agordo. Nun ni imagu, ke estas multaj uzantoj, kio estas pli proksima al la reala scenaro.
Ni diru, ke ni havas multajn analizistojn kaj Tableau-raportojn, kiuj konstante bombardas nian datumbazon per granda nombro da simplaj analizaj SQL-demandoj.
Krome, ni diru, ke ni havas inventemajn Datumajn Sciencistojn, kiuj provas fari monstrajn aferojn per datumoj, funkcii per dekoj da Terabajtoj, analizi miliardojn kaj duilionojn da vicoj da datumoj.
Por la du specoj de laborkvanto priskribitaj supre, Snowflake permesas al vi levi plurajn sendependajn komputigajn aretojn de malsamaj kapabloj. Plie, ĉi tiuj komputilaj aretoj funkcias sendepende, sed kun komunaj konsekvencaj datumoj.
Por granda nombro da malpezaj demandoj, vi povas levi 2-3 malgrandajn aretojn, proksimume 2 maŝinojn ĉiu. Ĉi tiu konduto povas esti efektivigita, interalie, uzante aŭtomatajn agordojn. Do vi diras: "Neĝfloko, levu malgrandan areton. Se la ŝarĝo sur ĝi pliiĝas super certa parametro, altigu similan sekundon, trionon. Kiam la ŝarĝo komencas malpliiĝi, estingu la troon." Por ke kiom ajn da analizistoj venos kaj ekrigardu raportojn, ĉiuj havas sufiĉe da rimedoj.
Samtempe, se analizistoj dormas kaj neniu rigardas la raportojn, la aretoj povas tute mallumiĝi, kaj vi ĉesas pagi por ili.
Samtempe, por pezaj demandoj (de Datumsciencistoj), vi povas levi unu tre grandan areton por 32 maŝinoj. Ĉi tiu areto ankaŭ estos pagita nur por tiuj minutoj kaj horoj, kiam via giganta peto funkcias tie.
La ŝanco priskribita supre permesas dividi ne nur 2, sed ankaŭ pli da specoj de laborŝarĝo en aretojn (ETL, monitorado, raporta materiigo,...).
Ni resumu Neĝflokon. La bazo kombinas belan ideon kaj realigeblan efektivigon. Ĉe ManyChat, ni uzas Snowflake por analizi ĉiujn datumojn, kiujn ni havas. Ni ne havas tri aretojn, kiel en la ekzemplo, sed de 5 ĝis 9, de malsamaj grandecoj. Ni havas konvenciajn 16-maŝinojn, 2-maŝinojn, kaj ankaŭ super-malgrandajn 1-maŝinojn por iuj taskoj. Ili sukcese distribuas la ŝarĝon kaj permesas al ni ŝpari multe.
La datumbazo sukcese skalas la legadon kaj skriban ŝarĝon. Ĉi tio estas grandega diferenco kaj grandega sukceso kompare kun la sama "Aŭroro", kiu nur portis la legan ŝarĝon. Snowflake permesas al vi skali vian skriban laborkvanton per ĉi tiuj komputikgrupoj. Tio estas, kiel mi menciis, ni uzas plurajn aretojn en ManyChat, malgrandaj kaj super-malgrandaj aretoj estas ĉefe uzataj por ETL, por ŝarĝi datumojn. Kaj analizistoj jam vivas sur mezaj aretoj, kiuj absolute ne estas tuŝitaj de la ETL-ŝarĝo, do ili funkcias tre rapide.
Sekve, la datumbazo bone taŭgas por OLAP-taskoj. Tamen, bedaŭrinde, ĝi ankoraŭ ne aplikeblas por OLTP-laborŝarĝoj. Unue, ĉi tiu datumbazo estas kolumna, kun ĉiuj sekvaj konsekvencoj. Due, la aliro mem, kiam por ĉiu peto, se necese, vi levas komputilan grapolon kaj inundas ĝin per datumoj, bedaŭrinde, ankoraŭ ne estas sufiĉe rapida por OLTP-ŝarĝoj. Atendu sekundojn por OLAP-taskoj estas normala, sed por OLTP-taskoj ĝi estas neakceptebla; 100 ms estus pli bona, aŭ 10 ms estus eĉ pli bona.
La rezulto
Senservila datumbazo eblas dividante la datumbazon en Sennaciajn kaj Ŝtatajn partojn. Vi eble rimarkis, ke en ĉiuj ĉi-supraj ekzemploj, la Ŝtata parto relative parolas konservas mikrodiskojn en S3, kaj Sennacia estas la optimumigilo, laborante kun metadatumoj, pritraktante sekurecajn problemojn, kiuj povas esti levitaj kiel sendependaj malpezaj Sennaciaj servoj.
Efektivigi SQL-demandojn ankaŭ povas esti perceptitaj kiel malpezaj servoj, kiuj povas aperi en senservila reĝimo, kiel Snowflake-komputikaj grupoj, elŝuti nur la necesajn datumojn, efektivigi la demandon kaj "eliri."
Senservilaj produktadnivelaj datumbazoj jam disponeblas por uzo, ili funkcias. Ĉi tiuj senservilaj datumbazoj jam pretas pritrakti OLAP-taskojn. Bedaŭrinde, por OLTP-taskoj ili estas uzataj... kun nuancoj, ĉar estas limigoj. Unuflanke, ĉi tio estas minuso. Sed, aliflanke, ĉi tio estas ŝanco. Eble unu el la legantoj trovos manieron fari OLTP-datumbazon tute senservila, sen la limigoj de Aŭrora.
Mi esperas, ke vi trovis ĝin interesa. Senservilo estas la estonteco :)
fonto: www.habr.com