Kaixo guztioi! Nire izena Golov Nikolay da. Aurretik, Aviton lan egin nuen eta sei urtez Datu Plataforma kudeatu nuen, hau da, datu-base guztietan lan egin nuen: analitikoa (Vertica, ClickHouse), streaminga eta OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Denbora horretan, datu-base ugari jorratu nituen - oso desberdinak eta ezohikoak, eta erabilera-kasu ez-estandarrak.
Gaur egun ManyChat-en nabil. Funtsean, startup bat da - berria, asmo handikoa eta azkar hazten ari dena. Eta konpainian sartu nintzenean, galdera klasiko bat sortu zen: "Zer hartu beharko luke orain startup gazte batek DBMS eta datu-baseen merkatutik?"
Artikulu honetan, nire txostenean oinarrituta , galdera honi erantzungo diot. Txostenaren bideo bertsioa hemen dago eskuragarri .
2020ko datu-base ezagunenak
2020a da, ingurura begiratu eta hiru datu-base mota ikusi nituen.
Lehenengo mota - OLTP datu-base klasikoak: PostgreSQL, SQL Server, Oracle, MySQL. Aspaldi idatzi ziren, baina oraindik garrantzitsuak dira garatzaileen komunitatearentzat oso ezagunak direlako.
Bigarren mota da "zero" oinarriak. Eredu klasikoetatik urruntzen saiatu ziren SQL, egitura tradizionalak eta ACID alde batera utziz, sharding integratua eta beste ezaugarri erakargarri batzuk gehituz. Adibidez, hau Cassandra, MongoDB, Redis edo Tarantool da. Soluzio horiek guztiek merkatuari funtsean zerbait berria eskaini nahi zioten eta beren nitxoa okupatu zuten, zeregin jakin batzuetarako oso erosoak zirelako. Datu-base hauek NOSQL termino nagusiarekin adieraziko ditut.
"Zeroak" amaitu dira, NOSQL datu-baseetara ohitu ginen eta munduak, nire ikuspuntutik, hurrengo urratsa eman zuen: kudeatutako datu-baseak. Datu-base hauek OLTP datu-base klasikoen edo NoSQL berrien core bera dute. Baina ez dute DBA eta DevOps beharrik eta kudeatutako hardwarean exekutatzen dira hodeietan. Garatzaile batentzat, hau nonbait funtzionatzen duen "oinarri bat besterik ez" da, baina inori ez zaio axola zerbitzarian nola instalatzen den, nork konfiguratu duen zerbitzaria eta nork eguneratzen duen.
Datu-base horien adibideak:
- AWS RDS PostgreSQL/MySQLrako kudeatutako bilgarri bat da.
- DynamoDB dokumentuetan oinarritutako datu-base baten AWS analogoa da, Redis eta MongoDB-ren antzekoa.
- Amazon Redshift kudeatutako datu-base analitiko bat da.
Funtsean datu-base zaharrak dira, baina kudeatutako ingurune batean sortuak, hardwarearekin lan egin beharrik gabe.
Ohar. Adibideak AWS ingurunerako hartu dira, baina haien analogoak Microsoft Azure, Google Cloud edo Yandex.Cloud-en ere badaude.
Zer berri dago honetaz? 2020an, hori ez.
Zerbitzaririk gabeko kontzeptua
2020an merkatuan dagoena zerbitzaririk gabeko edo zerbitzaririk gabeko irtenbideak dira.
Horrek zer esan nahi duen azaltzen saiatuko naiz ohiko zerbitzu edo backend aplikazio baten adibidea erabiliz.
Ohiko backend aplikazio bat zabaltzeko, zerbitzari bat erosten edo alokatzen dugu, bertan kodea kopiatzen dugu, amaierako puntua kanpoan argitaratzen dugu eta alokairua, elektrizitatea eta datu-zentroko zerbitzuak aldizka ordaintzen ditugu. Hau da eskema estandarra.
Ba al dago beste modurik? Zerbitzaririk gabeko zerbitzuekin dezakezu.
Zein da ikuspegi honen ardatza: ez dago zerbitzaririk, ez dago hodeian instantzia birtual bat alokatzea ere. Zerbitzua zabaltzeko, kopiatu kodea (funtzioak) biltegian eta argitaratu amaiera puntuan. Ondoren, funtzio honetarako dei bakoitza ordaintzen dugu, exekutatzen den hardwarea guztiz alde batera utzita.
Ikuspegi hau irudiekin ilustratzen saiatuko naiz.
Hedapen klasikoa. Karga jakin bat duen zerbitzu bat dugu. Bi instantzia planteatzen ditugu: zerbitzari fisikoak edo AWSko instantzia. Kanpoko eskaerak instantzia horietara bidaltzen dira eta bertan prozesatzen dira.
Irudian ikus dezakezun bezala, zerbitzariak ez dira berdin botatzen. Bata % 100 erabiltzen da, bi eskaera daude eta bestea % 50 baino ez dago - partzialki inaktiboa. Hiru eskaera iristen ez badira, baina 30, orduan sistema osoak ezin izango dio kargari aurre egin eta moteltzen hasiko da.
Zerbitzaririk gabeko inplementazioa. Zerbitzaririk gabeko ingurune batean, zerbitzu horrek ez du instantziarik edo zerbitzaririk. Berotutako baliabide multzo jakin bat dago: prestatutako Docker edukiontzi txikiak funtzio-kode zabaldua dutenak. Sistemak kanpoko eskaerak jasotzen ditu eta horietako bakoitzerako zerbitzaririk gabeko esparruak kodedun edukiontzi txiki bat sortzen du: eskaera zehatz hori prozesatzen du eta edukiontzia hiltzen du.
Eskaera bat - edukiontzi bat planteatu, 1000 eskaera - 1000 edukiontzi. Eta hardware zerbitzarietan zabaltzea hodeiko hornitzailearen lana da dagoeneko. Zerbitzaririk gabeko esparruak guztiz ezkutatuta dago. Kontzeptu honetan dei bakoitza ordaintzen dugu. Esaterako, dei bat etortzen zen egunean -dei bat ordaindu genuen, milioi bat minutuko etortzen zen- milioi bat ordaindu genuen. Edo segundo batean, hau ere gertatzen da.
Zerbitzaririk gabeko funtzio bat argitaratzearen kontzeptua estaturik gabeko zerbitzu baterako egokia da. Eta (egoera) zerbitzu osoa behar baduzu, datu-base bat gehitzen diogu zerbitzuari. Kasu honetan, egoerarekin lan egiteko orduan, egoera beteko funtzio bakoitzak datu-basetik idazten eta irakurtzen du. Gainera, artikuluaren hasieran deskribatutako hiru motatako edozein datu-base batetik.
Zein da datu-base horien guztien muga komuna? Etengabe erabiltzen den hodei edo hardware zerbitzari baten (edo hainbat zerbitzari) kostuak dira. Berdin du datu-base klasikoa edo kudeatutakoa erabiltzen dugun, Devops eta administratzaile bat izan ala ez, hardwarea, elektrizitatea eta datu-zentroen alokairua 24/7 ordaintzen dugu oraindik. Oinarri klasikoa badugu, nagusi eta esklabo ordaintzen ditugu. Oso kargatutako datu-base zatikatua bada, 10, 20 edo 30 zerbitzariengatik ordaintzen dugu, eta etengabe ordaintzen dugu.
Kostu-egituran betirako erreserbatutako zerbitzarien presentzia beharrezko gaitz gisa hautematen zen. Ohiko datu-baseek beste zailtasun batzuk ere badituzte, hala nola konexio-kopuruaren mugak, eskalatzeko murrizketak, geo-banatutako adostasuna: nolabait datu-base jakin batzuetan konpon daitezke, baina ez guztiak aldi berean eta ez modu egokian.
Zerbitzaririk gabeko datu-basea - teoria
2020ko galdera: posible al da datu-base bat zerbitzaririk gabe egitea? Denek entzun dute zerbitzaririk gabeko backendaren berri... saia gaitezen datu-basea zerbitzaririk gabe egiten?
Horrek arraroa dirudi, datu-basea egoera osoko zerbitzu bat delako, ez oso egokia zerbitzaririk gabeko azpiegituretarako. Aldi berean, datu-basearen egoera oso handia da: gigabyte, terabyte, eta datu-base analitikoetan baita petabyte ere. Ez da hain erraza Docker ontzi arinetan altxatzea.
Bestalde, ia datu-base moderno guztiek logika eta osagai ugari dituzte: transakzioak, osotasunaren koordinazioa, prozedurak, erlaziomenpekotasunak eta logika asko. Datu-base logika askorako, egoera txiki bat nahikoa da. Gigabyte eta Terabyte-k zuzenean kontsultak zuzenean exekutatzen parte hartzen duen datu-basearen logikaren zati txiki batek soilik erabiltzen ditu.
Horren arabera, ideia hau da: logikaren zati batek estaturik gabeko exekuzioa ahalbidetzen badu, zergatik ez zatitu oinarria Stateful eta Estaturik gabeko zatietan.
Zerbitzaririk gabeko OLAP soluzioetarako
Ikus dezagun datu-base bat Stateful eta Estaturik gabeko zatietan moztea nolakoa izan daitekeen adibide praktikoak erabiliz.
Adibidez, datu-base analitikoa dugu: kanpoko datuak (ezkerrean zilindro gorria), datu-basean datuak kargatzen dituen ETL prozesu bat eta datu-basera SQL kontsultak bidaltzen dituen analista. Datu-biltegiaren funtzionamendu-eskema klasikoa da.
Eskema honetan, ETL baldintzapean behin egiten da. Ondoren, datu-baseak ETLz betetako datuekin exekutatzen diren zerbitzariak etengabe ordaindu behar dituzu, kontsultak bidaltzeko zerbait egon dadin.
Ikus dezagun AWS Athena Serverless-en inplementatutako ikuspegi alternatibo bat. Ez dago deskargatutako datuak gordetzeko etengabeko hardware dedikaturik. Honen ordez:
- Erabiltzaileak SQL kontsulta bat bidaltzen dio Athenari. Athena optimizatzaileak SQL kontsulta aztertzen du eta metadatuen biltegian (Metadatuak) bilatzen ditu kontsulta exekutatzeko behar diren datu zehatzak.
- Optimizatzaileak, bildutako datuetan oinarrituta, kanpoko iturrietatik beharrezko datuak deskargatzen ditu aldi baterako biltegiratzera (datu-base aldi baterako).
- Erabiltzailearen SQL kontsulta bat aldi baterako biltegian exekutatzen da eta emaitza erabiltzaileari itzultzen zaio.
- Aldi baterako biltegiratzea garbitu eta baliabideak askatzen dira.
Arkitektura honetan, eskaera exekutatzeko prozesua bakarrik ordaintzen dugu. Ez dago eskaerarik - kosturik gabe.
Hau lan-ikuspegia da eta Athena Serverless-en ez ezik, Redshift Spectrum-en ere (AWSn) inplementatzen da.
Athena adibideak erakusten du Serverless datu-baseak hamarnaka eta ehunka Terabyte datu dituzten benetako kontsultetan lan egiten duela. Ehunka Terabytek ehunka zerbitzari beharko ditu, baina ez dugu ordaindu beharrik, eskaerak ordaintzen ditugu. Eskaera bakoitzaren abiadura (oso) baxua da Vertica bezalako datu-base analitiko espezializatuekin alderatuta, baina ez dugu ordaintzen geldialdi-aldiengatik.
Datu-base hori ad-hoc analitiko bakanetarako aplikagarria da. Adibidez, berez erabakitzen dugunean hipotesi bat datu kopuru erraldoi batean probatzea. Athena ezin hobea da kasu hauetarako. Ohiko eskaerak egiteko, sistema hori garestia da. Kasu honetan, gorde datuak soluzio espezializatu batean.
Zerbitzaririk gabeko OLTP soluzioetarako
Aurreko adibidean OLAP (analitikoak) zereginak aztertu ziren. Orain ikus ditzagun OLTP zereginak.
Imajina dezagun PostgreSQL edo MySQL eskalagarria. Sortu dezagun Kudeatutako PostgreSQL edo MySQL instantzia arrunt bat baliabide minimoekin. Instantziak karga gehiago jasotzen duenean, erreplika gehigarriak konektatuko ditugu eta haietara irakurketaren kargaren zati bat banatuko dugu. Eskaerarik eta kargarik ez badago, erreplikak itzaltzen ditugu. Lehen instantzia maisua da, eta gainerakoak erreplikak.
Ideia hau Aurora Serverless AWS izeneko datu-base batean ezartzen da. Printzipioa erraza da: kanpoko aplikazioen eskaerak proxy flotak onartzen ditu. Karga handitzen ari dela ikusita, aurrez berotutako gutxieneko instantzietatik esleitzen ditu informatika baliabideak - konexioa ahalik eta azkarren egiten da. Instantziak desgaitzea modu berean gertatzen da.
Auroraren barruan Aurora Capacity Unit kontzeptua dago, ACU. Hau (baldintzaz) instantzia (zerbitzaria) da. ACU zehatz bakoitza maisu edo esklabo izan daiteke. Edukiera Unitate bakoitzak bere RAM, prozesadorea eta disko minimoa ditu. Horren arabera, bat maisua da, gainerakoak irakurtzeko soilik erreplikak dira.
Aurora Edukiera Unitate hauen kopurua martxan dagoen parametro konfiguragarria da. Gutxieneko kantitatea bat edo zero izan daiteke (kasu honetan, datu-baseak ez du funtzionatzen eskaerarik ez badago).
Oinarriak eskaerak jasotzen dituenean, proxy flotak Aurora CapacityUnits igotzen du, sistemaren errendimendu baliabideak areagotuz. Baliabideak handitzeko eta murrizteko gaitasunak sistemari baliabideak "malabareak" egiteko aukera ematen dio: automatikoki bistaratu banakako ACUak (berriekin ordezkatuz) eta uneko eguneratze guztiak zabaldu kendutako baliabideei.
Aurora Serverless oinarriak irakurketa-karga eskala dezake. Baina dokumentazioak ez du hori zuzenean esaten. Baliteke multimaster bat altxa dezaketela sentitzea. Ez dago magiarik.
Datu-base hau oso egokia da ezusteko sarbiderik gabeko sistemetan diru kopuru handirik ez gastatzeko. Adibidez, MVP edo bisita-txartelen guneak merkaturatzean, normalean ez dugu karga egonkorrik espero. Horren arabera, sarbiderik ez badago, ez ditugu instantziengatik ordaintzen. Ustekabeko karga gertatzen denean, adibidez, konferentzia edo publizitate kanpaina baten ondoren, jende pila bisitatzen da gunea eta karga izugarri handitzen da, Aurora Serverless-ek automatikoki hartzen du karga hori eta azkar konektatzen ditu falta diren baliabideak (ACU). Ondoren, konferentzia pasatzen da, denek prototipoa ahazten dute, zerbitzariak (ACU) iluntzen dira eta kostuak zerora jaisten dira - erosoa.
Irtenbide hau ez da egokia karga altu egonkorrerako, idazketa-karga eskalatzen ez duelako. Baliabideen konexio eta deskonexio hauek guztiak "eskala-puntua" deritzonean gertatzen dira, datu-basea transakzio edo aldi baterako taulak onartzen ez duten une batean. Esate baterako, aste batean baliteke eskala puntua ez gertatzea, eta oinarriak baliabide berdinetan funtzionatzen du eta ezin du zabaldu edo uzkurtu.
Ez dago magiarik - PostgreSQL arrunta da. Baina makinak gehitzeko eta deskonektatzeko prozesua partzialki automatizatuta dago.
Zerbitzaririk gabeko diseinuaren arabera
Aurora Serverless hodeirako berridatzitako datu-base zahar bat da, Serverless-en abantaila batzuk aprobetxatzeko. Eta orain, jatorriz hodeirako idatzitako datu-baseari buruz kontatuko dizut zerbitzaririk gabeko ikuspegirako - Serverless-by-design. Berehala garatu zen zerbitzari fisikoetan exekutatuko zela suposatu gabe.
Oinarri honi Snowflake deitzen zaio. Hiru gako bloke ditu.
Lehenengoa metadatu bloke bat da. Segurtasunarekin, metadatuekin, transakzioekin eta kontsulten optimizazioarekin arazoak konpontzen dituen memoriako zerbitzu azkarra da (ezkerreko ilustrazioan ageri da).
Bigarren blokea kalkuluetarako konputazio-kluster birtualen multzo bat da (irudian zirkulu urdin multzo bat dago).
Hirugarren blokea S3-n oinarritutako datuak biltegiratzeko sistema da. S3 dimentsiorik gabeko objektuen biltegiratzea da AWSn, negozioetarako Dropbox dimentsiorik gabeko modukoa.
Ikus dezagun nola funtzionatzen duen Snowflake-k, hasiera hotz bat suposatuz. Hau da, datu-base bat dago, datuak bertan kargatzen dira, ez dago kontsultarik martxan. Horren arabera, datu-baserako eskaerarik ez badago, memoriako Metadatuen zerbitzu azkarra igo dugu (lehen blokea). Eta S3 biltegiratzea dugu, non taulen datuak gordetzen diren, mikropartizio deitzen direnetan banatuta. Sinpletasunerako: taulak transakzioak baditu, mikropartizioak transakzioen egunak dira. Egunero mikropartizio bereizia da, fitxategi bereizia. Eta datu-baseak modu honetan funtzionatzen duenean, datuek hartzen duten espazioagatik bakarrik ordaintzen duzu. Gainera, eserleku bakoitzeko tasa oso baxua da (batez ere konpresio nabarmena kontuan hartuta). Metadatuen zerbitzuak ere etengabe funtzionatzen du, baina ez duzu baliabide asko behar kontsultak optimizatzeko, eta zerbitzua sharewaretzat har daiteke.
Orain imajina dezagun erabiltzaile bat gure datu-basera etorri dela eta SQL kontsulta bat bidali duela. SQL kontsulta berehala bidaltzen da Metadatuen zerbitzura prozesatzeko. Horren arabera, eskaera bat jasotzean, zerbitzu honek eskaera, eskuragarri dauden datuak, erabiltzaileen baimenak aztertzen ditu eta, dena ondo badago, eskaera izapidetzeko plana egiten du.
Ondoren, zerbitzuak informatika-klusterra abiarazten du. Informatika-kluster bat kalkuluak egiten dituzten zerbitzarien multzoa da. Hau da, zerbitzari 1, 2 zerbitzari, 4, 8, 16, 32 izan ditzakeen kluster bat da, nahi adina. Eskaera bat botatzen duzu eta berehala hasten da kluster hau abiarazten. Benetan segundoak behar ditu.
Ondoren, klusterra hasi ondoren, zure eskaera prozesatzeko behar diren mikropartizioak S3-tik klusterera kopiatzen hasten dira. Hau da, pentsa dezagun SQL kontsulta bat exekutatzeko taula bateko bi partizio behar dituzula eta bigarreneko bat. Kasu honetan, beharrezkoak diren hiru partizioak bakarrik kopiatuko dira klusterera, eta ez taula guztiak guztiz. Horregatik, eta, hain zuzen, dena datu-zentro batean kokatuta dagoenez eta kanal oso azkarren bidez konektatuta dagoelako, transferentzia-prozesu osoa oso azkar gertatzen da: segundotan, oso gutxitan minututan, eskaera izugarri batzuei buruz ari ez bagara behintzat. Horren arabera, mikropartizioak informatika-klusterera kopiatzen dira, eta, amaitzean, SQL kontsulta exekutatzen da informatika-kluster honetan. Eskaera honen emaitza lerro bat, hainbat lerro edo taula izan daiteke; kanpotik bidaltzen zaizkio erabiltzaileari, deskargatu, bere BI tresnan bistaratu edo beste modu batean erabil dezan.
SQL kontsulta bakoitzak aldez aurretik kargatutako datuen agregatuak irakur ditzake, baina datu-basean datu berriak kargatu/sor ditzake. Hau da, kontsulta bat izan daiteke, adibidez, erregistro berriak beste taula batean txertatzen dituena, eta horrek partizio berri bat agertzea dakar informatika-klusterean, eta, aldi berean, automatikoki S3 biltegiratze bakarrean gordetzen da.
Goian deskribatutako eszenatokia, erabiltzailea iristen denetik klusterraren igoera arte, datuak kargatu, kontsultak exekutatu, emaitzak lortzen, igotako informatika-kluster birtuala, biltegi birtuala, erabiltzearen minutuen arabera ordaintzen da. Tasa aldatu egiten da AWS gunearen eta kluster tamainaren arabera, baina batez beste orduko dolar gutxi batzuk izaten dira. Lau makina multzo bat bi makina multzo bat baino bi aldiz garestiagoa da, eta zortzi makina multzo bat oraindik bi aldiz garestiagoa da. 16, 32 makina aukera daude eskuragarri, eskaeren konplexutasunaren arabera. Baina klusterra benetan martxan dagoenean soilik ordaintzen duzu, eskaerarik ez dagoenean eskuak kentzen dituzulako, eta 5-10 minutu itxaron ondoren (parametro konfiguragarria) bere kabuz itzali egingo da, baliabideak askatu eta aske bihurtu.
Eszenatoki guztiz errealista da eskaera bat bidaltzen duzunean, klusterra agertuko da, nahiko hitz eginez, minutu batean, beste minutu bat zenbatzen du, gero bost minutu ixteko, eta azkenean kluster honen zazpi minutuko funtzionamenduagatik ordaintzen duzu, eta ez hilabete eta urteetarako.
Snowflake erabiltzaile bakarreko ezarpen batean erabiliz deskribatutako lehenengo eszenatokia. Orain imajina dezagun erabiltzaile asko daudela, hau da, benetako eszenatokitik hurbilago dagoena.
Demagun analista eta Tableau-ren txosten asko ditugula gure datu-basea etengabe bonbardatzen dutenak SQL kontsulta analitiko soil ugarirekin.
Horrez gain, demagun datuekin gauza ikaragarriak egiten saiatzen ari diren Datu-zientzilari asmatzaileak ditugula, hamarnaka Terabyterekin funtzionatzen dutenak, bilioi eta bilioi datu-lerroak aztertzen dituztenak.
Goian deskribatutako bi lan-karga motetarako, Snowflake-k ahalmen ezberdinetako hainbat konputazio-kluster independente igo ditzakezu. Gainera, informatika-kluster hauek modu independentean lan egiten dute, baina datu koherente komunekin.
Kontsulta arin asko egiteko, 2-3 multzo txiki igo ditzakezu, gutxi gorabehera 2 makina bakoitza. Jokabide hau ezarpen automatikoak erabiliz gauzatu daiteke, besteak beste. Beraz, diozu: “Elur maluta, altxa kumulu txiki bat. Haren gaineko karga parametro jakin batetik gora handitzen bada, igo antzeko segundo bat, hirugarrena. Karga jaisten hasten denean, itzali gehiegizkoa». Beraz, zenbat analista etorri eta txostenak aztertzen hasi, denek nahikoa baliabide dituzte.
Aldi berean, analistak lo badaude eta inork ez baditu txostenak begiratzen, klusterrak guztiz ilundu daitezke, eta horiek ordaintzeari uzten diozu.
Aldi berean, kontsulta astunetarako (Data Scientists-en eskutik), 32 makinentzako kluster oso handi bat sor dezakezu. Kluster hau zure eskaera erraldoia bertan martxan dagoen minutu eta orduengatik bakarrik ordainduko da.
Goian azaldutako aukerak 2 ez ezik, lan-karga mota gehiago ere klusteretan banatzeko aukera ematen du (ETL, jarraipena, txostenaren materializazioa,...).
Labur dezagun Snowflake. Oinarriak ideia eder bat eta inplementazio egingarria konbinatzen ditu. ManyChat-en, Snowflake erabiltzen dugu ditugun datu guztiak aztertzeko. Ez ditugu hiru multzo, adibidean bezala, 5etik 9ra baizik, tamaina ezberdinetakoak. 16 makina konbentzionalak, 2 makina, eta 1 makina oso txikiak ere baditugu zeregin batzuetarako. Zama arrakastaz banatzen dute eta asko aurrezteko aukera ematen digute.
Datu-baseak ondo eskalatzen du irakurketa eta idazketa karga. Ezberdintasun handia eta aurrerapen handia da "Aurora" berarekin alderatuta, irakurketa-karga bakarrik eraman zuena. Snowflake-k zure idazketa lan-karga eskalatzeko aukera ematen dizu informatika-kluster hauekin. Hau da, aipatu dudan bezala, ManyChat-en hainbat kluster erabiltzen ditugu, kluster txikiak eta super-txikiak batez ere ETLrako erabiltzen dira, datuak kargatzeko. Eta analistak dagoeneko kluster ertainetan bizi dira, ETL kargak erabat eragiten ez dutenak, beraz, oso azkar lan egiten dute.
Horren arabera, datu-basea ondo egokitzen da OLAP zereginetarako. Dena den, zoritxarrez, oraindik ez da aplikagarria OLTP lan kargarentzat. Lehenik eta behin, datu-base hau zutabea da, ondoriozko ondorio guztiekin. Bigarrenik, ikuspegia bera, eskaera bakoitzerako, behar izanez gero, informatika-kluster bat planteatzen duzunean eta datuz gainezka egiten duzunean, zoritxarrez, oraindik ez da nahikoa azkarra OLTP kargak egiteko. OLAP zereginetarako segundo itxarotea normala da, baina OLTP zereginetarako onartezina da; 100 ms hobea izango litzateke, edo 10 ms are hobea.
Guztira
Zerbitzaririk gabeko datu-base bat posible da datu-basea Estaturik gabeko eta Estatuko zatietan banatuz. Konturatuko zinen goiko adibide guztietan Stateful zatia, nahiko hitz eginda, mikro-partizioak gordetzen dituela S3-n, eta Stateless-a optimizatzailea dela, metadatuekin lan egiten duena, Estaturik gabeko zerbitzu arin independente gisa plantea daitezkeen segurtasun-arazoak kudeatzen dituela.
SQL kontsultak exekutatzea zerbitzaririk gabeko moduan ager daitezkeen egoera arineko zerbitzu gisa ere hauteman daiteke, Snowflake informatika-klusterrak bezala, beharrezko datuak soilik deskargatu, kontsulta exekutatu eta "kanpora".
Zerbitzaririk gabeko ekoizpen-mailako datu-baseak erabilgarri daude dagoeneko, lanean ari dira. Zerbitzaririk gabeko datu-base hauek OLAP zereginak kudeatzeko prest daude dagoeneko. Zoritxarrez, OLTP zereginetarako erabiltzen dira... ñabardurarekin, mugak baitaude. Alde batetik, hori ken bat da. Baina, bestalde, aukera bat da hau. Beharbada, irakurleetako batek aurkituko du OLTP datu-base bat zerbitzaririk gabe egiteko modua, Auroraren mugarik gabe.
Espero dut interesgarria iruditu izana. Zerbitzaririk gabeko etorkizuna da :)
Iturria: www.habr.com