Jak bardzo backendowiec powinnien ogarniać baze danych?

Cześć,

Tak jak w temacie. Pisze w .NET do tego dość często coś tam muszę napisać we froncie. O ile proste zapytania (joiny, uniony etc) oraz podstawowe wiedza z zakresu baz danych (np. paginacja, indeksy etc) jest mi znana to zauważyłem, że na takiego fullstack'a czy na innych rozmowach ten temat jest mocno poruszany i to dogłębnie. Ile tak na prawdę taki backendowiec powinien umieć w bazach danych? Czy to nie powinno być tak, że jak naprawdę firma ma sporo danych w milionach,milardach rekordów to nie powinna mieć od tego specjalistę, który wie jak takie zapytanie napisać czy podzielić odpowiednio bazę danych? Taką ilość danych zazwyczaj mają duże firmy i powinny mieć kasę na takiego specjalistę. Pytanie do backednowców jak u was to wygląda?

To zależy. Od tak wielu czynników że kazda rozmowa o pracę bo domyślam się że to masz na myśli

na takiego fullstack'a czy na innych rozmowach

definiuje te wymagania sama.

Jeśli firma jest poważna to nie da osobie która nie ma o tym pojęcia dostępu do bazy. Jeśli jest niepoważna to nie będzie z tym problemu (i potem są różne fakapy o których słyszymy tu i tam).

Może podam przykład z pracy. W PG coś stało się z trzymaniem sekwencji w cacheu. Przy każdym następnym Insercie z sekwencją dodawał +5 zamiast +1 do ID. Przypisano mi to zadanie żebym sprawdził o co chodzi. Nie wiem czy to normalne żeby .NET'owiec się czymś takim zajmował. Szczerze mówiąc nie przepadam za tematem baz danych. Nie wiem czy się też przejmować tym, że moja wiedza z tego tematu nie jest wystarczająco duża.

Szadek95 napisał(a):

Może podam przykład z pracy. W PG coś stało się z trzymaniem sekwencji w cacheu. Przy każdym następnym Insercie z sekwencją dodawał +5 zamiast +1 do ID. Przypisano mi to zadanie żebym sprawdził o co chodzi. Nie wiem czy to normalne żeby .NET'owiec się czymś takim zajmował. Szczerze mówiąc nie przepadam za tematem baz danych. Nie wiem czy się też przejmować tym, że moja wiedza z tego tematu nie jest wystarczająco duża.

Tak, to jak najbardziej normalne.

Nie mam pojęcia jak Ty chcesz pisać backend bez znajomości baz oO

Od pisania zapytań zawsze był programista. Nie spotkałem się jeszcze, żeby od tego był dedykowany spec od baz potrzebny. Tak samo z debugowaniem, itp.

Powinien ogarniać. Nie wiem jak ty chcesz tworzyć wydajny backend bez indeksów, widoków, cachowania, relacji i tak dalej.

Każdy programista w zespole powinien ogarniać technologie na tyle żeby móc samemu dodać feature. Jeśli nie, to będą silosy.

Skill wszystkich w zespole powinien być dopasowany do złożoności projektu. Dlatego nie ma jednoznacznej odpowiedzi.

Jeśli jedyne co robicie to wrzucacie nowe rekordy i left joinujecie z tabelą faktów, to taki fs powinien umieć dodawać rekordy i left joinować.

Jeśli robicie niebagatelne agregacje, używacie funkcji okienkowych, zapytania rekruencyjne itp, to fs również powinien to umieć.

Szadek95 napisał(a):

Ile tak na prawdę taki backendowiec powinien umieć w bazach danych?

Tyle, ile potrzeba w jego zespole. W jednych zespołach wystarczy umiejętność odpytania bazy o dane w celach diagnostycznych, a w innych zespołach trzeba umieć konfigurować, backupować, i czyścić log audytu.

Czy to nie powinno być tak, że jak naprawdę firma ma sporo danych w milionach,milardach rekordów to nie powinna mieć od tego specjalistę, który wie jak takie zapytanie napisać czy podzielić odpowiednio bazę danych? Taką ilość danych zazwyczaj mają duże firmy i powinny mieć kasę na takiego specjalistę.

To raczej powinno zależeć od struktury danych niż od ich ilości.

Pytanie do backednowców jak u was to wygląda?

No u mnie jest prosto, bo bazę danych tworzę per serwis, a mój zespół akurat nie ma miliardów rekordów.
Co prawda mieliśmy kiedyś jeden problem wydajnościowy, bo użyliśmy biblioteki, której autor ewidentnie nie umiał dobierać partition keye, skutkiem czego apka co jakiś czas umierała, ale rozwiązaliśmy ten problem ubijając projekt.

anckor napisał(a):

Nie wiem jak ty chcesz tworzyć wydajny backend bez indeksów, widoków, cachowania, relacji i tak dalej.

To akurat bardzo prosto - zdecydowanie łatwiej o wydajny backend bez tych wszystkich patologii.

Backendowiec używający bazy musi umieć bazy. Stopien wiedzy zależy od tego jakie są wymagania.

Proces pisania kodu działającego z bazą danych wygląda tak:

• muszę coś zrobić
• próbuję to zrobić i testuję
• coś nie działa
• wracam do punktu 2 i poprawiam to bazując na wynikach błędnej próby

Programista musi umieć bazy, bo taki proces to nie jest zaklepię i będzie działać, tylko potrzeba wielu prób. Tej pracy nie przerzucisz do innej osoby, bo koszt przekazania wiedzy i koszt feedback loopu jest wielokrotnie większy, gdy robią to dwie osoby sekwencyjnie jedna po drugiej

Dobrym kontrprzykładem jest wszelaka praca devopsowa. Tutaj też jest fajnie jak dev wszystko umie, ale jak masz osobę dedykowaną, której powiesz postaw kubernetesa w AWS/bazę danych/inne usługi tak żeby działało, tu masz docker-compose, który robi to co ma być na produkcji i wszystko działa lokalnie to takie zadanie jest dużo prostsze do zrobienia przy minimalnej liczbie pytań zwrotnych. To właśnie od ilości tych zwrotnych pytań wynika to, czy daną pracę można przerzucić na inną osobę, czy jest to może marnowanie zasobów ludzkich.

Pamiętajmy że istnieje także zjawisko jak managed database https://www.google.com/search?q=managed+databases+digitalocean gdzie właśnie płacisz za to że możesz zatrudnić tańszego/gorszego backendowca który się nie musi zajmować głupotami.

marian pazdzioch napisał(a):

Pamiętajmy że istnieje także zjawisko jak managed database https://www.google.com/search?q=managed+databases+digitalocean gdzie właśnie płacisz za to że możesz zatrudnić tańszego/gorszego backendowca który się nie musi zajmować głupotami.

Chętnie dowiem się co to zmienia z perspektywy developera. Jeśli już komuś to ujmuje pracy to adminom, którzy nie muszą utrzymywać infry on-prem.

Na managed database da się odpalić tak samo debilne query jak na on-prem.

Baza danych dla backendowca to jak CSS dla frontendowca, trzeba wiedzieć czego się używa i jakie to daje gwarancje.
Obecnie bardzo trudno utrzymać wiedzę ze względu na ogrom technologii od Cassandry i Solr'a poprzez Redisy i MongoDB aż po klasyczne SQLe. Dodatkowo mamy quasi bazy danych takie jak S3.

Wracają co pytania jeżeli pracujesz tylko i wyłącznie z SQLem to powinieneś go znać od podszewki, na szczęście "klasyczne" bazy danych są bardzo proste, jedna książka o zaawansowanym SQL oraz jedna o optymalizacji danej bazy danych i wyjaśniająca jak to jest mniej więcej zaimplementowane pod spodem powinny dostarczyć 99% przydatnej wiedzy.

Polecam jednak wyjść poza to co znajome i poznać choć jedną nieSQLową bazę danych żeby zobaczyć jak się trzyma dane w wersji distributed, polecam Cassandrę ze względu na ciekawy design (wystarczy przeczytać whitepaper https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf). Centralny pomysł to trzymanie danych w pamięci, a żeby się nie zepsuło jak padnie jedna maszyna (node) to trzyma się na K maszynach z N dostępnych w klastrze. Co jakiś czas przerzuca się dane na dysk. Odpytuje się tak że pyta się pewną liczbę maszyn i wynik zwracany przez większość przyjmuje się jako aktualny stan danych. To tak w mega telegraficznym skrócie.

Generalnie DB to bardzo wdzięczny temat, i mnie osobiście jarają takie rzeczy jak implementacja transaction logów. Poza tym baza SQLowa to BTrzewa + zarządzanie page'ingiem (wczytywanie stron danych do pamięci) oraz R/W locking na BTree. Transaction log jest nieco trudniejszy do zaimplementowania ale też nie jest to rocket science. Jak się już wie jak to działa pod spodem to łatwo potem zrozumieć dlaczego dane zapytanie zamula itp.

Wydaje mi się, że to zależy od danej firmy. Tak samo jak np. kierowca - w jednej firmie bierze auto i jedzie, a o godzinie 15 odstawia na bazę i nic więcej go nie interesuje. W innej sam musi pilnować przeglądów, załatwiać mechanika gdy coś puka w zawieszeniu itp. Zarówno jedno, jak i drugie rozwiązanie jest ok, zależy od sytuacji w firmie, liczby osób tam pracujących i innych czynników.

Tak samo z bazami - w czymś małym bardziej jest potrzebny człowiek orkiestra, za to w dużych firmach z dużymi projektami mają specjalistów od baz i nikt nie będzie zlecał fullstakowi sprawdzania, czemu autoincrement nie działa poprawnie. Weźmie się za to ktoś, kto ma zapewnić obsługę bazy. Ty, jako programista masz mieć działający mechanizm bazy, do którego walisz zapytania i Ciebie w ogóle nie powinno interesować nic z zakresu technicznych kwestii jej utrzymania czy naprawiania.

Oczywiście - czymś innym jest debugowanie/profilowanie i dostrajanie zapytań - to fajnie, jakbyś umiał ogarnąć.

Szadek95 napisał(a):

ile proste zapytania (joiny, uniony etc) oraz podstawowe wiedza z zakresu baz danych (np. paginacja, indeksy etc) jest mi znana to zauważyłem, że na takiego fullstack'a czy na innych rozmowach ten temat jest mocno poruszany i to dogłębnie. Ile tak na prawdę taki backendowiec powinien umieć w bazach danych?

Wystarczy wiedza że współczesne bazy danych są na tyle skomplikowane pod spodem (współbieżność, replikacja, koherencja itp, itede) i na tyle proste w użyciu z zewnątrz że może dzięki temu traktować je jako Single Source of Truth przy projektowaniu architektury mikroserwisowej (co w praktyce załatwia 80% problemów). Nie wiem jak przy monolitach bo tam żeby nie było za prosto wymyślili dodatkowo pier**lion warstw pośrednich typu ORMy, DTOsy które mają własne problemy.

Co najmniej na tyle, żeby uznawać projektowanie IDków będących random UUID za herezję.

Pozdrawiam.

qbns napisał(a):

Co najmniej na tyle, żeby uznawać projektowanie IDków będących random UUID za herezję.

A co jest w tym heretyckiego?

A tak liczyłem, że sprowokuję kontrowersje

W skrócie - wg mnie najważniejsza jest wiedza na temat tego, na jakich strukturach danych zbudowane są silniki bazodanowe (czyt. jakiego rodzaju drzewa i w jakiej postaci zazwyczaj liście tych drzew są trzymane na dysku i w pamięci) oraz jakie są złożoności obliczeniowe poszczególnych operacji; jak minimalizować liczbę rotacji, jak działają mechanizmy "czyszczenia" etc.

Oczywiście, dla małych baz danych nie ma to pewnie większego znaczenia ale przy większych bazach, projektowanie w taki sposób, żeby chociaż wg teorii działało optymalnie, daje ogromne zyski - mniej brudnych stron, mniejsze katowanie dysku, optymalne wykorzystanie cache bazy, co skutkuje dużo mniejszym męczeniem się CPU z czekaniem na IO - a tym samym, wielokrotnie wyższą tolerancję na częstotliwość zapisów i odczytów a także ich czasy.

Co do rzeczy takich jak optymalizacja configu bazy, configu "czyszczenia", replikacji, cache etc - to są taski, które zostawiłbym DBA (chociaż w korpo często DBA nie interesuje się za bardzo, więc też czasem trzeba pilnować:D)

PS. jeszcze co do cache: nawet w epoce szybkich dysków odczyt z pamięci VS z dysku to przepaść więc zadbanie by jak najwięcej rekordów/wpisów w indeksach zmieściło się w RAM jest bardzo ważne (chyba, że robisz soft, który musi udawać, że coś długo mieli żeby się wydawał profesjonalny)

Jak bardzo backendowiec powinien ogarniać bazę danych? Są dwie szkoły: albo tak bardzo, jak się da, albo co najmniej tak bardzo, jak potrzeba.

Jeśli twój zespół jedynie czyta i zapisuje dane do bazy danych - i poza tym się nie tyka - to jedyne co ci wystarczy do pracy to znajomość skonfigurowania datasource'u i przemapowania tego na struktury. Jeśli twój zespół zajmuje się supportem produkcji to musisz ogarniać jak pisać SELECTy, które nie zabiją produkcji. Jeśli twój zespół tworzy nowe tabele to już znajomość projektowania tabel się przyda. Jeśli twój zespół robi optymalizację przez procedury bazodanowe - to musisz nawet i te pokraczne języki ogarniać.

anckor napisał(a):

Nie wiem jak ty chcesz tworzyć wydajny backend bez indeksów, widoków, cachowania, relacji i tak dalej.

To akurat bardzo prosto - zdecydowanie łatwiej o wydajny backend bez tych wszystkich patologii.

To często prawda, chociaż zostawiłbym te indeksy :D Bardzo ważne jest na pewno dobre przemyślenie i umiarkowanie w tworzeniu indeksów, bo każdy indeks, to większa męczarnia przy zapisach/replikacji + brudzenie cache.

Relacje też często są dużo wydajniejszym rozwiązaniem (np. gdy dają nam możliwość updatowania 1 rekordu w tabeli obok zamiast 100000 rekordów w "szerokiej" tabeli/kolekcji) ale można je robić bez Foreign Key constraintów żeby mieć jedno zmartwienie mniej.

Powinieneś umieć wszystko, żeby zdać rekrutację. Potrzebnych rzeczy nauczysz się w pierwszy tydzień.