Rojek di pêşerojek dûr de, rakirina otomatîkî ya daneyên nepêwist dê bibe yek ji karên girîng ên DBMS [1]. Di vê navberê de, em bi xwe hewce ne ku ji jêbirin an veguheztina daneyên nepêwist berbi pergalên hilanînê yên kêmtir biha ve mijûl bibin. Ka em bibêjin hûn biryar didin ku çend mîlyon rêzan jêbikin. Karûbarek pir hêsan e, nemaze heke rewş were zanîn û navnîşek guncan hebe. "JI JI tabloya 1 JI BIBIN KU col1 = :nirx" - çi dibe ku hêsantir be, rast?
Video:
-
Ez ji sala yekem, ango ji sala 2007-an ve di komîteya bernameya Highload de me.
-
Û ez ji 2005-an vir ve bi Postgres re me. Di gelek projeyan de bi kar anîn.
-
Kom jî ji sala 2007’an ve bi RuPostges re ye.
-
Em li ser Meetup gihîştin 2100+ beşdaran. Ev cîhê duyemîn e li cîhanê piştî New Yorkê, ku demek berê berê xwe da San Francisco.
-
Ev çend sal in ez li California dijîm. Ez bi piranî bi pargîdaniyên Amerîkî re, tevî yên mezin, dixebitim. Ew bikarhênerên Postgres çalak in. Û her cûre tiştên balkêş li wir derdikevin.
- ev şirketa min e. Em di karsaziya otomatîkkirina peywiran de ne ku hêdîbûna pêşkeftinê ji holê radikin.
Ger hûn tiştek bikin, carinan li dora Postgres hin xeletî hene. Ka em bibêjin ku hûn hewce ne ku li bendê bin heya ku rêvebir ji we re bendek ceribandinê bistîne, an jî hûn hewce ne ku li bendê bin heya ku DBA bersivê bide we. Û em di pêvajoya pêşveçûn, ceribandin û rêvebirinê de tengahiyên weha dibînin û bi karanîna otomasyon û nêzîkatiyên nû hewl didin ku wan ji holê rakin.
Ez vê dawiyê li VLDB li Los Angeles bûm. Ev mezintirîn konferansa databasê ye. Û raporek hebû ku di pêşerojê de DBMS dê ne tenê hilanînê, lê di heman demê de bixweber jî daneyan jêbirin. Ev mijareke nû ye.
Li cîhanê dane zêde û zêde dibin Zetabyte 1 petabyte ye. Û naha jixwe tê texmîn kirin ku li cîhanê zêdetirî 000 zetabytes daneyên me hene. Û ji wan bêtir û bêtir hene.
Û bi wê re çi bikin? Diyar e ku divê were jêbirin. Li vir lînka vê raporta balkêş heye. Lê heta niha ev yek di DBMS’ê de pêk nehatiye.
Yên ku dizanin pereyan bijmêrin du tiştan dixwazin. Ew dixwazin ku em jêbirin, ji ber vê yekê teknîkî divê em karibin wiya bikin.
Ya ku ez ê paşê bêjim rewşek razber e ku komek rewşên rastîn vedihewîne, ango berhevokek diyar a tiştê ku bi rastî bi min û databasên derdorê re gelek caran, gelek salan qewimî. Rake li her derê ne û her kes her gav pê li wan dike.
Em bibêjin bingehek me an çend bingeh hene ku mezin dibin. Û hin tomar zibilên eşkere ne. Mînakî, bikarhêner li wir dest bi kirina tiştek kir, lê neqediya. Û piştî demekê em dizanin ku ev karê neqediyayî êdî nikare were hilanîn. Ango, em dixwazin hin tiştên nebaş paqij bikin da ku cîh xilas bikin, performansê baştir bikin, hwd.
Bi gelemperî, peywir ew e ku meriv jêbirina tiştên taybetî, rêzikên taybetî yên di tabloyekê de otomatîk bike.
Û daxwazek me heye ku em ê îro li ser biaxivin, ango li ser rakirina çopê.
Me ji pêşdebirek pispor xwest ku vê yekê bike. Wî ev daxwaz girt, xwe kontrol kir - her tişt dixebite. Min ew li ser sehneyê ceriband - her tişt baş e. Ew derxistin - her tişt dixebite. Rojê carekê em vê dimeşînin - her tişt baş e.
Database her ku diçe mezin dibe. DELETE ya rojane hinekî hêdîtir dest bi xebatê dike.
Dûv re em fêhm dikin ku em naha pargîdaniyek kirrûbirrê ne û seyrûsefer dê çend carî mezintir be, ji ber vê yekê em biryar didin ku bi demkî tiştên nehewce bidin sekinandin. Û em ji bîr dikin ku wê vegerînin.
Piştî çend mehan hat bîra wan. Û ew pêşdebir dev jê berda an bi tiştekî din re mijûl bû, wan yekî din tayîn kir ku wê vegerîne.
Wî li dev, li ser sehneyê kontrol kir - her tişt baş e. Bi xwezayî, hûn hîn jî hewce ne ku tiştê ku berhev kiriye paqij bikin. Wî kontrol kir, her tişt dixebite.
Paşê çi dibe? Wê demê her tişt ji bo me têk diçe. Ew qas dadikeve ku di demekê de her tişt têk diçe. Her kes di şokê de ye, kes fêm nake ka çi diqewime. Û paşê derket holê ku ev DELETE pirsgirêk bû.
Tiştek xelet çû? Li vir navnîşek tiştên ku dikarin xelet biçin heye. Kîjan ji van herî girîng e?
-
Mînakî, nirxandinek tune bû, ango pisporê DBA-ê nedît. Bi çavek bi tecrûbe, ew ê tavilê pirsgirêkê bibîne, û ji bilî vê, wî bigihîje prod, ku çend mîlyon xet lê kom bûne.
-
Dibe ku wan tiştek xelet kontrol kirin.
-
Dibe ku hardware kevnar be û hûn hewce ne ku vê databasê nûve bikin.
-
An jî tiştek bi databasê bixwe re xelet e, û pêdivî ye ku em ji Postgres biçin MySQL.
-
An jî dibe ku di operasyonê de tiştek xelet heye.
-
Dibe ku di organîzekirina kar de hin xeletî hebin û hewce bike ku kesek ji kar derxînin û kesên çêtir bixebitin?
Kontrola DBA tune bû. Ger DBA hebûya, ew ê van çend mîlyon rêzan bidîta û bêyî ceribandinan jî bigota: "Ew wiya nakin." Em bibêjin ger ev kod di GitLab, GitHub de bûya û pêvajoyek vekolîna kodê hebûya û tiştek wusa tunebû ku bêyî pejirandina DBA ev operasyon li ser prod pêk were, wê demê eşkere DBA dê bigota: "Hûn nikarin wiya bikin. ”
Û ew ê bêje ku hûn ê bi dîska IO-yê re pirsgirêkên we hebin û hemî pêvajo dê dîn bibin, dibe ku kilît hebin, û hûn ê otovacuumê jî ji bo komek hûrdem asteng bikin, ji ber vê yekê ev ne baş e.
Xeletiya duyemîn ev e ku wan li cîhek xelet kontrol kirin. Me piştî wê yekê dît ku gelek daneyên çopê li ser prod kom bûne, lê pêşdebir di vê databasê de dane berhev nekiriye, û kes bi rastî ev zibil li ser sehneyê neafirandiye. Li gorî vê, 1 xet hebûn, ku zû bi dawî bûn.
Em fêm dikin ku ceribandinên me qels in, ango pêvajoya ku tê avakirin pirsgirêkan nagire. Ezmûnek DB ya têr nehat kirin.
Pêdivî ye ku ezmûnek îdeal bi tercîh li ser heman amûreyê were kirin. Her gav ne gengaz e ku meriv vê yekê li ser heman hardware bike, lê pir girîng e ku ew kopiyek tevahî mezinahiya databasê be. Ev çend sal in ku ez mizgîniyê didim vê yekê. Û salek berê min li ser vê yekê axivî, hûn dikarin hemî li ser YouTube-ê temaşe bikin.
Dibe ku alavên me xerab in? Ger hûn lê binêrin, dereng ketiye. Me dît ku vezîvirandin %100 bû. Bê guman, heke ev ajokarên NVMe-ya nûjen bûna, wê hingê ew ê ji me re pir hêsantir be. Û dibe ku em ê ji ber vê yekê derewan nekin.
Ger ewrên we hene, wê hingê nûvekirin hêsan e. Me kopiyên nû li ser hardware nû dan destpêkirin. Switchover. Û her tişt baş e. Pretty hêsan.
Ma gengaz e ku meriv bi rengek dîskên piçûktir bi dest bixe? Û li vir, bi alîkariya DBA-ê, em di mijarek diyarkirî ya ku jê re binavkirina nuqteya kontrolê tê gotin vediqetin. Derket holê ku me tunkirina nuqteya kontrolê pêk neaniye.
xala kontrolê çi ye? Ev di her DBMS de heye. Dema ku daneyên di bîra we de diguhezin, ew tavilê li ser dîskê nayê nivîsandin. Agahdariya ku dane guherî ye pêşî li têketina pêş, di têketina pêş-nivîsandinê de tê nivîsandin. Û di demekê de, DBMS biryar dide ku ew dem e ku rûpelên rastîn bavêjin ser dîskê, da ku heke têkçûnek me hebe, em dikarin kêmtir REDO bikin. Mîna pêlîstokekê ye. Ger em bên kuştin, em ê ji nuqteya kontrolê ya dawî dest bi lîstikê bikin. Û hemî DBMS vê yekê bicîh dikin.
Mîhengên li Postgres dereng in. Ew ji bo 10-15 sal cildên dane û operasyonan hatine çêkirin. Û xala kontrolê ne îstîsna ye.
Ev agahdarî ji rapora me ya bi kontrolkirina Postgres, ango kontrolkirina tenduristiyê ya otomatîkî ye. Û li vir hinek databasa çend terabytes heye. Û eşkere ye ku nuqteyên kontrolê hema hema di 90% bûyeran de têne zor kirin.
Poldayî? Li wir du mîheng hene. Xala kontrolê dikare di wextê de çêbibe, mînakî, di 10 hûrdeman de. An jî dibe ku dema ku gelek dane hatine dagirtin çêbibe.
Û ji hêla xwerû ve, max_wal_saze li 1 gigabyte tête danîn. Bi rastî, ev bi rastî di Postgres de piştî 300-400 megabytes diqewime. We ew qas dane guhertin û nuqteyeke we ya kontrolê heye.
Û ger kes wê nekiriye, lê karûbar mezin bûye, û pargîdanî gelek drav qezenc dike, gelek danûstendinên wê hene, wê hingê xala kontrolê di deqeyekê de carekê, carinan her 30 saniyeyan carekê pêk tê, û carinan jî ew li hev dikevin. . Ev bi rastî xirab e.
Û divê em pê ewle bin ku ew kêm caran tê. Ango em dikarin max_wal_size bilind bikin. Û ew ê kêm caran êrîş bike.
Lê me metodolojîyek tevahî pêşxistiye ka meriv çawa vê yekê rasttir dike, ango meriv çawa di derheqê bijartina mîhengan de, bi eşkere li ser bingeha daneyên taybetî, biryar dide.
Li gorî vê yekê, em du rêzikên ceribandinên databasê pêk tînin.
Rêzeya yekem - em max_wal_size diguherînin. Û em operasyoneke mezin li dar dixin. Pêşî em wê li mîhenga xwerû ya 1 gigabyte dikin. Û em DELETEyek girseyî ya bi mîlyonan rêzan dikin.
Hûn dikarin bibînin ku ji bo me çiqas zehmet e. Em dibînin ku dîska IO pir xirab e. Ka em bibînin ka me çiqas WAL hilberand, ji ber ku ev pir girîng e. Ka em bibînin ka çend caran xala kontrolê çêbû. Û em dibînin ku ew ne baş e.
Piştre em max_wal_size zêde dikin. Em dubare dikin. Zêde bikin, dubare bikin. Û gelek caran. Di prensîbê de, 10 xal baş e, ku 1, 2, 4, 8 gigabytes. Û em li tevgera pergalek taybetî dinêrin. Eşkere ye ku amûrên li vir divê wekî prod be. Divê hûn heman dîskê, heman mîqdara bîranînê, û heman mîhengên Postgres hebin.
Û bi vî awayî em ê pergala xwe biguhezînin, û em dizanin ku DBMS dê di bûyera komkujiyek xirab DELETE de çawa tevbigere, ew ê çawa nuqteya kontrolê bike.
Xala kontrolê bi rûsî tê wateya xalên kontrolê.
Nimûne: Çend mîlyon rêzan ji hêla indexê ve JÊBIKIN, rêz li ser rûpelan "belavbûyî" dibin.
Li vir mînakek heye. Ev hinek bingeh e. Û digel mîhenga xwerû ya 1 gigabyte ji bo max_wal_size, pir zelal e ku dîskên me yên tomarkirinê diçin berxê. Ev wêne nîşanek tîpîk a nexweşek pir nexweş e, ango, wî bi rastî xwe xirab hîs kir. Û tenê operasyonek hebû, li vir tenê DELETE ya çend mîlyon rêzan bû.
Ger destûr bê dayîn operasyonek weha, wê hingê em ê tenê bikevin xwarê, ji ber ku diyar e ku yek DELETE me di refê de dikuje.
Wekî din, li ku derê 16 gigabayt hene, hûn dikarin bibînin ku diranan berê dest pê kirine. Jixwe diran çêtir in, yanî em li banî dixin, lê ne ewqas xirab. Li wir piçek azadî xuya bû. Li aliyê rastê tomar heye. Û hejmara operasyonan grafiya duyemîn e. Û diyar e ku em jixwe bi 16 gigabaytan hinekî hêsantir nefesê digirin.
Û cihê ku 64 gigabayt xuya dibin, ew bi tevahî çêtir bûye. Jixwe diran bi zelalî têne xuyang kirin, bêtir derfet hene ku ji operasyonên din xilas bibin û bi dîskê re tiştek bikin.
Çima wusa?
Ez ê piçek hûrguliyan bişopînim, lê ev mijara ku meriv çawa birêkûpêkkirina nuqteya kontrolê dikare bi tevahî raporek encam bide, ji ber vê yekê ez ê pir hûrgulî nekim, lê ez ê piçek diyar bikim ka çi zehmetî hene.
Ger nuqteya kontrolê pir caran çêbibe, û em rêzikên xwe bi rêzê nûve nekin, lê wan bi navnîşan bibînin, ku ev baş e, ji ber ku em tabloya tevahî jê nakin, wê hingê dibe ku pêşî li rûpela yekem, dûv re jî ya hezarî, biqewime, û paşê vegeriya ser ya yekem. Û heke di navbera van serdanên rûpela yekem de xala kontrolê berê ew li ser dîskê tomar kiribe, wê hingê ew ê wê dîsa hilîne, ji ber ku me ew cara duyemîn pîs kiriye.
Û em ê gelek caran zorê bidin nuqteya kontrolê. Weke ku ji bo wê operasyonên zêde hene.
Lê ev ne hemû ye. Di Postgres de, rûpel 8 kilobyte, û di Linux de 4 kilobyte. Û mîhengek full_page_writes heye. Ew ji hêla xwerû ve hatî çalak kirin. Û ev rast e, ji ber ku heke em wê vemirînin, xeterek heye ku heke têkçûnek hebe, tenê nîvê rûpelê xilas bibe.
Tevgera têketina WAL-ê ya têketina pêşwext wusa ye ku gava me xalek kontrolê hebe û em rûpelek yekem car biguhezînin, tevahiya rûpelê, ango hemî 8 kilobyte, di têketina pêş de diqede, her çend em tenê rêzek ku giraniya wê 100 byte ye guhert. Û em neçar in ku tevahiya rûpelê binivîsin.
Di guhertinên paşerojê de dê tenê tixûbek taybetî hebe, lê yekem car em her tiştî dinivîsin.
Û, li gorî vê yekê, heke nuqteya kontrolê dîsa çêbibe, wê hingê pêdivî ye ku em her tiştî ji nû ve dest pê bikin û tevahiya rûpelê bişkînin. Digel nuqteyên kontrolê yên pir caran, dema ku em di heman rûpelan de dimeşin, full_page_writes = on dê ji ya ku çêbibe mezintir be, ango em bêtir WAL çêdikin. Zêdetir ji kopiyan, arşîvê, dîskê re tê şandin.
Û, li gorî vê yekê, du kêmasiyên me hene.
Ger em max_wal_size zêde bikin, derdikeve holê ku em hem karê xala kontrolê û hem jî ya nivîskarê wal hêsantir dikin. Û ev pir baş e.
Werin em terabyteyekê saz bikin û pê re bijîn. Çi xerab e? Ev xirab e, ji ber ku di rewşek têkçûnê de em ê bi saetan rabin, ji ber ku xala kontrolê demek dirêj berê bû û jixwe gelek tişt hatine guhertin. Û ji bo van hemûyan divê em REDO bikin. Û ji ber vê yekê em rêzek duyemîn ceribandinan dikin.
Em operasyonê dikin û dibînin dema ku nuqteya kontrolê nêzîkê qedandinê ye, em bi armanc kuştinek -9 Postgres dikin.
Û piştî wê, em wê dîsa dest pê bikin, û bibînin ka ew ê çiqas dem bigire ku li ser vê amûreyê rabe, ango, ew ê di vê rewşa xirab de çiqas REDO bike.
Ez ê du caran bibînim ku rewş xirab e. Ya yekem, em berî dawiya nuqteya kontrolê ketin, ji ber vê yekê em gelek winda ne. Ya duyemîn jî, me operasyoneke mezin pêk anî. Û heke xalên kontrolê demek dirêj hebe, wê hingê bi îhtîmalek kêm WAL dê ji nuqteya kontrolê ya paşîn ve hatî çêkirin. Yanî ev du caran windaker e.
Em vê rewşê ji bo max_wal_size cihêreng dipîvin û fam dikin ku heke max_wal_size 64 gigabayt be, wê hingê di rewşek ducarî ya herî xirab de em ê 10 hûrdem rabin. Û em difikirin ka ev li me dike yan na. Ev pirsgirêkek karsaziyê ye. Pêdivî ye ku em vê wêneyê nîşanî berpirsiyarên biryarên karsaziyê bidin û bipirsin: "Di rewşek pirsgirêkê de dema herî zêde em dikarin li bendê bin çend e? Ma em dikarin 3-5 deqeyan di rewşeke xerabtir de razên?” Û hûn biryarek bidin.
Û li vir xalek balkêş heye. Di konferansê de li ser Patroni çend raporên me hene. Û dibe ku hûn wê bikar bînin. Ev ji bo Postgres otofailover e. GitLab û Data Egret li ser vê yekê axivîn.
Û heke we otofailoverek heye ku dê di 30 çirkeyan de çêbibe, wê hingê dibe ku em 10 hûrdeman razên? Ji ber ku di vê nuqteyê de em ê li replica veguherînin, û her tişt dê baş be. Ev mijareke nakok e. Ez bersiveke zelal nizanim. Ez tenê hîs dikim ku ev mijar ne tenê li dora başkirina karesatê ye.
Ger em ji têkçûnek dirêj başbûnek hebe, wê hingê em ê di gelek rewşên din de nerehet bibin. Mînakî, di heman ceribandinan de, dema ku em tiştek dikin û carinan neçar in ku 10 hûrdem bisekinin.
Ez ê dîsa jî pir dûr neçim, hetta ku me otofailover hebe. Wekî qaîdeyek, nirxên wekî 64, 100 gigabytes nirxên baş in. Carinan jî hêja ye ku kêm hilbijêrin. Bi gelemperî, ev zanistek zehf e.
Ji bo ku hûn ji bo nimûne, max_wal_size = 1, 8 dubare bikin, hûn hewce ne ku operasyona girseyî gelek caran dubare bikin. Te ew kir. Û hûn dixwazin dîsa li ser heman bingehê bikin, lê we berê her tişt jêbirin. Çi bikim?
Ez ê paşê li ser çareseriya me û ya ku em di rewşên weha de dubare bikin ji we re vebêjim. Û ev nêzîkatiya herî rast e.
Lê di vê mijarê de em bi şens bûn. Ger, wekî ku li vir dibêje "DESTPÊK, JÊBIRBIN, BAŞ BIKE", wê hingê em dikarin JÊBIRINÊ dubare bikin. Ango ger me bi xwe betal kir, wê demê em dikarin dubare bikin. Û ji hêla fîzîkî ve daneyên we dê li wir bin. Hûn jî bi felekê nabin. Hûn dikarin li ser vê DELETE dubare bikin.
Ev DELETE bi ROLLBACK re îdeal e ji bo birêkûpêkkirina xala kontrolê, hetta ku hûn ne xwediyê laboratîfên databasê yên bi rêkûpêk nebin.
Me bi stûnek “i” nîşanek çêkir. Postgres stûnên karûbarê hene. Heya ku bi taybetî jê neyê xwestin ew nayên dîtin. Ev in: ctid, xmid, xmax.
Ctid navnîşana fîzîkî ye. Rûpelê sifir, yekem car di rûpelê de.
Tê dîtin ku piştî ROOLBACKê tuple li heman cihî maye. Ango em dikarin dîsa biceribînin, ew ê bi heman rengî tevbigere. Ya sereke ev e.
Xmax dema mirina tuple ye. Ew têketinê ye, lê Postgres dizane ku ev danûstendin paşve hat avêtin, ji ber vê yekê ne girîng e ku ew 0 be an danûstendinek paşde vegere. Ev pêşniyar dike ku DELETE dikare ji bo dubarekirin û ceribandina operasyonên girseyî yên tevgera pergalê were bikar anîn. Hûn dikarin ji bo xizanan laboratîfên databasê çêbikin.
Ev li ser bernamenûsan e. Di derbarê DBA-yê de jî, ew her gav ji bernamenûsan re ji bo vê yekê şermezar dikin: "Çima hûn operasyonên ewqas dirêj û dijwar dikin?" Ev mijarek perpendîkular bi tevahî cûda ye. Berê rêveberî hebû, lê niha wê pêşketin hebe.
Eşkere ye ku me ew perçe perçe nekiriye. Diyar e. Ne mimkûn e ku DELETEyek wusa ji bo komek mîlyon rêzan perçe bibe. Ew ê 20 hûrdeman bigire ku meriv bike, û her tişt dê derewan bike. Lê, mixabin, tewra pêşdebirên pispor jî di pargîdaniyên pir mezin de xeletiyan dikin.
Çima şikandina girîng e?
-
Ger em bibînin ku dîsk dijwar e, wê hingê em wê hêdî bikin. Û heke em şikestî bin, wê hingê em dikarin rawestan zêde bikin, em dikarin lêdanê hêdî bikin.
-
Û em ê ji bo demeke dirêj kesên din asteng nekin. Di hin rewşan de ne girîng e, heke hûn zibilên rastîn ên ku kes li ser naxebite radikin, wê hingê hûn ê bi îhtîmalek mezin ji bilî xebata otovacuumê kesek asteng nekin ji ber ku ew ê li benda qedandina danûstendinê bimîne. Lê heke hûn tiştek ku kesek din bixwaze jêbirin, wê hingê ew ê bêne asteng kirin, dê celebek reaksiyonek zincîre hebe. Divê danûstandinên dirêj li ser malper û sepanên mobîl werin dûr kirin.
Ev balkêş e. Ez pir caran dibînim ku pêşdebiran dipirsin, "Divê ez çi pîvana pakêtê hilbijêrin?"
Eşkere ye ku her ku mezinahiya hevîrê mezintir be, sermaya danûstendinê, ango sermaya danûstendinê ya zêde kêm dibe. Lê di heman demê de, dema vê danûstendinê zêde dibe.
Rêgezek min a pir hêsan heye: bi qasî ku gengaz dibe bigirin, lê ji darvekirinê serê çirkeyê derbas nekin.
Çima saniye? Ravekirin ji her kesî re, ji kesên ne-teknîkî jî re pir hêsan û têgihîştî ye. Em bertek dibînin. Were em 50 milî çirkeyan bigirin. Ger tiştek hatibe guhertin, çavê me dê bertek nîşan bide. Ger kêm be, dijwartir e. Ger tiştek piştî 100 milî çirkeyan bersivê bide, mînakî, we bi mişkê bikirtînin û ew piştî 100 milîsaniyeyan bersiv da we, hûn jixwe vê derengiya hindik hîs dikin. Duyemîn jixwe wekî şikandek tê fêm kirin.
Li gorî vê yekê, ger em operasyonên xwe yên girseyî di nav teqînên 10 saniyeyî de dabeş bikin, wê demê xetereya ku em ê kesek asteng bikin dikevin ber xeterê. Û ew ê çend saniyan bixebite, û mirov wê berê xwe bidinê. Ji ber vê yekê ez tercîh dikim ku ji saniyek zêdetir nekim. Lê di heman demê de, wê pir piçûk nehêlin, ji ber ku sermaya danûstendinê dê berbiçav be. Ew ê ji bo bingehê girantir be, û dibe ku pirsgirêkên cûda yên din derkevin.
Em mezinahiya pakêtê hilbijêrin. Di her rewşê de em dikarin vê yekê cûda bikin. Dikare were otomatîk. Û em ji karbidestiya hilanîna yek pakêtê piştrast in. Ango, em yek pakêtê PÊŞKIRIN an jî NAVKIRIN.
Bi awayê, her tiştê ku ez ji we re dibêjim ne tenê di derbarê DELETE de ye. Wekî ku we texmîn kir, ev li ser daneyan operasyonên girseyî ne.
Û em dibînin ku plan pir baş e. Hûn dikarin şanoya îndeksê bibînin, hê çêtir indeks tenê bişopînin. Û me hejmareke piçûk a daneyên tevlîhev hene. Û her tişt di kêmtirî duyemîn de dixebite. Yekemxweş.
Û em hîna jî hewce ne ku pê ewle bin ku xirabiyek tune. Wusa diqewime ku beşên pêşîn zû têne xebitandin, û paşê her tişt xirabtir û xirabtir û xirabtir dibe. Pêvajoyek wusa ye ku hûn hewce ne ku pir ceribandinê bikin. Ya ku ji bo laboratîfên databasê hewce ne ev e.
Û em hîn jî hewce ne ku tiştek amade bikin da ku ew ê bihêle ku em di hilberînê de rast çavdêriya vê yekê bikin. Mînakî, em dikarin wextê di têketinê de binivîsin, em dikarin binivîsin ku em niha li ku ne û me niha kî jê kiriye. Û ev ê bihêle ku em paşê fam bikin ka çi diqewime. Û heger tiştek çewt e, zû pirsgirêkê bibînin.
Ger hewce be ku em karbidestiya pirsan kontrol bikin û pêdivî ye ku em gelek caran dubare bikin, wê hingê tiştek wekî botek heval heye. Ew jixwe amade ye. Her roj ji hêla bi dehan pêşdebiran ve tê bikar anîn. Û ew dikare li gorî daxwazê di 30 çirkeyan de databasek mezin a terabyte peyda bike, kopiyek we bixwe. Û hûn dikarin li wir tiştek jêbirin û bêjin RESET, û dîsa jêbirin. Hûn dikarin bi vî rengî biceribînin. Ez di vî tiştî de paşerojê dibînim. Û em jixwe vê yekê dikin.
Stratejiyên dabeşkirinê çi ne? Ez 3 stratejiyên dabeşkirinê yên cihêreng ên ku pêşdebiran li ser pakêtê bikar tînin dibînim.
Ya yekem pir hêsan e. Nasnameya me ya jimare heye. Û werin em wê di navberên cûda de veqetînin û bi wê re bixebitin. Nerazîbûnê diyar e. Di beşa yekem de, dibe ku 100 xetên me yên çopê yên rastîn hebin, di ya duyemîn de 5 rêz an jî qet nebe, an jî dê her 1 xetên me bibin zibil. Karê pir nehevseng, lê şikandina hêsan e. Nasnameya herî zêde girtin û şikandin. Ev nêzîkatiyeke naîf e.
Stratejiya duyemîn nêzîkatiyek hevseng e. Li Gitlabê tê bikaranîn. Me sifrê girt û seh kir. Me sînorên pakêtên nasnameyê dît ku di her pakêtê de tam 10 tomar hene. Û wan ez di hindek dorê de asê kirim. Û em bêtir pêvajoyê bikin. Hûn dikarin vê yekê di çend mijaran de bikin.
Di stratejiya yekem de, bi awayê, hûn dikarin vê yekê di çend mijaran de jî bikin. Ne zehmet e.
Lê nêzîkatiyek sartir û çêtirîn heye. Ev stratejiya sêyemîn e. Û gava ku gengaz be, çêtir e ku hûn wê hilbijêrin. Em vê yekê li ser bingehek taybetî dikin. Di vê rewşê de, ew ê bi îhtîmalek mezin li ser bingeha şert û mercên çopê û nasnameya me bibe navnîşek. Em ê nasnameyê têxin nav xwe da ku ew tenê şansek be da ku em neçin serhev.
Bi gelemperî, şanoya tenê îndeks ji şopandina pêvekê zûtir e.
Û em zû nasnameyên xwe yên ku em dixwazin jêbirin bibînin. Em BATCH_SIZE pêşwext hildibijêrin. Û em ne tenê wan distînin, em wan bi rengekî taybetî distînin û tavilê rast dikin. Lê em wan bi awakî kilît dikin ku ger jixwe girtî bin, em wan negirin, lê bimeşin û yên din bigirin. Ev ji bo nûvekirina derbasbûna girtî ye. Ev taybetmendiya super Postgres dihêle ku ger em bixwazin em di gelek mijaran de bixebitin. Dibe ku di yek mijarê de. Û paşê CTE heye - ev yek daxwazek e. Û me rakirina rastîn li qata duyemîn a vê CTE-yê diqewime - returning *. Hûn dikarin id vegerînin, lê ew çêtir e *, heke di her rêzê de daneyên we hindik bin.
Çima em hewceyê vê yekê ne? Ji bo ku em rapor bikin pêdivî bi vê yekê heye. Me niha di rastiyê de ew qas rêz jêbirin. Û sînorên me bi ID an afirandin_at wiha ne. Hûn dikarin min, herî zêde bikin. Tiştek din dikare were kirin. Gelek tişt hene ku hûn dikarin li vir bicivînin. Û ev ji bo çavdêriyê pir hêsan e.
Di derbarê îndeksê de notek din jî heye. Ger em biryar bidin ku ji bo vê peywira taybetî hewceyê pêvekek taybetî ye, wê hingê pêdivî ye ku em pê ewle bin ku ew tenê nûvekirinên tîrêjê xera nake. Yanî Postgres xwedî statîstîkên wiha ye. Ev dikare di pg_stat_user_tables de ji bo tabloya we were dîtin. Hûn dikarin bibînin ka nûvekirinên germ têne bikar anîn an na.
Rewş hene ku dibe ku navnîşa weya nû bi hêsanî wan qut bike. Û hemî nûvekirinên din ên ku jixwe têne xebitandin dê hêdî bibin. Ne tenê ji ber ku index xuya bû (her index nûvekirinan hinekî hêdî dike, lê tenê piçek), lê li vir ew ê dîsa jî tiştan tevlihev bike. Û ne gengaz e ku meriv ji bo vê tabloyê xweşbîniyek taybetî bike. Ev carinan dibe. Ev hûrgelek wusa ye ku hindik kes tê bîra xwe. Û ew hêsan e ku li ser vê rakêşê gav bikin. Carinan diqewime ku hûn hewce ne ku hûn ji hêla din ve nêzîkatiyek bibînin û dîsa jî bêyî vê navnîşa nû bikin, an navnîşek din çêbikin, an tiştek din bikin, mînakî, hûn dikarin rêbaza duyemîn bikar bînin.
Lê ev stratejiya herî çêtirîn e, ka meriv çawa wê li koman veqetîne û bi yek daxwazê ve di koman de bişewitîne, her carê hinekî jê bibe, hwd.
Danûstandinên dirêj -
Otovacuum asteng kirin
Pirsgirêka astengkirinê
Şaşiya #5 xeletiyek mezin e. Nikolay ji Okmeter li ser çavdêriya Postgres axivî. Mixabin, çavdêriya bêkêmasî ya Postgres tune. Hin nêzîk in, hin jê dûrtir in. Okmeter têra xwe nêzîk e ku bêkêmasî be, lê pir kêm e û pêdivî ye ku were zêdekirin. Divê hûn ji bo vê yekê amade bibin.
Mînakî, çêtir e ku meriv tiliyên mirî bişopîne. Ger di maseya we de gelek tiştên mirî hene, wê hingê tiştek xelet e. Çêtir e ku em niha bertek nîşan bidin, wekî din dibe ku li wir xirabiyek çêbibe, û em dikarin razên. Diqewime.
Ger IO-ya mezin hebe, wê hingê diyar e ku ev ne baş e.
Danûstandinên dirêj jî. Divê danûstandinên dirêj li ser OLTP neyên destûr kirin. Û li vir lînkek bi snippetê re heye, ku dihêle hûn vê perçeyê bigirin û berê xwe bidin hin şopandina danûstendinên dirêj.
Çima danûstandinên dirêj xirab in? Ji ber ku hemî qefle dê tenê di dawiyê de werin berdan. Û em her kesî girtî ne. Zêdetir em otovacuumê ji bo hemî tabloyan asteng dikin. Ev qet ne baş e. Tewra ku we li ser replika standby-ya germ çalak kiriye, ev hîn jî xirab e. Bi gelemperî, çêtir e ku meriv ji danûstendinên dirêj li her deverê dûr bixe.
Ger gelek tabloyên me yên ku nehatine valakirin hene, wê hingê pêdivî ye ku em hişyariyek hebe. Li vir rewşeke wiha mumkin e. Em dikarin nerasterast bandorê li operasyona otovacuumê bikin. Ev pişkek ji Avito ye, ku min hinekî çêtir kir. Û derket holê ku amûrek balkêş e ku em bibînin ka me bi otovacuumê re çi heye. Mînakî, li wir hin tablo li benda li bendê ne û ew ê li benda dora xwe nemînin. Her weha hûn hewce ne ku wê di çavdêriyê de bihêlin û hişyariyek hebe.
Û blokan derdixe. Daristana astengkirina daran. Ez hez dikim ku tiştek ji kesek bistînim û çêtir bikim. Li vir min ji Data Egret CTE-ya paşverû ya xweş girt, ku daristanek darên girtî nîşan dide. Ev ji bo teşhîsê tiştekî baş e. Û çavdêrî jî dikare li ser bingeha wê were avakirin. Lê divê ev bi baldarî were kirin. Pêdivî ye ku hûn ji bo xwe daxuyaniyek_timeout piçûk çêbikin. Û lock_timeout tê xwestin.
Carinan ev hemû xeletî bi hev re çêdibin.
Li gorî min di vir de xeletiya herî girîng rêxistinî ye. Ew rêxistinî ye, ji ber ku teknolojî naxebite. Ev hejmar 2 ye - wan li cîhê xelet kontrol kirin.
Me li wir kontrol nekir ji ber ku me klonek hilberînê tune bû ku kontrolkirina wê hêsan bû. Dibe ku pêşdebir bi tevahî negihîje hilberînê.
Û me li cîhekî xelet kontrol kir. Ger wan li wir kontrol bikira, me ê bi xwe bidîta. Pêşdebir dikaribû van hemîyan bêyî DBA-yê jî bibîne, heke wî ew di hawîrdorek baş de kontrol kir, ku li wir heman danehev û rêkûpêkek wekhev heye. Dê ev hemû kêmasî bidîta û şerm bikira.
Zêdetir li ser valahiya gerîdeyê. Piştî ku me paqijkirinek girseyî ya çend mîlyon xet kir, em hîn jî hewce ne ku REPACK bikin. Ev bi taybetî ji bo indexan girîng e. Piştî ku me her tişt li wir paqij kir, ew ê xirab bibin.
Û heke hûn dixwazin karê rojane yê tazîkirinê vegerînin, wê hingê ez pêşniyar dikim ku ew pir caran, lê piçûktir bikin. Ew dikare her hûrdem carekê an jî pir caran piçûktir be. Û pêdivî ye ku em du tiştan bişopînin: ku ev tişt ne xeletî ye û ew li paş nemîne. Xefeta ku min nîşan da dê bihêle hûn vê yekê çareser bikin.
Ya ku em dikin çavkaniya vekirî ye. Ev li ser GitLab hatiye şandin. Û em wiya dikin ku mirov bêyî DBA-yê jî kontrol bike. Em laboratûvarek databasê çêdikin, ango em gazî pêkhateya bingehîn a ku Joe niha li ser dixebite, dikin. Û hûn dikarin kopiyek hilberînê bigirin. Naha pêkanîna Joe ji bo sistbûnê heye, hûn dikarin li wir bibêjin: "daxwazek wusa û wusa rave bikin" û tavilê encam ji bo kopiya databasa xwe bistînin. Tewra hûn dikarin li wir DELETE bikin, û kes guh nade.
Em bibêjin 10 terabaytên we hene, em laboratûwareke databasê jî 10 terabyte çêdikin. Û 10 pêşdebiran dikarin bi hevdemî bi databasên 10 terabyte re hevdem bixebitin. Her kes çi bixwaze dikare bike. Dikare jê bibe, dakeve, hwd.. Ev fantastîk e. Em ê sibê li ser vê biaxivin.
Ji vê re tê gotin dabînkirina tenik. Ev dabînkirina nazik e. Ev celebek xeyalek e ku pir derengiya pêşkeftin û ceribandinê ji holê radike û cîhanê di vî warî de cîhek çêtir dike. Ango, ew tenê dihêle hûn pirsgirêkên bi operasyonên girseyî re dûr bixin.
Nimûne: Databasa 5 terabyte, di kêmtirî 30 çirkeyan de kopiyek peyda dike. Û ew ne girêdayî mezinbûnê ye, ango çend terabytes ne girîng e.
Îro hûn dikarin biçin û li amûrên me dikolin. Hûn dikarin qeyd bikin û bibînin ka çi heye. Hûn dikarin vê botê ji bo xwe saz bikin. Ew belaş e. Nivîsîn.
Pirsên
Pir caran di rewşên rastîn de derdikeve holê ku daneyên ku divê di tabloyê de bimîne ji ya ku divê were jêbirin pir kêmtir e. Ango, di rewşek wusa de pir caran pêkanîna vê nêzîkatiyê hêsantir e, dema ku hêsantir e ku meriv tiştek nû biafirîne, tenê daneyên pêwîst li wir kopî bike û tabloya kevn binivîsîne. Eşkere ye ku dema ku hûn diguhezin ji bo vê gavê pêdivî bi nêzîkatiyek nermalavê heye. Ev nêzîkatî çawa ye?
Ev nêzîkatiyek pir baş û karekî pir baş e. Ew pir dişibihe ya ku pg_repack dike, ew pir dişibihe ya ku divê hûn bikin dema ku we kesan nas kir 4 byte. Gelek çarçove ev çend sal berê kirin, û lewheyên nû mezin bûne, û pêdivî ye ku ew li 8 byte werin veguheztin.
Ev kar pir dijwar e. Me ew kir. Û divê hûn pir baldar bin. Qefle hene û hwd.. Lê pêk tê. Ango, nêzîkatiya standard ev e ku meriv pg_repack bikar bîne. Hûn nîşanek weha radigihînin. Berî ku hûn dest bi dagirtina wê bi daneya wêneya wêneyê bikin, hûn tabloyek ku hemî guhertinan dişopîne jî radigihînin. Li wir hîleyek heye ku dibe ku hûn hin guhertinan jî bişopînin. Zehf hene. Û dûv re hûn veguherînin, guhertinan derxînin. Dema ku em her kesî kilît bikin dê rawestek kurt hebe, lê bi giştî ev tê kirin.
Ger hûn li pg_repack li GitHub mêze bikin, wê hingê gava ku peywirek hebû ku nasnameyê ji int 4-ê veguherîne int 8-ê, wê hingê fikirek hebû ku meriv pg_repack bixwe bikar bîne. Ev jî mimkun e, lê ev hinekî rêbazek hacker e, lê ew ê ji bo vê yekê jî bixebite. Hûn dikarin destwerdana teşqela ku pg_repack bikar tîne û li wir bibêjin: "Em ne hewceyê vê daneyê ne," ango em tenê ya ku ji me re hewce dike vediguhezînin. Û paşê ew tenê diguhere û ew e.
Bi vê nêzîkbûnê re, em kopiyek duyemîn a tabloyê jî distînin, ku tê de dane ji berê ve têne navnîş kirin û bi pêdekekên xweşik pir bi rêkûpêk têne danîn.
Nexêr, ev nêzîkatiyek baş e. Lê ez dizanim ku ji bo vê yekê, ango çêkirina çareseriyek gerdûnî, hewildan hene ku otomasyonê pêşve bibin. Ez dikarim vê otomatê bi we bidim nasîn. Ew di Python de hatî nivîsandin, tiştên baş.
Ez piçekî ji cîhana MySQL me, ji ber vê yekê ez hatim guhdarî bikim. Û em vê rêbazê bikar tînin.
Lê ew tenê heke me 90% hebe. Ger% 5 me hebe, wê hingê karanîna wê ne pir baş e.
Spas ji bo raporê! Ger çavkaniyên ku ji bo çêkirina kopiyek tam a prod tune bin, gelo algorîtmayek an formulek heye ku bar an mezinahiyê hesab bike?
Pirsa baş. Heya nuha em dikarin databasên pir-terabyte bibînin. Her çend hardware li wir ne yek be jî, mînakî, kêm bîranîn, kêm pêvajo û dîskên tam ne yek bin, em dîsa jî wiya dikin. Ger bi rastî li cîhek tune, wê hingê hûn hewce ne ku li ser wê bifikirin. Bihêle ez heta sibê li ser bifikirim, hûn hatin, em ê biaxivin, ev pirsek baş e.
Spas ji bo raporê! We pêşî dest bi axaftinê kir ku Postgresek xweş heye, ku xwedan sînorkirinên wusa û wusa ye, lê ew pêş dikeve. Û ev hemû bi giranî kêşek e. Ma ev hemî nakokî bi pêşkeftina Postgres bi xwe re nabin, ku tê de dê celebek DELETE deferent xuya bibe an tiştek din ku divê di astek nizm de tiştê ku em li vir hewl didin bi hin navgînên xweyên xerîb veşêrin, bihêle?
Ger di SQL de me got ku em di yek danûstendinê de gelek tomar jêbirin an nûve bikin, wê hingê Postgres çawa dikare vê belav bike? Em di operasyonan de ji aliyê fîzîkî ve bi sînor in. Em ê hîn ji bo demek dirêj vê yekê bikin. Û em ê di vê demê de kilît bikin, hwd.
Bi îndeksan re jî heman tişt kirin.
Ez dikarim texmîn bikim ku heman verastkirina nuqteya kontrolê dikare bixweber be. Rojekê dibe ku ev yek bibe. Lê paşê ez bi rastî ji pirsê fêm nakim.
Pirs ev e: gelo vektorek pêşkeftinê heye ku li wir rast diçe, û li vir bi ya we re paralel diçe? Ewan. Ma ew hîn li ser vê yekê nafikirin?
Min behsa prensîbên ku niha dikarin bên bikaranîn kir. Botek din heye , bi vê yekê hûn dikarin birêkûpêkkirina xala kontrolê ya otomatîkî bikin. Dê ev yek carî li Postgres bibe? Nizanim, ev hîn jî nayê nîqaş kirin. Em hîn ji vê yekê dûr in. Lê zanyar hene ku pergalên nû çêdikin. Û ew me dixin nav navnîşên otomatîkî. Pêşketin hene. Mînakî, hûn dikarin li guheztina otomatîkê binêrin. Ew bixweber parametreyan hildibijêre. Lê ew ê hêj ji bo we guheztina xala kontrolê neke. Ango, ew ê ji bo performansê, tampona şêlê, hwd hilbijêrin.
Û ji bo birêkûpêkkirina xala kontrolê hûn dikarin tiştê jêrîn bikin: heke we hezar kom û perçeyên cûda yên hardware, makîneyên cihêreng ên virtual di ewr de hebin, hûn dikarin bota me bikar bînin. otomatiyê bikin. Û max_wal_size dê bixweber li gorî mîhengên mebesta we were hilbijartin. Lê mixabin heya niha ev yek ne nêzî kernelê ye jî.
Paş nîvro We behsa xetereyên danûstandinên dirêj kir. We got ku di bûyera jêbirinê de otovacuum tê asteng kirin. Wekî din ev çawa zirarê dide me? Ji ber ku em bêtir behsa azadkirina cîh û karanîna wê dikin. Ma wekî din çi heye ku em winda bikin?
Dibe ku otovacuum li vir ne pirsgirêka herî mezin be. Û rastiya ku danûstendinek dirêj dikare danûstendinên din asteng bike îhtîmalek xeternaktir e. Ew dibe ku hevdîtin an jî ne. Ger ew hevdîtin kir, wê hingê dibe ku tişt pir xirab bibin. Û bi otovacuumê ev jî pirsgirêkek e. Di OLTP de du pirsgirêk bi danûstendinên dirêj hene: kilît û otovacuum. Û heke we li ser replikayê bertekên standby-a germ çalakkirî be, wê hingê astengkirina otovacuumê jî dê bigihîje masterê, ew ê ji kopiyê were. Lê bi kêmanî dê li wir qefl nebe. Û li vir dê qefle hebin. Em li ser guhertinên daneyê diaxivin, ji ber vê yekê kilît li vir xalek girîng in. Û heke ev ji bo demek dirêj û dirêj berdewam bike, wê hingê bêtir û bêtir danûstandin têne asteng kirin. Ew dikarin kesên din bixin xefikê. Û darên qeflê xuya dibin. Min girêdanek ji perçeyê re peyda kir. Û ev pirsgirêk zû ji pirsgirêka otovacuumê, ya ku tenê dikare kom bibe, bêtir diyar dibe.
Spas ji bo raporê! Te rapora xwe bi gotina ku te xelet ceriband dest pê kir. Me fikra xwe domand ku pêdivî ye ku em heman amûran bigirin, bi bingehê tam heman. Em bêjin me bingehek da pêşdebir. Û wî daxwaza xwe bi cih anî. Û xuya dike ku ew baş dike. Lê ew li ser zindî kontrol nake, lê di zindî de, mînakî, barê me 60-70%. Û heke em vê ahengê bikar bînin jî, ew pir baş dernakeve
Hebûna pisporek li ser tîmê we û karanîna pisporên DBA-yê ku dikarin pêşbînî bikin ka dê di binê barkirina paşerojê ya rastîn de çi bibe girîng e. Gava ku me bi tenê guhertinên xwe yên paqij ajot, em wêneyê dibînin. Lê nêzîkatiyek pêşkeftî ew bû ku me dîsa heman tişt kir, lê bi barek hilberîna simulasyonê. Ev bi tevahî xweş e. Em hîn jî hewce ne ku di vê xalê de mezin bibin. Ew gihîştî ye. Me bi tenê li tiştên ku me hene mêze kir û her weha me nihêrî ka çavkaniyên me têr hene yan na. Ew pirsek baş e.
Dema ku em berê hilbijarkek çopê dikin û ji bo nimûne, alayek me jêbirin heye
Ya ku otovacuum bixweber li Postgres dike ev e.
Oh, ew wiya dike?
Autovacuum berhevkarê çopê ye.
Spas!
Spas ji bo raporê! Ma vebijarkek heye ku meriv tavilê databasek bi dabeşkirinê dîzayn bike da ku hemî zibil ji tabloya sereke li deverek li kêlekê were rakirin?
Helbet heye.
Wê hingê em dikarin xwe biparêzin ger me tabloyek ku divê neyê bikar anîn kilît kiribe?
Helbet heye. Lê ev pirsek mirîşk û hêk e. Ger em hemî zanibin dê di pêşerojê de çi bibe, wê hingê, bê guman, em ê her tiştî mezin bikin. Lê karsazî diguhere, stûnên nû û daxwazên nû xuya dibin. Û paşê - oops, em dixwazin wê jêbirin. Lê ev rewşek îdeal e; di jiyanê de dibe, lê ne her gav. Lê bi giştî ew ramanek baş e. Tenê qut bikin û ew e.
Source: www.habr.com