[Khaine]

#programowanie #bazydanych #webdev #csharp

Stoimy z chłopakami przed pewnym dylematem i brakuje nam wiedzy aby być w stanie go jakoś rozstrzygnąć. Obecnie sprawa wygląda tak, że jest sobie baza MSSQL która ma od pyty procedur składowanych w których to dzieje się cała magia. Danych jest bardzo dużo i przychodzą non stop, backend jest szczątkowy - właściwie tylko przewala gotowce z bazy do frontu. Mówimy o potencjalnie setkach gigabajtów danych, które to mogą być niekiedy pobierane w ilości wielu gb na raz celem zrobienia np. agregacji do wykresów. Obecnie robi to baza w wewnętrznej procce i backend dostaje tylko mały zagregowany już odpowiednio pakiet danych, więc działa to jako tako.

No ale procedury składowane śmierdzą, bo uwiązują j---a do konkretnego silnika baz danych a w dzisiejszych czasach można się zastanawiać czy baza na pewno szybciej przeliczy. NoSQL nie ma procek składowanych, jest dosyć szybkie i masz podejście "code-first" w gratisie bez żadnych dziwnych tańców, aczkolwiek sam model danych to jeden wielki b----l i w pewnym momencie jak to spuchnie, to może się zrobić chaos nad którym normalnie panowałyby relacje.

Macie jakieś doświadczenia z tym związane aby mieć porównanie?

[scriptkitty]

@Khaine: Serio procedury uwiązują do konkretnego systemu? Przecież to jak wywołania zdalne - podajesz parametry a dostajesz wiersze z powrotem. Przecież każda poważna baza relacyjna to potrafi zaimplementować. Nie trzeba zmieniać backendu.

[Khaine]

Serio procedury uwiązują do konkretnego systemu?

@scriptkitty: Tak, składnia języka rozszerzeń. Jeśli piszesz procki w notacji MSSQL i nagle stwierdzisz, że chcesz PostgreSQL, to musisz przepisywać wszystko od nowa (a jest tego od ch...). No chyba, że PostgreSQL umie zrozumieć notację MSSQL i przetłumaczyć to na swoją, nie wiem bo nie mam tutaj wiedzy.

[scriptkitty]

@Khaine: No tak, po stronie bazy są wymagane zmiany. Ja pisałem o zmianach na backendzie. Ale jeśli nie wystarczy wam czysty standardowy SQL to zawsze gdzieś trzeba będzie zrobić zmiany przy wymianie bazy czy na SQL czy noSQL.

[b.....a]

@Khaine: baza to ma byc storage tylko z jakimis podstawowymi SP odpowiedzialnymi za typowy CRUD. Jak potrzebujesz cos wiecej to z tymi danymi zrobic to zazwyczaj rozwazasz np, indexing machines albo enterprise search engines np. Solr.

[Kaczus2B]

@Khaine: procedury skladowane moze i przywiazuja do jakiejs bazy, ale maja podstwaowe rzeczy, tzn, to one dbaja o spojnosc danych, nie ma problemu, ze ktos uruchomi niewlasciwa wersje programu, po wtore jak sam zauwazyles dzial to szybko, po trzecie, nie widziałem, żeby klienci przeskakiwali z bazy na bazę. Co najwyżej moze kosztem być utrzymanie 2 kodów dla 2-3 baz danych. Inne podejście miałbm do jakiś drobnych kodów, gdzie rzeczywiście możńa

[Khaine]

Ja pisałem o zmianach na backendzie.

@scriptkitty: Nie no, dlatego zaproponowałem jako jedna z opcji liczenie na backendzie. Jak robisz łyse selecty na bazie, to masz to z grubsza w dupie jaki silnik tam siedzi. Natomiast musisz wtedy w samym backendzie przygotować się na łyknięcie jednorazowo np. 5 gb danych do zmielenia.

Obecnie jest tak, że są wydzielone providery w osobnej dllce, więc jedyne co musisz zrobić to podmienić mu

[scriptkitty]

@Khaine: Jeśli stać was żeby tyle danych mielić na backendzie to spoko ¯\_(ツ)_/¯

[scriptkitty]

@Khaine: Inną opcją jest używanie jednej bazy znormalizowanej, a potem co jakiś czas generowanie innego modelu w innej bazie - jeśli dane nie muszą być takie świeże lub mogą być odpytywane już w zoptymalizowanej do zapytań formie.

[Khaine]

@scriptkitty: No moje pytanie odnosi się do tego co tak naprawdę szybciej zadziała xD Moje doświadczenie mówi, że nic szybciej niż baza danych nie jest w stanie tych danych przemielić, szczególnie po tym jak sobie zoptymalizuje wszystkie plany, ale może coś się zmieniło i opłaca się chapać to w backendy w 2019, i tam rozbijać to ręcznie na wątki przetwarzając równolegle.

Inną opcją jest używanie jednej bazy znormalizowanej, a potem co jakiś czas generowanie innego modelu w innej bazie

No mniej więcej podobnie jest teraz

[T.....n]

@Khaine: baza danych do transakcji i osobna hurtownia do raportów i BI

[scriptkitty]

po trzecie, nie widziałem, żeby klienci przeskakiwali z bazy na bazę.

@Kaczus2B: W projekcie gdzie mamy kilkadziesiąt mikroserwisów przeskakiwanie z bazy na bazę to normalka ( ͡° ͜ʖ ͡°)

[scriptkitty]

Moje doświadczenie mówi, że nic szybciej niż baza danych nie jest w stanie tych danych przemielić, szczególnie po tym jak sobie zoptymalizuje wszystkie plany,

@Khaine: Ja bym też szedł w tą opcję domyślnie

[Kaczus2B]

@scriptkitty: ale mikroserwis, to trochę co innego niż rozbudowany system z dużą ilością danych i dużym obciążeniem danymi, które trzeba analizować. Dlatego rozdzielam małe rzeczy od dużych, które jednak lepiej by o spójność danych oraz działanie dbała sama baza.

[scriptkitty]

@Kaczus2B: No niby tak ale ja osobiście nawet w małych bazach domyślnie wybieram postgresa dla spójności lokalnej

[Khaine]

@Kaczus2B: Małe gówna (takie bardziej w doktrynie "napisz i zapomnij" a nie "napisz i utrzymuj przez 10 lat") to bym robił na NoSQL, bo szybciej by się to pisało. Code-first z definicji, w bazę wrzuca się jak do wiadra bez żadnych zapytań i w sumie tak samo się czyta. No ale mówimy o czymś, co z biegiem czasu potężnie puchnie.

[ksiak]

@Khaine: to może pora rozważyć migracje z MSSQL w stronę czegoś innego/tańszego co nie będzie was tak wiązało. Analiza tak dużych danych w backendzie to na pewno nie jest dobry pomysł. Musisz doliczyć wtedy czas potrzebny. A przesłanie tego z bazy. Na bazie zrobisz to to dużo szybciej. Może nie zawsze to jest super wygodne ale sprawdza się.

[Khaine]

to może pora rozważyć migracje z MSSQL w stronę czegoś innego/tańszego co nie będzie was tak wiązało.

@ksiak: No pora. Tak jak mówiłem. MSSQL może zostać w starym systemie-molochu, ale robiąc nowy PostgreSQL albo NoSQL aby taka sytuacja się nie powtórzyła.

[ksiak]

@Khaine: w NoSQL bym się chyba nie pakował zwłaszcza jeżeli macie sporo logiki biznesowej na bazie a dane są głównie tabelaryczne i relacyjne. To będzie strzał w kolano po dłuższym czasie.

[Hauleth]

@Khaine: a co konkretnie chcesz robić z tymi danymi i jakie są to dane? Bo to może mocno wpłynąć na to co warto użyć.

@ksiak: nie myl, bo w SQLu wszystkie dane są relacyjne (relacja to inaczej mówiąc tabela). To o czym mówisz to są JOINy, które z "relacyjnością" w relacyjnych DB nie mają praktycznie nic wspólnego.

[Khaine]

a co konkretnie chcesz robić z tymi danymi i jakie są to dane? Bo to może mocno wpłynąć na to co warto użyć.

@Hauleth: Przede wszystkim liczbowe. Wykresy, tabele itd. Ale jak ktoś chce zobaczyć dane z ostatnich 2 lat to zaboli, bo to może być grube kilka gb, które trzeba w pełni pobrać od razu aby zrobić agregację (nie można sobie fetchować porcjami jak w tabeli wtedy).