Kā aizmugursistēmas izstrādātājs saprot, ka SQL vaicājums labi darbosies “produktā”? Lielos vai strauji augošos uzņēmumos ne visiem ir pieejams "produkts". Un ar piekļuvi ne visus pieprasījumus var nesāpīgi pārbaudīt, un datu bāzes kopijas izveide bieži aizņem stundas. Lai atrisinātu šīs problēmas, mēs izveidojām mākslīgu DBA - Džo. Tas jau ir veiksmīgi ieviests vairākos uzņēmumos un palīdz vairāk nekā duci izstrādātāju.
Video:
Sveiki visiem! Mani sauc Anatolijs Stenslers. Es strādāju uzņēmumā . Mēs esam apņēmušies paātrināt izstrādes procesu, novēršot izstrādātāju, DBA un QA kavējumus, kas saistīti ar Postgres darbu.
Mums ir lieliski klienti, un šodien daļa no ziņojuma būs veltīta gadījumiem, ar kuriem sastapāmies, strādājot ar viņiem. Es runāšu par to, kā mēs viņiem palīdzējām atrisināt diezgan nopietnas problēmas.
Izstrādājot un veicot sarežģītas lielas slodzes migrācijas, mēs uzdodam sev jautājumu: "Vai šī migrācija sāksies?". Mēs izmantojam pārskatīšanu, izmantojam pieredzējušāku kolēģu, DBA ekspertu zināšanas. Un viņi var pateikt, vai tas lidos vai nē.
Bet varbūt būtu labāk, ja mēs paši varētu to pārbaudīt uz pilna izmēra kopijām. Un šodien mēs tikai runāsim par to, kādas pieejas testēšanai ir tagad un kā to var izdarīt labāk un ar kādiem rīkiem. Mēs arī runāsim par šādu pieeju plusiem un mīnusiem un to, ko mēs šeit varam labot.
Kurš jebkad ir veidojis indeksus tieši prod vai veicis kādas izmaiņas? Diezgan nedaudz. Un kam tas noveda pie tā, ka dati tika zaudēti vai bija dīkstāves? Tad jūs zināt šīs sāpes. Paldies Dievam, ka ir rezerves kopijas.
Pirmā pieeja ir testēšana prod. Vai arī, kad izstrādātājs sēž uz vietējās mašīnas, viņam ir testa dati, ir kaut kāda ierobežota izvēle. Mēs sākam ražot, un mēs iegūstam šo situāciju.
Tas sāp, tas ir dārgi. Droši vien labāk to nedarīt.
Un kāds ir labākais veids, kā to izdarīt?
Ņemsim iestudējumu un tur atlasīsim kādu produkcijas daļu. Vai labākajā gadījumā ņemsim īstu prod, visus datus. Un pēc tam, kad būsim to izstrādājuši lokāli, mēs papildus pārbaudīsim iestudējumu.
Tas ļaus mums novērst dažas kļūdas, t.i., neļaus tām parādīties prod.
Kādas ir problēmas?
- Problēma ir tā, ka mēs dalāmies ar šo iestudējumu ar kolēģiem. Un ļoti bieži gadās, ka jūs veicat kaut kādas izmaiņas, bam - un nav datu, darbs ir nolaists. Iestudējums bija vairākus terabaitus. Un jums ir jāgaida ilgi, lai tas atkal paceltos. Un mēs nolemjam to pabeigt rīt. Tas ir viss, mums ir attīstība.
- Un, protams, mums tur strādā daudz kolēģu, daudzas komandas. Un tas ir jādara manuāli. Un tas ir neērti.
Un ir vērts teikt, ka mums ir tikai viens mēģinājums, viens kadrs, ja mēs vēlamies veikt dažas izmaiņas datu bāzē, pieskarties datiem, mainīt struktūru. Un, ja kaut kas nogāja greizi, ja migrēšanā radās kļūda, mēs ātri neatgriezīsimies.
Tas ir labāks par iepriekšējo pieeju, taču joprojām pastāv liela varbūtība, ka kāda veida kļūda nonāks ražošanā.
Kas mums neļauj katram izstrādātājam dot testēšanas stendu, pilna izmēra kopiju? Es domāju, ka ir skaidrs, kas traucē.
Kam ir datubāze, kas lielāka par terabaitu? Vairāk nekā puse istabas.
Un skaidrs, ka mašīnu turēšana katram izstrādātājam, kad ir tik liela produkcija, ir ļoti dārga, turklāt tas aizņem ilgu laiku.
Mums ir klienti, kuri ir sapratuši, ka ir ļoti svarīgi visas izmaiņas pārbaudīt uz pilna izmēra kopijām, taču viņu datu bāze ir mazāka par terabaitu, un nav resursu, lai katram izstrādātājam būtu testēšanas stends. Tāpēc viņiem ir jālejupielādē izgāztuves lokāli savā mašīnā un jāpārbauda šādā veidā. Tas aizņem daudz laika.
Pat ja to darāt infrastruktūras iekšienē, tad viena terabaita datu lejupielāde stundā jau ir ļoti laba. Bet viņi izmanto loģiskās izgāztuves, lejupielādē lokāli no mākoņa. Viņiem ātrums ir aptuveni 200 gigabaiti stundā. Un vēl vajag laiku, lai no loģiskās izgāztuves apgrieztos, saritinātu indeksus utt.
Taču viņi izmanto šo pieeju, jo tā ļauj nodrošināt produkta uzticamību.
Ko mēs šeit varam darīt? Padarīsim testēšanas stendus lētus un katram izstrādātājam piešķirsim savu testēšanas stendu.
Un tas ir iespējams.
Un šajā pieejā, veidojot plānus klonus katram izstrādātājam, mēs varam tos kopīgot vienā mašīnā. Piemēram, ja jums ir 10 TB datubāze un vēlaties to piešķirt 10 izstrādātājiem, jums nav jābūt XNUMX x XNUMX TB datubāzēm. Jums ir nepieciešama tikai viena iekārta, lai izveidotu plānas izolētas kopijas katram izstrādātājam, izmantojot vienu iekārtu. Es jums pastāstīšu, kā tas darbojas nedaudz vēlāk.
Reāls piemērs:
-
DB - 4,5 terabaiti.
-
Mēs varam iegūt neatkarīgas kopijas 30 sekundēs.
Jums nav jāgaida testa stends un jābūt atkarīgam no tā, cik liels tas ir. Jūs varat to iegūt dažu sekunžu laikā. Tās būs pilnībā izolētas vides, kas savā starpā apmainās ar datiem.
Tas ir lieliski. Šeit mēs runājam par maģiju un paralēlo Visumu.
Mūsu gadījumā tas darbojas, izmantojot OpenZFS sistēmu.
OpenZFS ir kopēšanas un rakstīšanas failu sistēma, kas atbalsta momentuzņēmumus un klonus. Tas ir uzticams un mērogojams. Viņa ir ļoti viegli vadāma. To burtiski var izvietot divās komandās.
Ir arī citas iespējas:
-
lvm,
-
Uzglabāšana (piemēram, Pure Storage).
Datu bāzes laboratorija, par kuru es runāju, ir modulāra. Var ieviest, izmantojot šīs iespējas. Bet pagaidām esam koncentrējušies uz OpenZFS, jo problēmas bija tieši ar LVM.
Kā tas strādā? Tā vietā, lai pārrakstītu datus katru reizi, kad tos mainām, mēs tos saglabājam, vienkārši atzīmējot, ka šie jaunie dati ir no jauna laika punkta, jauns momentuzņēmums.
Un nākotnē, kad vēlamies atcelt vai izveidot jaunu klonu no kādas vecākas versijas, mēs vienkārši sakām: "Labi, dodiet mums šos datu blokus, kas ir atzīmēti šādi."
Un šis lietotājs strādās ar šādu datu kopu. Viņš tos pamazām mainīs, veidos pats savus momentuzņēmumus.
Un mēs zarosim. Katram izstrādātājam mūsu gadījumā būs iespēja izveidot savu klonu, ko viņš rediģē, un koplietotie dati tiks kopīgoti starp visiem.
Lai izvietotu šādu sistēmu mājās, jums jāatrisina divas problēmas:
-
Pirmais ir datu avots, no kurienes jūs tos ņemsit. Varat iestatīt replikāciju ar ražošanu. Es ceru, ka jūs jau varat izmantot jūsu konfigurētās dublējumkopijas. WAL-E, WAL-G vai Bārmenis. Un pat tad, ja izmantojat kādu mākoņa risinājumu, piemēram, RDS vai Cloud SQL, varat izmantot loģiskās izgāztuves. Bet mēs joprojām iesakām izmantot dublējumus, jo ar šo pieeju jūs saglabāsit arī failu fizisko struktūru, kas ļaus jums būt vēl tuvāk tiem rādītājiem, kurus jūs redzētu ražošanā, lai noķertu esošās problēmas.
-
Otrais ir vieta, kur vēlaties mitināt datu bāzes laboratoriju. Tas varētu būt mākonis, tas varētu būt uz vietas. Šeit ir svarīgi teikt, ka ZFS atbalsta datu saspiešanu. Un tas to dara diezgan labi.
Iedomājieties, ka katram šādam klonam atkarībā no darbībām, ko veicam ar bāzi, pieaugs sava veida izstrādātājs. Šim nolūkam izstrādātājam būs nepieciešama arī vieta. Bet, ņemot vērā to, ka mēs paņēmām 4,5 terabaitu bāzi, ZFS to saspiedīs līdz 3,5 terabaitiem. Tas var atšķirties atkarībā no iestatījumiem. Un mums joprojām ir vieta izstrādātājiem.
Šādu sistēmu var izmantot dažādiem gadījumiem.
-
Tie ir izstrādātāji, DBA vaicājumu validācijai, optimizācijai.
-
To var izmantot kvalitātes nodrošināšanas testēšanā, lai pārbaudītu konkrētu migrāciju, pirms to izlaižam prod. Mēs varam arī izveidot īpašas vides kvalitātes nodrošināšanai ar reāliem datiem, kur viņi var pārbaudīt jaunas funkcionalitātes. Un tas prasīs sekundes, nevis gaidīšanas stundas, un dažos citos gadījumos, kad plānās kopijas netiek izmantotas, iespējams, dienas.
-
Un vēl viens gadījums. Ja uzņēmumam nav izveidota analītikas sistēma, mēs varam izolēt plānu produktu bāzes klonu un piešķirt to gariem vaicājumiem vai īpašiem indeksiem, ko var izmantot analīzē.
Izmantojot šo pieeju:
-
Zema kļūdu iespējamība "prod", jo mēs pārbaudījām visas izmaiņas pilna izmēra datos.
-
Mums ir testēšanas kultūra, jo tagad jums nav jāgaida stundām ilgi uz savu stendu.
-
Un nav šķēršļu, nav jāgaida starp testiem. Jūs tiešām varat iet un pārbaudīt. Un tas būs labāk, jo mēs paātrināsim attīstību.
-
Būs mazāk pārstrukturēšanas. Mazāk kļūdu nonāks prod. Mēs vēlāk tos mazāk pārveidosim.
-
Mēs varam mainīt neatgriezeniskas izmaiņas. Šī nav standarta pieeja.
- Tas ir izdevīgi, jo mēs kopīgi izmantojam testu stendu resursus.
Jau labi, bet ko vēl varētu paātrināt?
Pateicoties šādai sistēmai, mēs varam ievērojami samazināt slieksni šādai pārbaudei.
Tagad ir izveidojies apburtais loks, kad izstrādātājam, lai piekļūtu reāliem pilna izmēra datiem, jākļūst par ekspertu. Viņam šāda pieeja ir jāuztic.
Bet kā augt, ja tā nav. Ko darīt, ja jums ir pieejams tikai ļoti neliels testa datu kopums? Tad jūs neiegūsit nekādu reālu pieredzi.
Kā izkļūt no šī loka? Kā pirmo interfeisu, kas ir ērts jebkura līmeņa izstrādātājiem, mēs izvēlējāmies Slack robotu. Bet tas var būt jebkurš cits interfeiss.
Ko tas ļauj darīt? Varat veikt noteiktu vaicājumu un nosūtīt to uz īpašu datu bāzes kanālu. Mēs automātiski izvietosim plānu klonu dažu sekunžu laikā. Izpildīsim šo pieprasījumu. Mēs apkopojam rādītājus un ieteikumus. Parādīsim vizualizāciju. Un tad tas klons paliks, lai šo vaicājumu varētu kaut kā optimizēt, pievienot indeksus utt.
Un arī Slack sniedz mums iespējas sadarboties. Tā kā šis ir tikai kanāls, varat sākt apspriest šo pieprasījumu tieši šāda pieprasījuma pavedienā, ping jūsu kolēģiem, DBA, kas atrodas uzņēmumā.
Bet, protams, ir problēmas. Tā kā šī ir reālā pasaule un mēs izmantojam serveri, kurā vienlaikus tiek mitināti daudzi kloni, mums ir jāsaspiež kloniem pieejamais atmiņas apjoms un CPU jauda.
Bet, lai šie testi būtu ticami, jums ir kaut kā jāatrisina šī problēma.
Ir skaidrs, ka svarīgi ir tie paši dati. Bet mums tas jau ir. Un mēs vēlamies sasniegt tādu pašu konfigurāciju. Un mēs varam dot šādu gandrīz identisku konfigurāciju.
Būtu forši, ja būtu tāda pati aparatūra kā ražošanā, taču tā var atšķirties.
Atcerēsimies, kā Postgres strādā ar atmiņu. Mums ir divas kešatmiņas. Viena no failu sistēmas un viena vietējā Postgres, t.i., koplietotā bufera kešatmiņa.
Ir svarīgi ņemt vērā, ka koplietojamā bufera kešatmiņa tiek piešķirta, startējot Postgres, atkarībā no tā, kādu izmēru norādījāt konfigurācijā.
Un otrā kešatmiņa izmanto visu pieejamo vietu.
Un, veidojot vairākus klonus vienā mašīnā, izrādās, ka mēs pamazām piepildām atmiņu. Un labā nozīmē koplietojamā bufera kešatmiņa ir 25% no kopējā iekārtā pieejamās atmiņas apjoma.
Un izrādās, ja nemainīsim šo parametru, tad vienā mašīnā varēsim palaist tikai 4 instances, t.i., 4 no visiem tādiem plāniem kloniem. Un tas, protams, ir slikti, jo mēs vēlamies, lai viņu būtu daudz vairāk.
Bet, no otras puses, Bufera kešatmiņa tiek izmantota, lai izpildītu vaicājumus indeksiem, tas ir, plāns ir atkarīgs no tā, cik lielas ir mūsu kešatmiņas. Un, ja mēs vienkārši ņemam šo parametru un samazinām to, tad mūsu plāni var daudz mainīties.
Piemēram, ja mums ir liela prod kešatmiņa, Postgres dos priekšroku indeksa izmantošanai. Un ja nē, tad būs SeqScan. Un kāda jēga būtu, ja mūsu plāni nesakristu?
Bet šeit mēs nonākam pie secinājuma, ka patiesībā plāns Postgres nav atkarīgs no konkrēta izmēra, kas norādīts plānā Shared Buffer, tas ir atkarīgs no efektīvas_cache_size.
Efektīvās_kešatmiņas_izmērs ir aptuvenais mums pieejamās kešatmiņas apjoms, t.i., bufera kešatmiņas un failu sistēmas kešatmiņas summa. To nosaka konfigurācija. Un šī atmiņa nav piešķirta.
Un šī parametra dēļ mēs varam apmānīt Postgresu, sakot, ka mums patiesībā ir pieejams daudz datu, pat ja mums šo datu nav. Un līdz ar to plāni pilnībā sakritīs ar ražošanu.
Bet tas var ietekmēt laiku. Un mēs optimizējam vaicājumus pēc laika, taču ir svarīgi, lai laiks būtu atkarīgs no daudziem faktoriem:
-
Tas ir atkarīgs no slodzes, kas pašlaik ir prod.
-
Tas ir atkarīgs no pašas mašīnas īpašībām.
Un tas ir netiešs parametrs, bet patiesībā mēs varam optimizēt tieši pēc datu apjoma, ko šis vaicājums nolasīs, lai iegūtu rezultātu.
Un, ja vēlaties, lai laiks būtu tuvu tam, ko mēs redzēsim prod, tad mums ir jāņem līdzīgākā aparatūra un, iespējams, vēl vairāk, lai visi kloni ietilptu. Bet tas ir kompromiss, t.i., saņemsiet tos pašus plānus, redzēsiet, cik daudz datu nolasīs konkrētais vaicājums un varēsiet secināt, vai šis vaicājums ir labs (vai migrācija) vai slikts, tas vēl ir jāoptimizē .
Apskatīsim, kā Džo ir īpaši optimizēts.
Ņemsim pieprasījumu no reālas sistēmas. Šajā gadījumā datubāze ir 1 terabaits. Un mēs vēlamies saskaitīt jaunu ziņu skaitu, kurām ir vairāk nekā 10 atzīmju Patīk.
Rakstam ziņu kanālam, mums ir izvietots klons. Un mēs redzēsim, ka šāds pieprasījums tiks izpildīts 2,5 minūtēs. Šī ir pirmā lieta, ko mēs pamanām.
B Džo jums parādīs automātiskus ieteikumus, pamatojoties uz plānu un metriku.
Mēs redzēsim, ka vaicājums apstrādā pārāk daudz datu, lai iegūtu salīdzinoši nelielu rindu skaitu. Un ir nepieciešams sava veida specializēts indekss, jo mēs pamanījām, ka vaicājumā ir pārāk daudz filtrētu rindu.
Apskatīsim notikušo tuvāk. Patiešām, mēs redzam, ka esam nolasījuši gandrīz pusotru gigabaitu datu no failu kešatmiņas vai pat no diska. Un tas nav labi, jo mums ir tikai 142 rindas.
Un, šķiet, mums šeit ir indeksa skenēšana, un tam vajadzēja ātri strādāt, taču, tā kā mēs izfiltrējām pārāk daudz rindu (mums bija tās jāskaita), vaicājums lēnām izdevās.
Un tas notika plānā tāpēc, ka nosacījumi vaicājumā un nosacījumi indeksā daļēji nesakrīt.
Mēģināsim padarīt indeksu precīzāku un redzēt, kā pēc tam mainās vaicājuma izpilde.
Indeksa izveide aizņēma diezgan ilgu laiku, taču tagad pārbaudām vaicājumu un redzam, ka laiks 2,5 minūšu vietā ir tikai 156 milisekundes, kas ir pietiekami labi. Un mēs nolasām tikai 6 megabaitus datu.
Un tagad mēs izmantojam tikai indeksa skenēšanu.
Vēl viens svarīgs stāsts ir tas, ka mēs vēlamies plānu pasniegt kaut kādā saprotamākā veidā. Mēs esam ieviesuši vizualizāciju, izmantojot Flame Graphs.
Šis ir cits pieprasījums, intensīvāks. Un mēs veidojam Flame Graphs saskaņā ar diviem parametriem: tas ir datu apjoms, ko konkrētais mezgls skaitīja plānā un laikā, t.i., mezgla izpildes laiks.
Šeit mēs varam salīdzināt konkrētus mezglus savā starpā. Un būs skaidrs, kurš no tiem aizņem vairāk vai mazāk, ko parasti ir grūti izdarīt citās renderēšanas metodēs.
Protams, visi zina, paskaidrojiet.depesz.com. Laba šīs vizualizācijas iezīme ir tāda, ka mēs saglabājam teksta plānu un arī ievietojam dažus pamata parametrus tabulā, lai mēs varētu kārtot.
Un izstrādātāji, kuri vēl nav iedziļinājušies šajā tēmā, izmanto arī skaidro.depesz.com, jo viņiem ir vieglāk saprast, kuri rādītāji ir svarīgi un kuri nav.
Ir jauna pieeja vizualizācijai - tas ir paskaidrots.dalibo.com. Viņi veic koka vizualizāciju, taču ir ļoti grūti salīdzināt mezglus savā starpā. Šeit jūs varat labi saprast struktūru, tomēr, ja ir liels pieprasījums, jums būs jāritina uz priekšu un atpakaļ, bet arī iespēja.
sadarbību
Un, kā jau teicu, Slack sniedz mums iespēju sadarboties. Piemēram, ja mēs saskaramies ar sarežģītu vaicājumu, kas nav skaidrs, kā optimizēt, mēs varam noskaidrot šo problēmu ar saviem kolēģiem Slack pavedienā.
Mums šķiet, ka ir svarīgi pārbaudīt pilna izmēra datus. Lai to izdarītu, mēs izveidojām rīku Update Database Lab, kas ir pieejams atvērtā avotā. Varat arī izmantot Joe robotu. Jūs varat to ņemt tūlīt un ieviest savā vietā. Tur ir pieejami visi ceļveži.
Svarīgi arī atzīmēt, ka pats risinājums nav revolucionārs, jo ir Delphix, bet tas ir uzņēmuma risinājums. Tas ir pilnībā slēgts, tas ir ļoti dārgs. Mēs īpaši specializējamies Postgres. Tie visi ir atvērtā pirmkoda produkti. Pievienojies mums!
Šeit es beidzu. Paldies!
jautājumi
Sveiki! Paldies par ziņojumu! Ļoti interesanti, īpaši man, jo pirms kāda laika atrisināju apmēram to pašu problēmu. Un tāpēc man ir vairāki jautājumi. Cerams, ka dabūšu vismaz daļu.
Interesanti, kā jūs aprēķināt vietu šai videi? Šī tehnoloģija nozīmē, ka noteiktos apstākļos jūsu kloni var izaugt līdz maksimālajam izmēram. Aptuveni runājot, ja jums ir desmit terabaitu datubāze un 10 kloni, tad ir viegli simulēt situāciju, kad katrs klons sver 10 unikālus datus. Kā jūs aprēķināt šo vietu, tas ir, delta, par kuru jūs runājāt, kurā šie kloni dzīvos?
Labs jautājums. Šeit ir svarīgi izsekot konkrētiem kloniem. Un, ja klonā ir pārāk lielas izmaiņas, tas sāk augt, tad mēs vispirms varam brīdināt lietotāju par to vai nekavējoties apturēt šo klonu, lai mums nebūtu neveiksmes.
Jā, man ir ligzdots jautājums. Tas ir, kā nodrošināt šo moduļu dzīves ciklu? Mums ir šī problēma un viss atsevišķs stāsts. Kā tas notiek?
Katram klonam ir kāds ttl. Būtībā mums ir fiksēts ttl.
Kas, ja nav noslēpums?
1 stunda, t.i., tukšgaita - 1 stunda. Ja to neizmanto, tad dauzām. Bet šeit nav nekāda pārsteiguma, jo mēs varam pacelt klonu sekundēs. Un, ja jums to vajag vēlreiz, lūdzu.
Mani interesē arī tehnoloģiju izvēle, jo, piemēram, mēs vienu vai otru iemeslu dēļ izmantojam vairākas metodes paralēli. Kāpēc ZFS? Kāpēc neizmantojāt LVM? Jūs minējāt, ka bija problēmas ar LVM. Kādas bija problēmas? Manuprāt, visoptimālākais variants ir ar uzglabāšanu, veiktspējas ziņā.
Kāda ir galvenā ZFS problēma? Fakts, ka jums ir jādarbojas vienā un tajā pašā resursdatorā, t.i., visi gadījumi darbosies vienā operētājsistēmā. Un uzglabāšanas gadījumā jūs varat savienot dažādas iekārtas. Un sašaurinājums ir tikai tie bloki, kas atrodas uzglabāšanas sistēmā. Un jautājums par tehnoloģiju izvēli ir interesants. Kāpēc ne LVM?
Konkrēti, mēs varam apspriest LVM tikšanās reizē. Par uzglabāšanu - tas vienkārši ir dārgi. Mēs varam ieviest ZFS sistēmu jebkur. Varat to izvietot savā datorā. Jūs varat vienkārši lejupielādēt repozitoriju un izvietot to. ZFS ir instalēts gandrīz visur, ja mēs runājam par Linux. Tas ir, mēs iegūstam ļoti elastīgu risinājumu. Un ārpus kastes ZFS dod daudz. Varat augšupielādēt tik daudz datu, cik vēlaties, pievienot lielu skaitu disku, ir momentuzņēmumi. Un, kā jau teicu, to ir viegli administrēt. Tas ir, šķiet ļoti patīkami lietot. Viņš ir pārbaudīts, viņam ir daudz gadu. Viņam ir ļoti liela kopiena, kas aug. ZFS ir ļoti uzticams risinājums.
Nikolajs Samohvalovs: Vai drīkstu komentēt tālāk? Mani sauc Nikolajs, mēs strādājam kopā ar Anatoliju. Piekrītu, ka uzglabāšana ir lieliska. Un dažiem mūsu klientiem ir Pure Storage utt.
Anatolijs pareizi atzīmēja, ka mēs koncentrējamies uz modularitāti. Un nākotnē jūs varat ieviest vienu interfeisu - uzņemiet momentuzņēmumu, izveidojiet klonu, iznīciniet klonu. Tas viss ir viegli. Un uzglabāšana ir forša, ja tā ir.
Bet ZFS ir pieejams ikvienam. DelPhix jau ir pietiekami, viņiem ir 300 klientu. No tiem Fortune 100 ir 50 klienti, t.i., tie ir vērsti uz NASA utt. Ir pienācis laiks ikvienam iegūt šo tehnoloģiju. Un tāpēc mums ir atvērtā pirmkoda Core. Mums ir saskarnes daļa, kas nav atvērta pirmkoda. Šī ir platforma, kuru mēs parādīsim. Bet mēs vēlamies, lai tas būtu pieejams ikvienam. Mēs vēlamies veikt revolūciju, lai visi testētāji pārstātu minēt klēpjdatorus. Jāraksta SELECT un uzreiz jāredz, ka tas ir lēns. Pārtrauciet gaidīt, kamēr DBA jums par to pastāstīs. Šeit ir galvenais mērķis. Un es domāju, ka mēs visi pie tā nonāksim. Un mēs izgatavojam šo lietu ikvienam. Tāpēc ZFS, jo tas būs pieejams visur. Paldies kopienai par problēmu risināšanu un atvērtā pirmkoda licenci utt.*
Sveiciens! Paldies par ziņojumu! Mani sauc Maksims. Mēs esam tikuši galā ar tiem pašiem jautājumiem. Viņi izlēma paši. Kā jūs sadalāt resursus starp šiem kloniem? Katrs klons jebkurā brīdī var darīt savu: viens pārbauda vienu, otrs citu, kāds veido indeksu, kādam ir smags darbs. Un, ja jūs joprojām varat dalīt pēc CPU, tad pēc IO, kā jūs sadalāt? Šis ir pirmais jautājums.
Un otrs jautājums ir par tribīņu nelīdzību. Teiksim man te ir ZFS un viss ir forši, bet klientam uz prod nav ZFS, bet gan ext4, piemēram. Kā šajā gadījumā?
Jautājumi ir ļoti labi. Es mazliet pieminēju šo problēmu ar to, ka mēs dalām resursus. Un risinājums ir šāds. Iedomājieties, ka jūs testējat iestudējumu. Var būt arī tāda situācija vienlaikus, ka kāds dod vienu slodzi, kāds cits. Un rezultātā jūs redzat nesaprotamus rādītājus. Pat tāda pati problēma var būt ar prod. Kad gribi pārbaudīt kādu pieprasījumu un redzi, ka ar to ir kaut kāda problēma - darbojas lēni, tad patiesībā problēma nebija pieprasījumā, bet gan tajā, ka ir kaut kāda paralēlā slodze.
Un tāpēc šeit ir svarīgi koncentrēties uz to, kāds būs plāns, kādus soļus mēs veiksim plānā un cik daudz datu mēs šim nolūkam apkoposim. Tas, ka, piemēram, mūsu diski tiks ar kaut ko ielādēti, tas īpaši ietekmēs laiku. Taču mēs varam novērtēt, cik ielādēts šis pieprasījums ir pēc datu apjoma. Tas nav tik svarīgi, lai tajā pašā laikā notiktu kāda veida izpilde.
Man ir divi jautājumi. Šīs ir ļoti foršas lietas. Vai ir bijuši gadījumi, kad ražošanas dati ir kritiski, piemēram, kredītkaršu numuri? Vai kaut kas jau ir gatavs vai tas ir atsevišķs uzdevums? Un otrs jautājums - vai MySQL ir kaut kas līdzīgs šim?
Par datiem. Mēs veiksim apmulsināšanu, līdz to darīsim. Bet, ja izvietojat tieši Džo, ja nedodat piekļuvi izstrādātājiem, tad nav piekļuves datiem. Kāpēc? Jo Džo nerāda datus. Tas parāda tikai metriku, plānus un viss. Tas tika darīts ar nolūku, jo tā ir viena no mūsu klienta prasībām. Viņi vēlējās optimizēt, nedodot ikvienam piekļuvi.
Par MySQL. Šo sistēmu var izmantot visam, kas saglabā stāvokli diskā. Un tā kā mēs veicam Postgres, mēs tagad vispirms veicam visu Postgres automatizāciju. Mēs vēlamies automatizēt datu iegūšanu no dublējuma. Mēs pareizi konfigurējam Postgres. Mēs zinām, kā saskaņot plānus utt.
Bet, tā kā sistēma ir paplašināma, to var izmantot arī MySQL. Un ir tādi piemēri. Yandex ir līdzīga lieta, taču viņi to nekur nepublicē. Viņi to izmanto vietnē Yandex.Metrica. Un ir tikai stāsts par MySQL. Bet tehnoloģijas ir tās pašas, ZFS.
Paldies par ziņojumu! Man arī ir pāris jautājumi. Jūs minējāt, ka klonēšanu var izmantot analītikai, piemēram, lai tur izveidotu papildu indeksus. Vai varat pastāstīt nedaudz vairāk par to, kā tas darbojas?
Un uzreiz uzdošu otro jautājumu par tribīņu līdzību, plānu līdzību. Plāns ir atkarīgs arī no Postgres apkopotās statistikas. Kā jūs atrisināt šo problēmu?
Pēc analītikas datiem, konkrētu gadījumu nav, jo vēl neesam izmantojuši, bet tāda iespēja ir. Ja mēs runājam par indeksiem, tad iedomājieties, ka vaicājums dzenā tabulu ar simtiem miljonu ierakstu un kolonnu, kas parasti netiek indeksēta prod. Un mēs tur vēlamies aprēķināt dažus datus. Ja šis pieprasījums tiek nosūtīts uz prod, tad pastāv iespēja, ka tas būs vienkārši uz prod, jo tur pieprasījums tiks apstrādāts vienu minūti.
Labi, uztaisīsim plānu klonu, kuru nav briesmīgi apstāties uz dažām minūtēm. Un, lai būtu ērtāk lasīt analīzi, mēs pievienosim indeksus tām kolonnām, kurās mūs interesē dati.
Indekss tiks izveidots katru reizi?
Varat izveidot tā, lai mēs pieskartos datiem, izveidotu momentuzņēmumus, tad mēs atgūsim no šī momentuzņēmuma un virzīsim jaunus pieprasījumus. Tas ir, jūs varat izveidot tā, lai jūs varētu audzēt jaunus klonus ar jau piestiprinātiem indeksiem.
Kas attiecas uz jautājumu par statistiku, ja mēs atjaunojam no dublējuma, ja veicam replikāciju, tad mūsu statistika būs tieši tāda pati. Tā kā mums ir visa fizisko datu struktūra, tas ir, mēs ienesīsim datus tādus, kādi tie ir, arī ar visiem statistikas rādītājiem.
Šeit ir vēl viena problēma. Ja izmanto mākoņa risinājumu, tad tur ir pieejamas tikai loģiskās izgāztuves, jo Google, Amazon neļauj ņemt fizisku kopiju. Būs problēma.
Paldies par ziņojumu. Šeit bija divi labi jautājumi par MySQL un resursu koplietošanu. Bet patiesībā tas viss ir saistīts ar faktu, ka šī nav konkrētas DBVS tēma, bet gan failu sistēma kopumā. Un attiecīgi arī resursu koplietošanas jautājumi būtu jārisina no turienes, nevis beigās, ka tas ir Postgres, bet gan failu sistēmā, piemēram, serverī.
Mans jautājums ir nedaudz atšķirīgs. Tas ir tuvāk daudzslāņu datu bāzei, kur ir vairāki slāņi. Piemēram, mēs uzstādām desmit terabaitu attēla atjauninājumu, mēs replicējam. Un mēs īpaši izmantojam šo risinājumu datu bāzēm. Notiek replikācija, dati tiek atjaunināti. Šeit paralēli strādā 100 darbinieki, kuri nepārtraukti palaiž šos dažādos kadrus. Ko darīt? Kā pārliecināties, ka nav konflikta, vai viņi to palaiž, un pēc tam mainījās failu sistēma, un visi šie attēli aizgāja?
Viņi nebrauks, jo tā darbojas ZFS. Mēs varam atsevišķi vienā pavedienā saglabāt failu sistēmas izmaiņas, kas rodas replikācijas dēļ. Un saglabājiet klonus, ko izstrādātāji izmanto vecākām datu versijām. Un tas mums darbojas, ar šo viss ir kārtībā.
Izrādās, ka atjauninājums notiks kā papildu slānis, un visas jaunās bildes jau iet, pamatojoties uz šo slāni, vai ne?
No iepriekšējiem slāņiem, kas bija no iepriekšējām replikācijām.
Iepriekšējie slāņi nokritīs, bet tie attieksies uz veco slāni, un vai tie uzņems jaunus attēlus no pēdējā slāņa, kas tika saņemts atjauninājumā?
Vispār jā.
Tad rezultātā mums būs līdz fig slāņu. Un laika gaitā tie būs jāsaspiež?
Jā, viss ir pareizi. Ir kāds logs. Mēs saglabājam iknedēļas momentuzņēmumus. Tas ir atkarīgs no tā, kāds resurss jums ir. Ja jums ir iespēja saglabāt daudz datu, varat saglabāt momentuzņēmumus ilgu laiku. Viņi nepazudīs paši no sevis. Datu bojājumu nebūs. Ja momentuzņēmumi ir novecojuši, kā mums šķiet, t.i., tas ir atkarīgs no uzņēmuma politikas, tad varam tos vienkārši izdzēst un atbrīvot vietu.
Labdien, paldies par ziņojumu! Jautājums par Džo. Jūs teicāt, ka klients nevēlējās visiem dot piekļuvi datiem. Stingri sakot, ja personai ir Explain Analyze rezultāts, viņš var aplūkot datus.
Tas ir tā. Piemēram, mēs varam rakstīt: "SELECT FROM WHERE e-pasts = uz to". Tas ir, mēs neredzēsim pašus datus, bet mēs varam redzēt dažas netiešas pazīmes. Tas ir jāsaprot. Bet, no otras puses, tas viss ir. Mums ir žurnāla audits, mēs kontrolējam citus kolēģus, kuri arī redz, ko izstrādātāji dara. Un, ja kāds mēģina to izdarīt, tad drošības dienests nāks pie viņa un strādās pie šī jautājuma.
Labdien Paldies par ziņojumu! Man ir īss jautājums. Ja uzņēmums neizmanto Slack, vai tagad tam ir kāds saistījums, vai arī izstrādātājiem ir iespējams izvietot gadījumus, lai savienotu testa lietojumprogrammu ar datu bāzēm?
Tagad ir saite uz Slack, t.i., nav cita kurjera, bet es ļoti vēlos sniegt atbalstu arī citiem kurjeriem. Ko tu vari izdarīt? Varat izvietot DB Lab bez Džo, doties ar REST API vai mūsu platformas palīdzību un izveidot klonus un izveidot savienojumu ar PSQL. Taču to var izdarīt, ja esat gatavs nodrošināt izstrādātājiem piekļuvi datiem, jo ekrāna vairs nebūs.
Man šis slānis nav vajadzīgs, bet man vajag šādu iespēju.
Tad jā, to var izdarīt.
Avots: www.habr.com