Silav hemû! Navê min Golov Nikolay e. Berê, min şeş salan li Avito xebitî û Platforma Daneyê bi rê ve bir, ango min li ser hemî databasan xebitî: analîtîk (Vertica, ClickHouse), streaming û OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Di vê demê de, min bi hejmareke mezin databasan re mijûl bû - pir cûda û neasayî, û bi dozên ne-standard ên karanîna wan.
Ez niha li ManyChat dixebitim. Di eslê xwe de, ev destpêkek e - nû, ambargo û bi lez mezin dibe. Û gava ku ez yekem car beşdarî pargîdaniyê bûm, pirsek klasîk derket holê: "Destpêkek ciwan naha divê ji bazara DBMS û databasê çi bigire?"
Di vê gotarê de, li ser bingeha rapora min li , Ez ê bersiva vê pirsê bidim. Versiyonek vîdyoyê ya raporê li vir heye .
Databasên bi gelemperî têne zanîn 2020
Sala 2020-an e, min li dora xwe nihêrî û sê celeb databasan dît.
Tîpa yekem - databases OLTP klasîk: PostgreSQL, SQL Server, Oracle, MySQL. Ew demek dirêj berê hatine nivîsandin, lê hîn jî têkildar in ji ber ku ew ji civaka pêşdebir re ew qas nas in.
Cureyê duyemîn e bingehên ji "sifir". Wan hewl da ku bi dev ji SQL, strukturên kevneşopî û ACID-ê veqetînin, bi lêzêdekirina şilavkirina çêkirî û taybetmendiyên din ên balkêş, ji qalibên klasîk dûr bikevin. Mînakî, ev Cassandra, MongoDB, Redis an Tarantool e. Hemî van çareseriyan dixwest ku bazarê tiştek bingehîn nû pêşkêşî bikin û cîhê wan dagir kir ji ber ku ew ji bo hin karan pir hêsan derketin. Ez ê van databasan bi têgîna sîwanê NOSQL destnîşan bikim.
"Sifir" qediyan, me bi databasên NOSQL-ê re fêr kir, û cîhan, ji nihêrîna min, gavê din avêt - ku databases rêvebirin. Van databasan heman bingehîn wekî databasên OLTP yên klasîk an yên nû NoSQL hene. Lê hewcedariya wan bi DBA û DevOps tune û li ser hardware-ya rêvebirinê di ewran de dimeşîne. Ji bo pêşdebirek, ev "tenê bingehek" e ku li cîhek dixebite, lê kes guh nade ka ew çawa li ser serverê tête saz kirin, kê server mîheng kiriye û kî wê nûve dike.
Nimûneyên databasên weha:
- AWS RDS ji bo PostgreSQL/MySQL pêçekek rêvekirî ye.
- DynamoDB analogek AWS ya databasek bingehîn e, mîna Redis û MongoDB.
- Amazon Redshift databasek analîtîk a rêvekirî ye.
Vana di bingeh de databasên kevn in, lê di hawîrdorek birêvebirî de hatine raber kirin, bêyî ku hewce bike ku bi hardware re bixebitin.
Not. Nimûne ji bo hawîrdora AWS têne girtin, lê analogên wan di Microsoft Azure, Google Cloud, an Yandex.Cloud de jî hene.
Li ser vê yekê çi nû ye? Di sala 2020 de, yek ji van.
Konsepta bê server
Ya ku di sala 2020-an de li sûkê bi rastî nû ye çareseriyên bê server an bê server e.
Ez ê hewl bidim ku rave bikim ka ev tê çi wateyê ku mînaka karûbarek birêkûpêk an serîlêdana paşîn bikar tîne.
Ji bo ku em serîlêdanek paşerojê ya birêkûpêk bicîh bikin, em serverek dikirin an kirê dikin, kodê li ser wê kopî dikin, xala dawiyê li derve diweşînin û bi rêkûpêk ji bo kirê, elektrîk û karûbarên navenda daneyê didin. Ev plana standard e.
Ma rêyek din heye? Bi karûbarên bê server hûn dikarin.
Mebesta vê nêzîkatiyê çi ye: serverek tune, di ewr de ne jî kirêkirina mînakek virtual heye. Ji bo bicîhkirina karûbarê, kodê (fonksiyonên) li depoyê kopî bikin û wê li dawiya dawî biweşînin. Dûv re em tenê ji bo her bangek vê fonksiyonê didin, bi tevahî guh nadin hardware ku ew lê tê darve kirin.
Ez ê hewl bidim ku vê nêzîkatiyê bi wêneyan diyar bikim.
Dabeşkirina klasîk. Xizmetek me bi barek diyar heye. Em du mînakan bilind dikin: pêşkêşkerên laşî an mînakên di AWS de. Daxwazên derve ji van bûyeran re têne şandin û li wir têne kirin.
Wekî ku hûn di wêneyê de dibînin, server bi heman rengî nayên avêtin. Yek 100% tê bikar anîn, du daxwaz hene, û yek tenê 50% e - qismî bêkar. Ger ne sê daxwaz werin, lê 30, wê hingê dê tevahiya pergalê nikaribe bi barkirinê re rû bi rû bimîne û dê dest bi hêdîbûnê bike.
Bicihkirina bê server. Di hawîrdorek bê server de, karûbarek weha nimûne an serverek tune. Hin hewzek çavkaniyên germkirî hene - konteynerên piçûk ên Docker ên amadekirî yên bi koda fonksiyonê veqetandî hene. Pergal daxwazên derveyî werdigire û ji bo her yek ji wan çarçoweya bê server konteynirek piçûk a bi kodê radike: ew vê daxwaziya taybetî dişoxilîne û konteynerê dikuje.
Yek daxwaz - yek konteynir rakir, 1000 daxwaz - 1000 konteynir. Û bicihkirina li ser serverên hardware jixwe karê peydakerê ewr e. Ew ji hêla çarçoveya bê server ve bi tevahî veşartî ye. Di vê konseptê de em ji bo her bangekê didin. Mesela, rojekê telefonek dihat - me ji bo telefonekê pere da, her deqeyekê mîlyonek hat - me ji bo mîlyonekê pere da. An jî di saniyeyekê de, ev jî dibe.
Têgîna weşandina fonksiyonek bê server ji bo karûbarek bêdewlet maqûl e. Û heke hûn hewceyê karûbarek (dewletê) dewletparêz in, wê hingê em databasek li karûbarê zêde dikin. Di vê rewşê de, dema ku ew bi dewletê re dixebite, her fonksiyonek statefull tenê ji databasê dinivîse û dixwîne. Wekî din, ji databasa her sê celebên ku di destpêka gotarê de hatine destnîşan kirin.
Sînordariya hevpar a van hemî databasan çi ye? Vana lêçûnên serverek ewr an hardware (an çend serverek) bi domdarî têne bikar anîn. Ne girîng e ku em danegehek klasîk an birêvebir bikar bînin, Devops û rêveberek me hebin an na, em dîsa jî 24/7 10/20 heqê hardware, elektrîkê û kirêkirina navenda daneyê didin. Ger bingehek me ya klasîk hebe, em ji bo xulam û koleyan didin. Ger ew databasek şikestî ya pir barkirî be, em ji bo 30, XNUMX an XNUMX pêşkêşkeran didin, û em bi domdarî didin.
Hebûna serverên parastî yên domdar di avahiya lêçûnê de berê wekî xirabiyek pêdivî dihat hesibandin. Databasên kevneşopî di heman demê de dijwariyên din jî hene, wek sînorên li ser hejmara pêwendiyan, sînorkirinên pîvandinê, lihevhatina jeo-belavbûyî - ew dikarin bi rengekî di hin databasan de werin çareser kirin, lê ne bi yekcarî û ne îdeal.
Database bê server - teorî
Pirsa 2020: Ma gengaz e ku meriv databasek jî bê server çêbike? Herkesî li ser pişta bê server bihîstiye... em hewl bidin ku databasê bê server bikin?
Ev xerîb xuya dike, ji ber ku databas karûbarek dewletparêz e, ji bo binesaziya bê server ne pir maqûl e. Di heman demê de, rewşa databasê pir mezin e: gigabytes, terabytes, û di databasên analîtîk de jî petabytes. Bilindkirina wê di konteynerên sivik ên Docker de ne ew qas hêsan e.
Ji hêla din ve, hema hema hemî databasên nûjen hejmareke mezin ji mantiq û hêmanan vedihewîne: danûstendin, hevrêziya yekrêziyê, prosedur, girêdanên pêwendiyê û gelek mantiq. Ji bo pir mantiqa databasê, dewletek piçûk bes e. Gigabytes û Terabytes rasterast ji hêla tenê beşek piçûk a mantiqa databasê ve ku rasterast di pêkanîna pirsan de têkildar e têne bikar anîn.
Li gorî vê yekê, fikir ev e: heke beşek ji mantiqê destûrê dide darvekirina bêdewlet, çima bingehê li beşên Dewlet û Bêdewlet nayê dabeş kirin.
Ji bo çareseriyên OLAP bê server
Ka em bibînin ka qutkirina databasek li beşên Dewlemend û Bêdewlet bi karanîna nimûneyên pratîkî çawa xuya dike.
Mînakî, me databasek analîtîk heye: Daneyên derveyî (silindera sor li milê çepê), pêvajoyek ETL ya ku daneyan li databasê bar dike, û analîstek ku pirsên SQL ji databasê re dişîne. Ev plansaziyek xebata wargeha daneya klasîk e.
Di vê planê de, ETL bi şertê carekê tête kirin. Dûv re hûn hewce ne ku bi berdewamî ji bo serverên ku databasa li ser wan bi daneyên ku bi ETL-ê dagirtî dimeşe bidin, da ku tiştek hebe ku hûn lêpirsînan bişînin.
Ka em li nêzîkatiyek alternatîf a ku di AWS Athena Serverless de hatî bicîh kirin binêrin. Zehfek daîmî ya ku daneyên dakêşandî li ser têne hilanîn tune. Li şûna vê:
- Bikarhêner pirsek SQL ji Athena re dişîne. Optimîzatorê Athena pirsa SQL analîz dike û li dikana metadata (Metadata) li daneyên taybetî yên ku ji bo bicîhanîna pirsê hewce ne digere.
- Optimîzator, li ser bingeha daneyên berhevkirî, daneyên pêwîst ji çavkaniyên derveyî dakêşîne nav hilanîna demkî (danûstandinên demkî).
- Lêpirsînek SQL ji bikarhêner di hilanîna demkî de tê darve kirin û encam ji bikarhêner re tê vegerandin.
- Depoya demkî tê paqij kirin û çavkanî têne berdan.
Di vê mîmariyê de, em tenê ji bo pêvajoya pêkanîna daxwazê didin. No daxwaz - bê mesref.
Ev nêzîkatiyek xebatê ye û ne tenê di Athena Serverless de, lê di heman demê de di Redshift Spectrum (di AWS) de jî tête bicîh kirin.
Mînaka Athena nîşan dide ku databasa Serverless bi deh û sedan Terabytes daneyan li ser pirsên rastîn dixebite. Bi sedan Terabyte dê bi sedan serveran hewce bike, lê em neçar in ku ji bo wan bidin - em ji bo daxwazan didin. Leza her daxwazê li gorî databasên analîtîk ên pispor ên mîna Vertica (pir) kêm e, lê em ji bo demên domandinê nadin.
Databasek wusa ji bo pirsên ad-hoc yên analîtîk ên kêm pêk tê. Mînakî, dema ku em bixweber biryar didin ku hîpotezek li ser hin daneya mezin biceribînin. Athena ji bo van rewşan bêkêmasî ye. Ji bo daxwazên birêkûpêk, pergalek wusa biha ye. Di vê rewşê de, daneyan di hin çareseriyên pispor de cache bikin.
Ji bo çareseriyên OLTP bê server
Mînaka berê li karên OLAP (analîtîk) mêze kir. Naha em li peywirên OLTP binêrin.
Werin em PostgreSQL an MySQL-ya berbelavkirî xeyal bikin. Ka em bi çavkaniyên hindiktirîn mînakek birêkûpêk PostgreSQL an MySQL rakin. Gava ku mînakek bêtir bargiraniyê werdigire, em ê kopiyên din ên ku em ê beşek ji barkirina xwendinê bi wan re belav bikin ve girêbidin. Ger daxwazek an barkirin tune be, em kopiyan vedigirin. Mînaka yekem master e, û yên mayî replica ne.
Ev raman di databasek bi navê Aurora Serverless AWS de tête bicîh kirin. Prensîb hêsan e: daxwazên ji serîlêdanên derveyî ji hêla fîloya proxy ve têne pejirandin. Bi dîtina zêdebûna barkirinê, ew çavkaniyên hesabkirinê ji mînakên hindiktirîn ên berê-germkirî veqetîne - pêwendî bi lez û bez pêk tê. Mînakên neçalakkirinê bi heman awayî pêk tê.
Di nav Aurora de têgeha Yekîneya Kapasîteya Aurora, ACU heye. Ev (bi şert) mînakek (server) e. Her ACU-ya taybetî dikare bibe master an xulam. Her Yekîneyek Kapasîteyê RAM, pêvajoyek û dîska hindiktirîn heye. Li gorî vê yekê, yek master e, yên mayî tenê replica têne xwendin.
Hejmara van Yekîneyên Kapasîteya Aurora ku dixebitin parametreyek mîhengbar e. Hejmara hindiktirîn dikare yek an sifir be (di vê rewşê de, heke daxwazek tune be, databas kar nake).
Dema ku bingeh daxwazan distîne, fîloya proxy Yekeyên Kapasîteya Aurora bilind dike, çavkaniyên performansa pergalê zêde dike. Hêza zêdekirin û kêmkirina çavkaniyan destûrê dide pergalê ku çavkaniyan "jihevdeng" bike: bixweber ACU-yên ferdî nîşan bide (li şûna wan bi yên nû veguhezîne) û hemî nûvekirinên heyî li ser çavkaniyên vekişandî derxîne.
Bingeha Aurora Serverless dikare barkirina xwendinê mezin bike. Lê belge rasterast vê yekê nabêjin. Dibe ku hîs bikin ku ew dikarin pir-masterek rakin. Sêrbaz tune.
Ev databas baş e ku ji xerckirina mîqdarên mezin drav li ser pergalên bi gihîştina nediyar dûr bixe. Mînakî, dema afirandina MVP an malperên qerta karsaziyê kirrûbirra, em bi gelemperî li bendê ne ku barek domdar be. Li gorî vê, ger ku destnedan nebe, em ji bo mînakan pere nadin. Dema ku barkirina neçaverêkirî çêbibe, mînakî piştî konferansek an kampanyayek reklamê, girseyên mirovan serdana malperê dikin û bar bi rengek berbiçav zêde dibe, Aurora Serverless bixweber vê barkirinê digire û zû çavkaniyên winda (ACU) girêdide. Dûv re konfêrans derbas dibe, her kes prototîpê ji bîr dike, server (ACU) tarî dibin, û lêçûn digihîje sifir - rehet.
Ev çareserî ji bo barkirina bi îstîqrar ne maqûl e ji ber ku ew barê nivîsandinê mezin nake. Hemî van girêdan û veqetandina çavkaniyan di nav "xala pîvanê" de pêk tê - xalek di demê de ku databas ji hêla danûstendinek an tabloyên demkî ve nayê piştgirî kirin. Mînakî, di nav hefteyekê de dibe ku xala pîvanê çênebe, û bingeh li ser heman çavkaniyan dixebite û bi hêsanî nikare berfireh bike an peyman bike.
Sêrbaz tune - ew PostgreSQL-ya birêkûpêk e. Lê pêvajoya zêdekirina makîneyan û qutkirina wan bi qismî otomatîk e.
Ji hêla sêwiranê ve bê server
Aurora Serverless databasek kevn e ku ji bo ewr ji nû ve hatî nivîsandin da ku ji hin feydeyên Serverless sûd werbigire. Û naha ez ê ji we re qala bingehê bikim, ku bi eslê xwe ji bo ewr, ji bo nêzîkatiya bê server hate nivîsandin - Serverless-by-design. Ew tavilê bêyî texmîna ku ew ê li ser serverên laşî bixebite hate pêşve xistin.
Ji vê bingehê re Snowflake tê gotin. Ew sê blokên sereke hene.
Ya yekem bloka metadata ye. Ev karûbarek bilez a bîranînê ye ku pirsgirêkên ewlehî, metadata, danûstendin û xweşbîniya pirsê çareser dike (di nîgara li milê çepê de tê xuyang kirin).
Bloka duyemîn ji bo hesaban komek komikên berhevoka virtual e (di nîgarê de komek derdorên şîn hene).
Bloka sêyemîn pergalek hilanîna daneyê ye ku li ser bingeha S3 ye. S3 di AWS-ê de hilanîna tiştên bêpîvan e, ji bo karsaziyê mîna Dropbox-a bêpîvan e.
Ka em bibînin ka Snowflake çawa dixebite, bi texmîna destpêkek sar. Ango danegehek heye, dane tê barkirin, lêpirsînên ku dimeşin tune. Li gorî vê yekê, heke daxwazek ji databasê re tune be, wê hingê me karûbarê Metadata-ya zû ya bîranînê (bloka yekem) bilind kiriye. Û me hilanîna S3 heye, ku li wir daneyên tabloyê têne hilanîn, bi navê mîkropartîsyonê têne dabeş kirin. Ji bo hêsaniyê: heke tablo danûstendinan hebe, wê hingê mîkropartîsyonê rojên danûstendinê ne. Her roj mîkrobeşek cuda ye, pelek cuda ye. Û gava ku databas di vê modê de dixebite, hûn tenê ji bo cîhê ku ji hêla daneyê ve hatî dagir kirin didin. Digel vê yekê, rêjeya her kursiyek pir kêm e (bi taybetî ku lihevhatina girîng tê hesibandin). Karûbarê metadata jî bi domdarî dixebite, lê ji bo xweşbînkirina pirsan hûn ne hewceyê gelek çavkaniyan in, û karûbar dikare wekî parveker were hesibandin.
Naha em bifikirin ku bikarhênerek hate databasa me û pirsek SQL şand. Pirsa SQL tavilê ji bo pêvajoyê ji karûbarê Metadata re tê şandin. Li gorî vê yekê, piştî wergirtina daxwazek, ev karûbar daxwazê, daneyên berdest, destûrên bikarhêner analîz dike û, heke her tişt baş be, ji bo pêkanîna daxwazê planek çêdike.
Dûv re, karûbar destpêkirina koma komputerê dest pê dike. Komek komputerê komek pêşkêşkeran e ku hesaban pêk tîne. Ango, ev komik e ku dikare 1 server, 2 pêşkêşker, 4, 8, 16, 32 - bi qasî ku hûn dixwazin hene. Hûn daxwazek davêjin û destpêkirina vê komê tavilê dest pê dike. Ew bi rastî çirkeyan digire.
Dûv re, piştî ku komê dest pê kir, mîkropartîsyonên ku ji bo pêkanîna daxwaza we hewce ne dest pê dikin ku di nav komê de ji S3 werin kopî kirin. Ango, em bifikirin ku ji bo pêkanîna pirsek SQL ji yek tabloyê û yek ji ya duyemîn du beş hewce dike. Di vê rewşê de, tenê sê dabeşên pêwîst dê li komê bêne kopî kirin, û ne hemî tabloyên bi tevahî. Ji ber vê yekê, û tam ji ber ku her tişt di nav yek navendek daneyê de ye û bi kanalên pir bilez ve girêdayî ye, tevahiya pêvajoya veguheztinê pir zû diqewime: di çirkeyan de, pir kêm di hûrdeman de, heya ku em behsa hin daxwazên cinawir nekin. Li gorî vê yekê, mîkropartîsyonên li koma hesabkerê têne kopî kirin, û, piştî qedandinê, lêpirsîna SQL li ser vê komê hesabkirinê tê darve kirin. Encama vê daxwazê dikare yek rêz, çend rêz an tabloyek be - ew ji derve re ji bikarhêner re têne şandin da ku ew bikaribe wê dakêşîne, di amûra xweya BI de nîşan bide, an jî bi rengek din bikar bîne.
Her pirsek SQL ne tenê dikare berhevokên ji daneyên berê yên barkirî bixwîne, lê di heman demê de daneyên nû di databasê de jî bar dike/hilberîne. Ango, ew dikare bibe pirsek ku, mînakî, tomarên nû têxe nav tabloyek din, ku dibe sedema xuyangkirina dabeşek nû li ser komika hesabkirinê, ku, di encamê de, bixweber di hilanînek yek S3 de tê hilanîn.
Senaryoya ku li jor hatî behs kirin, ji hatina bikarhêner heya bilindkirina komê, barkirina daneyan, bicihanîna pirsan, bidestxistina encaman, bi rêjeya hûrguliyên karanîna komê berhevkirina virtual ya bilindkirî, depoya virtual tê dayîn. Rêje li gorî qada AWS û mezinahiya komê diguhere, lê bi navînî ew di saetekê de çend dolar e. Komek ji çar makîneyan du caran bihatir e ji koma du makîneyan, û komek ji heşt makîneyan hêj du caran biha ye. Vebijarkên 16, 32 makîneyan hene, li gorî tevliheviya daxwazan. Lê hûn tenê ji bo wan deqeyan didin dema ku kom bi rastî dimeşe, ji ber ku dema ku daxwaz tunebin, hûn bi rengekî destên xwe jê digirin, û piştî 5-10 hûrdeman li bendê (parametreyek mîhengbar) ew ê bixwe biçe, çavkaniyên azad bikin û azad bibin.
Senaryoyek bi tevahî realîst ev e ku gava hûn daxwazek dişînin, komik derdikeve holê, nisbeten biaxive, di deqeyek de, ew deqeyek din dihejmêre, paşê pênc hûrdeman tê girtin, û hûn di dawiyê de ji bo heft hûrdeman xebata vê komê drav didin, û ne bi meh û salan.
Senaryoya yekem bi karanîna Snowflake di mîhengek yek-bikarhêner de hate vegotin. Naha em bifikirin ku gelek bikarhêner hene, ku ji senaryoya rastîn nêzîktir e.
Ka em bibêjin gelek analîst û raporên me yên Tabloyê hene ku bi domdarî databasa me bi hejmareke mezin ji pirsên SQL-ya analîtîk ên hêsan bombebaran dikin.
Wekî din, em bibêjin ku Zanyarên Daneyên dahêner ên me hene ku hewl didin bi daneyan tiştên cinawir bikin, bi dehan Terabytes kar bikin, bi mîlyaran û trîlyon rêzên daneyan analîz bikin.
Ji bo du celeb bargiraniyên ku li jor hatine destnîşan kirin, Snowflake destûrê dide we ku hûn çend komikên hesabker ên serbixwe yên kapasîteyên cihêreng bilind bikin. Digel vê yekê, ev komikên hesabkirinê serbixwe dixebitin, lê bi daneyên domdar ên hevpar.
Ji bo hejmareke mezin ji pirsên sivik, hûn dikarin 2-3 komên piçûk, bi qasî 2 makîneyên her yekê rakin. Ev tevger dikare, di nav tiştên din de, bi karanîna mîhengên otomatîkî were bicîh kirin. Ji ber vê yekê hûn dibêjin, "Snowflake, komek piçûk rakin. Ger barkirina li ser wê li ser pîvanek diyarkirî zêde bibe, duyemîn, sêyemînek wekhev bilind bikin. Dema ku bar dest bi kêmbûnê kir, zêdeyê vemirînin.” Ji ber vê yekê çiqas analîst werin û dest bi nihêrîna raporan bikin, her kes têra xwe çavkaniyên xwe hene.
Di heman demê de, heke analîst di xew de bin û kes li raporan nenihêre, dibe ku kom bi tevahî tarî bibin, û hûn dev ji dayîna wan berdin.
Di heman demê de, ji bo pirsên giran (ji Zanyarên Daneyê), hûn dikarin ji bo 32 makîneyan komek pir mezin rakin. Di heman demê de ev kom dê tenê ji bo wan hûrdem û demjimêran were dayîn dema ku daxwaza weya giyanî li wir dimeşîne.
Derfeta ku li jor hatî destnîşan kirin dihêle hûn ne tenê 2, lê di heman demê de bêtir celeb bargiraniyê jî li koman dabeş bikin (ETL, çavdêrîkirin, materyalkirina raporê, ...).
Ka em Snowflake kurt bikin. Bingeh ramanek xweşik û pêkanînek bikêr li hev dike. Li ManyChat, em Snowflake bikar tînin da ku hemî daneyên ku me hene analîz bikin. Sê komikên me tune ne, wekî di nimûneyê de, lê ji 5 heta 9, bi mezinahiyên cihêreng. Me ji bo hin karan 16-makîne, 2-makîne, û her weha 1-makîneyên super-biçûk ên kevneşopî hene. Ew bi serfirazî barkirinê belav dikin û dihêlin ku em gelek xilas bikin.
Database bi serfirazî barkirina xwendin û nivîsandinê dipîve. Ev cûdahiyek mezin û serkeftinek mezin e li gorî heman "Aurora", ku tenê barê xwendinê hilgirt. Snowflake destûrê dide te ku hûn bi van komikên komputerê re barê xweya nivîsandinê mezin bikin. Ango, wekî ku min behs kir, em di ManyChat de çend koman bikar tînin, komên piçûk û super-biçûk bi giranî ji bo ETL, ji bo barkirina daneyan têne bikar anîn. An analîst jixwe li ser komikên navîn dijîn, ku bê guman ji barkirina ETL bandor nabin, ji ber vê yekê ew pir zû dixebitin.
Li gorî vê yekê, databas ji bo karên OLAP-ê baş e. Lêbelê, mixabin, ew hîn ji bo barkêşên OLTP-ê ne sepandin e. Ya yekem, ev databas stûnek e, digel hemî encamên paşerojê. Ya duyemîn, nêzîkatî bixwe, gava ku ji bo her daxwazê, ger hewce be, hûn komek berhevokê radikin û wê bi daneyan diherikînin, mixabin, ji bo barkirinên OLTP-ê hîn bi lez ne bes e. Li benda saniyeyan ji bo karên OLAP normal e, lê ji bo karên OLTP nayê qebûl kirin; 100 ms dê çêtir be, an jî 10 ms dê hê çêtir be.
Encam
Databasek bê server bi dabeşkirina databasê li beşên Bêdewlet û Dewlet gengaz dibe. Dibe ku we bala xwe dayê ku di hemî mînakên jorîn de, beşa Stateful, bi nisbetî dipeyivî, mîkro-parçeyan di S3 de hilîne, û Stateless optimîzator e, bi metadata re dixebite, pirsgirêkên ewlehiyê yên ku dikarin wekî karûbarên bêdewlet ên sivik ên serbixwe bêne raber kirin, hildigire.
Pêkanîna pirsên SQL dikare wekî karûbarên rewşa sivik jî were fêm kirin ku dikarin di moda bê server de derkevin, mîna komikên hesabkirinê yên Snowflake, tenê daneyên pêwîst dakêşin, lêpirsînê bicîh bikin û "derkevin".
Databasên asta hilberîna bê server jixwe ji bo karanîna hene, ew dixebitin. Van databasên bê server jixwe amade ne ku karên OLAP-ê bikin. Mixabin, ji bo karên OLTP-ê ew têne bikar anîn ... bi nuwazeyan, ji ber ku sînor hene. Ji aliyekî ve, ev kêmasiyek e. Lê ji aliyê din ve ev derfetek e. Dibe ku yek ji xwendevanan rêyek bibîne ku databasek OLTP bi tevahî bê server, bêyî tixûbên Aurora bike.
Ez hêvî dikim ku we ew balkêş dît. Bê server pêşeroj e :)
Source: www.habr.com