Pytanie odnośnie baz danych typu Cassandra / ScyllaDB. Czy ktoś stosuje to jako główną bazę danych w projekcie? Duplikujecie dane?
Przykład w relacyjnej bazie:
users
- id
- name
- photo
posts:
- id
- userid
- content
Na froncie potrzebujemy:
- nazwę użytkownika
- zdjęcie użytkownika
- treść postu
Robimy JOIN i mamy wszystko, ale jak się baza rozrośnie, to JOIN-y potrafią trwać wieki.
Swoją drogą w dobie HTTP/3 może to front powinien strzelać osobno po dane każdego użytkownika i zapisać w cache?
Natomiast w Cassandrze zaleca się duplikację danych:
users
- id
- name
- photo
posts:
- id
- userid
- username
- userphoto
- content
Teraz dodajmy funkcję "znajomi". W relacyjnej bazie tworzymy przelotkę wiele-do-wielu. W Cassandrze potrzebujemy kolejną tabelkę, gdzie też będą kopie tych samych danych, bo na froncie potrzebujemy wyświetlić znajomych danego użytkownika.
Dodajmy jeszcze funkcję "obserwowani" i pozwólmy wyświetlać "znajomi + obserwowani". Kolejne 2 tabele z duplikatami?
Dodajmy jeszcze czaty, artykuły, blogi, gdzie użytkownicy mogą coś publikować. Też potrzebujemy danych użytkownika.
Zastanawiam się, czy to ma sens. Równie dobrze można dane trzymać osobno i je doklejać z osobnych tabel, a żeby było szybko, to trzymać je w cache, np. Redis lub lokalny cache w pamięci. Ale czy znowu nie będzie potrzeba 64 TB RAM-u w dużym systemie?
Dodanie nowej funkcjonalności lub modyfikacja istniejącej wymaga zmian we wszystkich tabelach, gdzie trzymamy te dane.
Jeśli użytkownik zmieni zdjęcie, trzeba zmodyfikować wszystkie powiązane wiersze w innych tabelach, a co się wtedy dzieje:
- baza zapisuje informację, że coś się zmieniło (dla 99999 postów zapewne 99999 wpisów w memtable i commit logu)
- compaction - podczas którego baza optymalizuje się, co też może być czasochłonne
Backend musi zadbać o aktualizację tych danych we wszystkich tabelach. Nie mam pojęcia, czy jest jakaś biblioteka, która sama o to zadba. Raczej programista sam musi o to zadbać.
Jak coś się sypnie, np. padnie jakiś node, wystąpi błąd między zapytaniami, to będzie rozjazd danych.
Inna wada to brak transakcji i co za tym idzie, brak spójności danych. O lekkich transakcjach nie wspominam, bo jest wyśrubowany limit, ile danych można w takiej transakcji przesłać.
Ciekawe, jak to jest rozwiązane w Messengerze i innych aplikacjach korzystających z tej bazy danych. Przecież użytkownik może zmienić nazwę, zdjęcie, a na jednym czacie potrafi być 1000000 wiadomości, a co dopiero w całym systemie.
Mogę znaleźć inne przykłady, gdzie te same dane trzeba wyświetlać w wielu miejscach.
Rozważam migrację na inną bazę, bo to nam wymyślił pośrednik klienta, ale obecnie mamy wolny wybór.
Edit: chodzi o to, jakie podejścia stosowaliście w waszych projektach i co się sprawdziło przy dużej ilości danych.
TL;DR: Czy duplikować dane, czy robić wiele zapytań i sklejać w back-endzie?#programowanie #backend #bazydanych #nosql #fullstack #springboot