Depozita e p\u00ebrkohshme pastron, burimet lirohen.<\/li>\n<\/ul>\nN\u00eb k\u00ebt\u00eb arkitektur\u00eb, ne paguajm\u00eb vet\u00ebm p\u00ebr procesin e ekzekutimit t\u00eb k\u00ebrkes\u00ebs. Nuk ka k\u00ebrkesa \u2014 nuk ka shpenzime.<\/p>\n
N\u00eb shembujt e Athena shihet se baza e t\u00eb dh\u00ebnave Serverless funksionon me k\u00ebrkesa reale me dhjet\u00ebra dhe qindra Terabajt t\u00eb dh\u00ebnash. P\u00ebr qindra Terabajt do t\u00eb nevojiteshin qindra server\u00eb, por ne nuk kemi nevoj\u00eb t\u00eb paguajm\u00eb p\u00ebr ta \u2014 ne paguajm\u00eb p\u00ebr k\u00ebrkesat. Shpejt\u00ebsia e \u00e7do k\u00ebrkese \u00ebsht\u00eb (shum\u00eb) e ul\u00ebt n\u00eb krahasim me bazat e dh\u00ebnash analitike t\u00eb specializuara si Vertica, por p\u00ebr k\u00ebt\u00eb arsye nuk paguajm\u00eb p\u00ebr periudhat e q\u00ebndrimit.<\/p>\n
Nj\u00eb baz\u00eb e till\u00eb e t\u00eb dh\u00ebnave \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr k\u00ebrkesa analitike ad-hoc t\u00eb ralla. P\u00ebr shembull, kur ne spontanisht vendosim t\u00eb verifikojm\u00eb nj\u00eb hipotez\u00eb mbi nj\u00eb volum t\u00eb madh t\u00eb t\u00eb dh\u00ebnash. P\u00ebr k\u00ebto raste Athena \u00ebsht\u00eb ideale. P\u00ebr k\u00ebrkesat e rregullta, nj\u00eb sistem i till\u00eb b\u00ebhet i shtrenjt\u00eb. N\u00eb k\u00ebt\u00eb rast ruani t\u00eb dh\u00ebnat n\u00eb ndonj\u00eb zgjidhje t\u00eb specializuar. <\/p>\n
Serverless p\u00ebr zgjidhjet OLTP<\/h2>\n \nN\u00eb shembullin e m\u00ebparsh\u00ebm u diskutuan detyrat OLAP (analitike). Tani do t\u00eb shqyrtojm\u00eb detyrat OLTP.<\/p>\n
T\u00eb imagjinoni nj\u00eb PostgreSQL ose MySQL n\u00eb shkall\u00ebzueshme. Le t\u00eb ngrem\u00eb nj\u00eb instanc\u00eb t\u00eb menaxhuar t\u00eb zakonshme PostgreSQL ose MySQL me burime minimale. Kur instanca t\u00eb p\u00ebrballet me nj\u00eb ngarkes\u00eb m\u00eb t\u00eb madhe, ne do t\u00eb lidhim replika t\u00eb tjera, mbi t\u00eb cilat do t\u00eb shp\u00ebrndajm\u00eb nj\u00eb pjes\u00eb t\u00eb ngarkes\u00ebs lexuese. N\u00ebse nuk ka k\u00ebrkesash dhe ngarkesash - \u00e7aktivizojm\u00eb replikat. Instanca e par\u00eb \u00ebsht\u00eb master, nd\u00ebrsa t\u00eb tjerat jan\u00eb replika.<\/p>\n
Kjo ide \u00ebsht\u00eb realizuar n\u00eb nj\u00eb baz\u00eb t\u00eb quajtur Aurora Serverless AWS. Parimi \u00ebsht\u00eb i thjesht\u00eb: k\u00ebrkesat nga aplikacionet e jashtme pranohen nga flota proxy. Duke par\u00eb rritjen e ngarkes\u00ebs, ai alokon burime llogarit\u00ebse nga instancat minimale t\u00eb ngrira paraprakisht - lidhja realizohet sa m\u00eb shpejt t\u00eb jet\u00eb e mundur. \u00c7aktivizimi i instancave ndodh po ashtu.<\/p>\n
Brenda Aurora-s ekziston koncepti i Nj\u00ebsis\u00eb s\u00eb Kapacitetit Aurora, ACU. Kjo \u00ebsht\u00eb (n\u00eb m\u00ebnyr\u00eb t\u00eb kushtezuar) - nj\u00eb instanc\u00eb (server). \u00c7do ACU konkret mund t\u00eb jet\u00eb master ose slave. \u00c7do Nj\u00ebsi Kapaciteti ka memorjen e saj t\u00eb p\u00ebrkohshme, procesorin dhe nj\u00eb disk minimal. Prandaj, nj\u00eb master, nd\u00ebrsa tjerat jan\u00eb replika vet\u00ebm p\u00ebr lexim.<\/p>\n
Numri i k\u00ebtyre Nj\u00ebsive t\u00eb Kapacitetit Aurora n\u00eb funksion \u00ebsht\u00eb nj\u00eb parameter i konfigurable. Numri minimal mund t\u00eb jet\u00eb nj\u00eb ose zero (n\u00eb k\u00ebt\u00eb rast, baza nuk funksionon n\u00ebse nuk ka k\u00ebrkesa).<\/p>\n
Baza Aurora Serverless mund t\u00eb shkall\u00ebzoj\u00eb ngarkes\u00ebn lexuese. Por n\u00eb dokumentacion nuk thuhet drejtp\u00ebrdrejt p\u00ebr k\u00ebt\u00eb. Mund t\u00eb krijohet ndjenja se ata mund t\u00eb ngrejn\u00eb multi-master. Nuk ka ndonj\u00eb magji k\u00ebtu. <\/p>\n
Kjo baz\u00eb \u00ebsht\u00eb shum\u00eb e p\u00ebrshtatshme p\u00ebr t\u00eb shmangur shpenzimet e m\u00ebdha p\u00ebr sisteme me qasje t\u00eb paqart\u00eb. P\u00ebr shembull, kur krijojm\u00eb nj\u00eb MVP ose faqesh\u00ebngjyrash marketingu, zakonisht nuk presim nj\u00eb ngarkes\u00eb t\u00eb q\u00ebndrueshme. Prandaj, n\u00eb rast mos qasje, ne nuk paguajm\u00eb p\u00ebr instancat. Kur papritmas shfaqet ngarkesa, p\u00ebr shembull pas nj\u00eb konference ose fushate reklamimi, turmat e njer\u00ebzve hyjn\u00eb n\u00eb faqe dhe ngarkesa rritet ndjesh\u00ebm; Aurora Serverless automatikisht pranon k\u00ebt\u00eb ngarkes\u00eb dhe lidh shpejt burimet q\u00eb mungojn\u00eb (ACU). M\u00eb pas, konferenca kalon, t\u00eb gjith\u00eb e harrojn\u00eb prototipin, serverat (ACU) fik\u00ebn dhe shpenzimet bien n\u00eb zero - e p\u00ebrshtatshme.<\/p>\n
Ky zgjidhje nuk \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr ngarkes\u00eb t\u00eb lart\u00eb t\u00eb q\u00ebndrueshme, sepse ajo nuk di t\u00eb shkall\u00ebzoj\u00eb ngarkes\u00ebn e shkrimit. T\u00eb gjitha k\u00ebto lidhje dhe \u00e7lodhje burimesh ndodhin n\u00eb momentin e ashtuquajtur 'scale point' - momenti kur baza nuk mbahet nga transaksionet, as nga tabelat p\u00ebrkohshme. P\u00ebr shembull, gjat\u00eb nj\u00eb jave mund t\u00eb mos ndodh\u00eb scale point dhe baza punon me t\u00eb nj\u00ebjtat burime dhe thjesht nuk mund t\u00eb zgjer\u00eb apo t\u00eb ngushtohet. <\/p>\n
Nuk ka magji - ky \u00ebsht\u00eb PostgreSQL i zakonsh\u00ebm. Por procesi i shtimit dhe \u00e7lodhjes t\u00eb makinave \u00ebsht\u00eb pjes\u00ebrisht automatizuar.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless \u00ebsht\u00eb nj\u00eb baz\u00eb e vjet\u00ebr, e shkruar p\u00ebr n\u00eb cloud, p\u00ebr t\u00eb p\u00ebrdorur avantazhet specifike t\u00eb Serverless. Tani do t\u00eb flas p\u00ebr nj\u00eb baz\u00eb q\u00eb \u00ebsht\u00eb projektuar q\u00eb nga fillimi p\u00ebr n\u00eb cloud, me qasjen serverless - Serverless-by-design. Ajo \u00ebsht\u00eb zhvilluar menj\u00ebher\u00eb pa supozuar se do t\u00eb funksiononte n\u00eb server\u00eb fizik\u00eb.<\/p>\n
Kjo baz\u00eb quhet Snowflake. Ajo ka tre blloqe kryesore.<\/p>\n
Blloku i dyt\u00eb - \u00ebsht\u00eb nj\u00eb num\u00ebr i madh i klaster\u00ebve virtual\u00eb p\u00ebrllogarit\u00ebs p\u00ebr llogaritjet (n\u00eb ilustrimin - nj\u00eb grup topash blu).<\/p>\n
Blloku i tret\u00eb - \u00ebsht\u00eb sistemi i ruajtjes s\u00eb t\u00eb dh\u00ebnave mbi baz\u00ebn S3. S3 \u00ebsht\u00eb nj\u00eb ruajtje objektesh e pandar\u00eb n\u00eb AWS, di\u00e7ka si nj\u00eb Dropbox i pandar\u00eb p\u00ebr biznes.<\/p>\n
Le t\u00eb shohim se si funksionon Snowflake, duke supozuar nj\u00eb fillim t\u00eb ftoht\u00eb. K\u00ebshtu q\u00eb kemi baz\u00ebn, t\u00eb dh\u00ebnat jan\u00eb ngarkuar n\u00eb t\u00eb, por nuk ka k\u00ebrkesa t\u00eb ekzekutueshme. Prandaj, n\u00ebse nuk ka k\u00ebrkesa p\u00ebr baz\u00ebn, ne kemi ngritur nj\u00eb sh\u00ebrbim Metadata me shpejt\u00ebsi t\u00eb lart\u00eb n\u00eb memorie (bloku i par\u00eb). Dhe kemi nj\u00eb depo S3, ku ruhen t\u00eb dh\u00ebnat e tabelave, t\u00eb ndara n\u00eb at\u00eb q\u00eb quhet mikro-partita. Thjesht: n\u00ebse tabela p\u00ebrmban transaksione, mikro-partita jan\u00eb dit\u00ebt e transaksioneve. \u00c7do dit\u00eb \u00ebsht\u00eb nj\u00eb mikro-partit\u00eb e ve\u00e7ant\u00eb, nj\u00eb skedar i ve\u00e7ant\u00eb. Dhe kur baza punon n\u00eb k\u00ebt\u00eb mod, ju paguani vet\u00ebm p\u00ebr hap\u00ebsir\u00ebn e z\u00ebn\u00eb nga t\u00eb dh\u00ebnat. \u00c7mimi p\u00ebr hap\u00ebsir\u00ebn \u00ebsht\u00eb shum\u00eb i ul\u00ebt (ve\u00e7an\u00ebrisht n\u00eb marr\u00ebveshje me kompresimin e konsideruesh\u00ebm). Sh\u00ebrbimi i metadatave gjithashtu punon vazhdimisht, por p\u00ebr optimizimin e k\u00ebrkesave nuk k\u00ebrkon shum\u00eb burime dhe sh\u00ebrbimi mund t\u00eb konsiderohet kushtimisht falas. <\/p>\n
Tani imagjinoni se nj\u00eb p\u00ebrdorues i \u00ebsht\u00eb afruar baz\u00ebs son\u00eb dhe ka d\u00ebrguar nj\u00eb k\u00ebrkes\u00eb SQL. K\u00ebrkesa SQL menj\u00ebher\u00eb procedohet n\u00eb sh\u00ebrbimin Metadata. Pra, pasi merr k\u00ebrkes\u00ebn, ky sh\u00ebrbim analizon k\u00ebrkes\u00ebn, t\u00eb dh\u00ebnat e disponueshme, autorizimet e p\u00ebrdoruesit dhe, n\u00ebse gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull, p\u00ebrgatit nj\u00eb plan p\u00ebr p\u00ebrpunimin e k\u00ebrkes\u00ebs.<\/p>\n
M\u00eb pas, sh\u00ebrbimi iniciaton aktivizimin e grupit t\u00eb llogaritjes. Grupi i llogaritjes \u00ebsht\u00eb nj\u00eb grup server\u00ebsh q\u00eb kryejn\u00eb llogaritjet. K\u00ebshtu q\u00eb ky grup mund t\u00eb p\u00ebrmbaj\u00eb 1 server, 2 server\u00eb, 4, 8, 16, 32 \u2014 sa t\u00eb d\u00ebshironi. Ju d\u00ebrgoni k\u00ebrkes\u00ebn dhe menj\u00ebher\u00eb fillon aktivizimi i k\u00ebtij grupi. Kjo v\u00ebrtet merr disa sekonda.<\/p>\n
\u00c7do k\u00ebrkes\u00eb SQL nuk mund vet\u00ebm t\u00eb llogaris\u00eb agregat nga t\u00eb dh\u00ebnat e ngarkuara m\u00eb par\u00eb, por gjithashtu t\u00eb ngarkoj\u00eb\/krijoj\u00eb t\u00eb dh\u00ebna t\u00eb reja n\u00eb baz\u00eb. Kjo do t\u00eb thot\u00eb q\u00eb mund t\u00eb jet\u00eb nj\u00eb k\u00ebrkes\u00eb q\u00eb, p\u00ebr shembull, realizon nj\u00eb insertim n\u00eb nj\u00eb tabel\u00eb tjet\u00ebr t\u00eb sh\u00ebnimeve t\u00eb reja, e cila \u00e7on n\u00eb shfaqjen e nj\u00eb partie t\u00eb re n\u00eb klasterin llogarit\u00ebs, e cila, nga ana e saj, automatikisht ruhet n\u00eb depozit\u00ebn unike S3.<\/p>\n
Skenari i p\u00ebrshkruar m\u00eb sip\u00ebr, nga ardhja e p\u00ebrdoruesit deri n\u00eb ngritjes e klasterit, ngarkimi i t\u00eb dh\u00ebnave, ekzekutimi i k\u00ebrkesave, marrja e rezultateve, paguhet sipas tarif\u00ebs p\u00ebr minutat e p\u00ebrdorimit t\u00eb klasterit t\u00eb ngritur virtual, warehouse virtual. Tarifa varion n\u00eb var\u00ebsi t\u00eb zon\u00ebs AWS dhe madh\u00ebsis\u00eb s\u00eb klasterit, por, mesatarisht, \u00ebsht\u00eb disa dollar\u00eb n\u00eb or\u00eb. Klasteri me kat\u00ebr makina \u00ebsht\u00eb dy her\u00eb m\u00eb i shtrenjt\u00eb se ai me dy makina, dhe ai me tet\u00eb makina \u00ebsht\u00eb edhe dy her\u00eb m\u00eb i shtrenjt\u00eb. Jan\u00eb t\u00eb disponueshme variante nga 16, 32 makina, var\u00ebsisht nga kompleksiteti i k\u00ebrkesave. Por ju paguani vet\u00ebm p\u00ebr minutat kur klasteri \u00ebsht\u00eb realisht n\u00eb pun\u00eb, sepse, kur nuk ka k\u00ebrkesa, si t\u00eb thuash, hiqni duar nga tastiera, dhe pas 5-10 minutash pritjeje (parametri i rregulluesh\u00ebm), ai vet\u00eb do t\u00eb fiket, do t\u00eb \u00e7liroj\u00eb burimet dhe do t\u00eb b\u00ebhet falas.<\/p>\n
Nj\u00eb skenar absolutisht realist \u00ebsht\u00eb ai ku ju d\u00ebrgoni nj\u00eb k\u00ebrkes\u00eb, klasteri shfaqet, mund\u00ebsisht, p\u00ebr nj\u00eb minut\u00eb, dhe p\u00ebr nj\u00eb minut\u00eb tjet\u00ebr ai llogaritet, m\u00eb pas pes\u00eb minuta p\u00ebr t\u00eb fikur, dhe n\u00eb fund paguani p\u00ebr shtat\u00eb minuta funksionimi t\u00eb k\u00ebtij klasteri, dhe jo p\u00ebr muaj dhe vite.<\/p>\n
Skenari i par\u00eb p\u00ebrshkruante p\u00ebrdorimin e Snowflake n\u00eb nj\u00eb version p\u00ebr nj\u00eb p\u00ebrdorues. Tani le t\u00eb imagjinojm\u00eb se ka shum\u00eb p\u00ebrdorues, q\u00eb \u00ebsht\u00eb m\u00eb af\u00ebr skenarit real.<\/p>\n
Supozoni se kemi shum\u00eb analist\u00eb dhe raporte Tableau q\u00eb vazhdimisht bombardojn\u00eb baz\u00ebn ton\u00eb me shum\u00eb SQL-llogari analitike t\u00eb thjeshta.<\/p>\n
P\u00ebrve\u00e7 k\u00ebsaj, le t\u00eb supozojm\u00eb se kemi DSC (Shkenc\u00ebtar\u00eb t\u00eb Dh\u00ebnash) shpik\u00ebs q\u00eb p\u00ebrpiqen t\u00eb b\u00ebjn\u00eb gj\u00ebra t\u00eb frikshme me t\u00eb dh\u00ebnat, duke operuar me dhjet\u00ebra Terabajt, analizuar miliarda e triliona rreshtash t\u00eb dh\u00ebnash. <\/p>\n
P\u00ebr dy llojet e ngarkesave t\u00eb p\u00ebrshkruara m\u00eb sip\u00ebr, Snowflake lejon ngritjen e disa klaster\u00ebsh t\u00eb pavarur t\u00eb llojeve t\u00eb ndryshme t\u00eb fuqis\u00eb. K\u00ebta klaster\u00eb t\u00eb llogaritjes punojn\u00eb pavar\u00ebsisht, por me t\u00eb dh\u00ebna t\u00eb p\u00ebrbashk\u00ebta t\u00eb koherente.<\/p>\n
P\u00ebr nj\u00eb sasi t\u00eb madhe k\u00ebrkesash t\u00eb lehta, mund t\u00eb ngrini 2-3 klaster\u00eb t\u00eb vegj\u00ebl, me nj\u00eb p\u00ebrmas\u00eb, mund\u00ebsisht, 2 makina secila. Ky veprim \u00ebsht\u00eb i realizuesh\u00ebm, gjithashtu, me an\u00eb t\u00eb konfigurimeve automatike. Pra, ju thoni: \"Snowflake, ngrit nj\u00eb klaster t\u00eb vog\u00ebl. N\u00ebse ngarkesa rritet m\u00eb shum\u00eb se nj\u00eb paramet\u00ebr t\u00eb caktuar, ngrit nj\u00eb t\u00eb dyt\u00eb, t\u00eb tret\u00eb t\u00eb ngjash\u00ebm. Kur ngarkesa t\u00eb filloj\u00eb t\u00eb bjer\u00eb - fikni t\u00eb tep\u00ebrtit.\" T\u00eb siguroheni q\u00eb, pavar\u00ebsisht nga sa analist\u00eb vijn\u00eb dhe fillojn\u00eb t\u00eb shikojn\u00eb raportet, t\u00eb gjith\u00eb t\u00eb ken\u00eb burime t\u00eb mjaftueshme.<\/p>\n
N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, n\u00ebse analist\u00ebt flen\u00eb, dhe raportet nuk shikohen nga askush - klaster\u00ebt mund t\u00eb fik\u00ebn plot\u00ebsisht dhe ju ndaloni pages\u00ebn p\u00ebr ta.<\/p>\n
N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, p\u00ebr k\u00ebrkesa t\u00eb r\u00ebnda (nga DSC), mund t\u00eb ngrini nj\u00eb klaster shum\u00eb t\u00eb madh me nj\u00eb num\u00ebr t\u00eb supozuar prej 32 makinash. Ky klaster gjithashtu do t\u00eb paguhet vet\u00ebm p\u00ebr minutat dhe or\u00ebt kur atje funksionon k\u00ebrkesa juaj gjigande.<\/p>\n
Kjo mund\u00ebsi e p\u00ebrshkruar m\u00eb sip\u00ebr lejon ndarjen sipas klaster\u00ebve jo vet\u00ebm dy, por edhe m\u00eb shum\u00eb lloje ngarkesash (ETL, monitorim, materializim raporte, ...).<\/p>\n
T\u00eb b\u00ebjm\u00eb nj\u00eb p\u00ebrmbledhje p\u00ebr Snowflake. Database kombinon nj\u00eb ide t\u00eb bukur dhe nj\u00eb implementim funksional. N\u00eb ManyChat ne p\u00ebrdorim Snowflake p\u00ebr analitik\u00ebn e t\u00eb dh\u00ebnave q\u00eb kemi. Ne kemi m\u00eb shum\u00eb se tre grupe, si\u00e7 \u00ebsht\u00eb shembulli, nga 5 n\u00eb 9, me madh\u00ebsi t\u00eb ndryshme. Kemi grupe me 16 makinave, 2 makinash, dhe kemi edhe super-t\u00eb vogla me 1 makin\u00eb p\u00ebr disa detyra. Ato shp\u00ebrndajn\u00eb ngarkes\u00ebn me sukses dhe na lejojn\u00eb t\u00eb kursejm\u00eb shum\u00eb.<\/p>\n
Database me sukses shkall\u00ebzon ngarkes\u00ebn lexuese dhe shkruese. Ky \u00ebsht\u00eb nj\u00eb ndryshim i Madh dhe nj\u00eb hap i madh p\u00ebrpara krahasuar me \"Aurora\", e cila trajtonte vet\u00ebm ngarkes\u00ebn lexuese. Snowflake lejon q\u00eb k\u00ebto grupe kompjuterike t\u00eb shkall\u00ebzojn\u00eb edhe ngarkes\u00ebn shkruese. Pra, si\u00e7 p\u00ebrmenda, ne n\u00eb ManyChat p\u00ebrdorim disa grupe, grupe t\u00eb vogla dhe super t\u00eb vogla p\u00ebrdoren kryesisht p\u00ebr ETL, p\u00ebr ngarkimin e t\u00eb dh\u00ebnave. Dhe analist\u00ebt punojn\u00eb n\u00eb grupe mesatare, t\u00eb cilat nuk preken nga ngarkesa ETL, prandaj punojn\u00eb shum\u00eb shpejt. <\/p>\n
Meqen\u00ebse, database \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr detyra OLAP. Nd\u00ebrkoh\u00eb, me keqardhje, p\u00ebr ngarkesat OLTP nuk \u00ebsht\u00eb ende e aplikueshme. S\u00eb pari, kjo baz\u00eb \u00ebsht\u00eb kolonuese, me t\u00eb gjitha pasojat q\u00eb dalin nga kjo. S\u00eb dyti, vet\u00eb qasja, kur p\u00ebr \u00e7do k\u00ebrkes\u00eb rritni nj\u00eb grup kompjuterik sipas nevoj\u00ebs dhe e derdhni at\u00eb me t\u00eb dh\u00ebna, p\u00ebr fat t\u00eb keq, p\u00ebr ngarkesat OLTP ende nuk \u00ebsht\u00eb e mjaftueshme e shpejt\u00eb. Sekondat e pritjes p\u00ebr detyrat OLAP jan\u00eb normale, por p\u00ebr detyrat OLTP - \u00ebsht\u00eb e papranueshme, do t\u00eb ishte m\u00eb mir\u00eb 100 ms, dhe akoma m\u00eb mir\u00eb - 10 ms.<\/p>\n
P\u00ebrfundimi<\/h2>\n \nDatabase pa server \u00ebsht\u00eb e mundur p\u00ebrmes ndarjes s\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave n\u00eb pjes\u00eb Stateless dhe Stateful. Ju ndoshta keni v\u00ebn\u00eb re se n\u00eb t\u00eb gjitha shembujt e dh\u00ebn\u00eb, pjesa Stateful - \u00ebsht\u00eb, n\u00eb terma t\u00eb qart\u00eb, ruajtja e microparticioneve n\u00eb S3, nd\u00ebrsa Stateless - \u00ebsht\u00eb optimizuesi, puna me metadat, trajtimi i pyetjeve t\u00eb siguris\u00eb, t\u00eb cilat mund t\u00eb ngrihen si sh\u00ebrbime t\u00eb lehta dhe t\u00eb pavarura Stateless.<\/p>\n
Ekzekutimi i k\u00ebrkesave SQL gjithashtu mund t\u00eb perceptohet si sh\u00ebrbime me nj\u00eb gjendje t\u00eb leht\u00eb, t\u00eb cilat mund t\u00eb shfaqen n\u00eb modalitet pa server, si grupet kompjuterike t\u00eb Snowflake, duke shkarkuar vet\u00ebm t\u00eb dh\u00ebnat e nevojshme, duke ekzekutuar k\u00ebrkes\u00ebn dhe \"dukur\".<\/p>\n
Baza pa serverless e nivelit prodhues \u00ebsht\u00eb tashm\u00eb e disponueshme p\u00ebr t'u p\u00ebrdorur, ata po punojn\u00eb. K\u00ebto baza serverless jan\u00eb gati t\u00eb p\u00ebrballojn\u00eb detyrat OLAP. Fatkeq\u00ebsisht, p\u00ebr detyrat OLTP ato aplikohen\u2026 me nuanca, sepse ka kufizime. Nga nj\u00ebra an\u00eb, kjo \u00ebsht\u00eb nj\u00eb disavantazh. Por, nga ana tjet\u00ebr, kjo \u00ebsht\u00eb nj\u00eb mund\u00ebsi. Ndoshta ndonj\u00eb prej lexuesve do t\u00eb gjej\u00eb nj\u00eb m\u00ebnyr\u00eb p\u00ebr ta b\u00ebr\u00eb nj\u00eb baz\u00eb OLTP plot\u00ebsisht serverless, pa kufizime Aurora.<\/p>\n
Shpresoj q\u00eb ju ka interesuar. P\u00ebr t\u00eb ardhmen Serverless \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t