Kāds bija lielākais datu bāzes projekts, kuru jums nācās īstenot vai uzturēt?
Golang
Kādās intervijas procesa posmos dažādās organizācijās bieži uzdod šo jautājumu?
Kā tiek veikti pieprasījumi uz PostgreSQL datu bāzi?
Vai jūs varat izskaidrot gRPC darbības principu un tā galvenās iezīmes?
Cik rakstīšanas pieprasījumu sekundē tika saņemti no datiem?
Cik daudz instanču/konteineru darbāja pakalpojums?
Kura slāņa ietilpst klienti ārējiem pakalpojumiem un sistēmām?
Kāda ir jūsu pieredze ar daudzprocesu un paralēliem aprēķiniem balstītu lietojumprogrammu izstrādi?
Vai vari orientēties hostos? Cik hostu, cik konteineru tiek palaists?
Kā notiek datu pieslēgšana un attēlošana Grafanā?
Kāds bija ilgākais projekts, ar kuru jūs strādājāt?
Kā vizuāli vai algoritmiski noteikt, ka elements ir unikāls Map datu struktūrā?
""" Kinoteātra vietas ir izvietotas vienā rindā. Jauns apmeklētājs, kurš tikko ieradies, izvēlas vietu, lai sēdētu pēc iespējas tālāk no citiem apmeklētājiem rindā. Tas ir, attālums no šīs vietas, līdz tuvākajam apmeklētājam, ir jābūt maksimālam. Tiek garantēts, ka vienmēr ir brīvas vietas un jau ir sēdējis vismaz viens apmeklētājs. Uzrakstiet funkciju, kas, dodot vietu rindu (masīvu no nullēm un vieniniekiem), atgriezīs attālumu (skaitu starp sēdvietām) no izvēlētās vietas līdz tuvākajam apmeklētājam. [1, 0, 0, 0, 1] -> 2 [1, 0, 1, 0, 0, 1, 0, 0, 1] -> 2 [1, 0, 1, 0] -> 1 """
/* Mums nepieciešams pārsūtīt datus no noteikta avota noteiktam patērētājam. Šajā procesā avots sniedz datus mazās partijās (~ desmitiem ierakstu), bet patērētājs efektīvāk strādā ar lielākiem batčiem. Reāls piemērs - datu piegāde no Kafka tipa rindām uz Clickhouse datubāzi. Avots: - Nosacīti bezgalīgs. - Avots nekad neatgriezīs vairāk par MaxItems ierakstiem vienā Next izsaukumā. - Vienā "sesijā" (viena Pipe funkcijas izsaukuma laikā) avots katru reizi atgriež jaunus datus. - Tomēr, pēc pārstartēšanas, avots sāk no iepriekšējās "apstiprinātās" pozīcijas, kas norādīta ar cookie. Tādēļ, *katra* cookie vērtība, ko atgrieza Next, pēc datu saglabāšanas saņēmējā, jāapstiprina ar Commit, un tas jāizdara stingri tādā pašā secībā, kā tie tika atgriezti. Saņēmējs: - Nevar apstrādāt vairāk par MaxItems vienlaikus. Pamatlīmenis: Jāimplementē funkcija func Pipe(p Producer, c Consumer) error, kura lasa datus no avota, tos grupē buferī, kura lielums nepārsniedz MaxItems, un saglabā saņēmējā, pēc tam apstiprina progresu avotā. */ const MaxItems = 9999 type Producer interface { // Next atgriež: // - datu partiju // - cookie apstiprināšanai // - kļūdu Next() (items []any, cookie int, err error) // Commit apzīmē, ka datu partija ir apstrādāta Commit(cookie int) error } type Consumer interface { Process(items []any) error } func Pipe(p Producer, c Consumer) error { var buf []any var cookies []int for { items, cookie, err := p.Next() if err != nil { return err } buf = append(buf, items...) cookies = append(cookies, cookie) if len(buf) >= MaxItems { if err := c.Process(buf); err != nil { return err } for _, c := range cookies { if err := p.Commit(c); err != nil { return err } } buf = buf[:0] cookies = nil } } if len(buf) > 0 { if err := c.Process(buf); err != nil { return err } for _, c := range cookies { if err := p.Commit(c); err != nil { return err } } } return nil }
Kā organizēt arhitektūru pieprasījumam, kas veic biznesa loģiku, izsauc ārējo pakalpojumu (Google) un saglabā rezultātu datu bāzē? Aprakstiet slāņos no augšas uz leju.
Kādam principam jāseko, samazinot vai palielinot have skaitītāju?
Kādus efektivitātes rādītājus izmantojāt, novērtējot savu darbu pēdējā projektā?
Vai jūs šobrīd strādājat vai nē, un kādā formātā: birojs, hibrīds, attālināti?
func countSubs(s string) int { result := 0 left := 0 hm := make(map[rune]int) n := len(s) for right := 0; right < n; right++ { hm[s[right]]++ for hm[s[right]] > 1 { hm[s[left]]-- if hm[s[left]] == 0 { delete(hm, s[left]) } left++ } result += (right - left + 1) } return result }
/* Mums nepieciešams nodot datus no noteikta avota noteiktam patērētājam. Šajā gadījumā avots sniedz mazākas partijas (~ desmitiem ierakstu), bet patērētājs efektīvāk strādā ar lielākām partijām (~ tūkstošiem ierakstu). Reāls piemērs - datu nodošana no Kafka tipa rindām uz Clickhouse datu bāzi. Avots: - Puslīdz bezgalīgs. - Avots nekad neatgriež vairāk par MaxItems ierakstiem vienā Next izsaukumā. - Vienā "sesijā" (viena Pipe funkcijas izsaukuma laikā) avots katru reizi atgriež jaunus datus. - Tomēr, pārstartējot, avots atsāks no iepriekšējās "apstiprinātās" pozīcijas, kas norādīta ar cookie. Tādēļ katra vērtība, ko atgrieza Next izsaukums, pēc datu saglabāšanas saņēmējam, ir jāapstiprina ar Commit izsaukumu, un tas jāveic tieši tajā pašā secībā, kurā tie tika atgriezti ar Next. Saņēmējs: - Nevar apstrādāt vairāk par MaxItems vienlaikus. Galvenais līmenis: Jāievieš funkcija func Pipe(p Producer, c Consumer) error, kura lasa datus no avota, tos grupē buferī, kura izmērs nav lielāks par MaxItems, un saglabā saņēmējā, tad atjauno progresu avotā. Grūtības: Next, Process un Commit metodes ir saistītas ar tīkla izsaukumiem un var darboties diezgan ilgi. Lai paātrinātu datu pārraidi, nepieciešams paralēli veikt lasīšanu, ierakstīšanu un apstiprināšanu. Tādējādi, izsaucot Process vai Commit, turpinās lasīšana no avota un jauna bufera veidošana. */