Baza danych, szybkie odczyty, petabajty danych

Cześć. Wymagania są takie, aby baza danych zapewniała szybkie odczyty i pozwalała przechowywać petabajty danych.

Prawdopodobnie będą to dwie bazy. Obie mają przechowywać wszytkie zdarzenia zachodzące w systemie (miliony dziennie) dotyczące klientów oraz pracowników.
Jedna baza ma trzymać skrócone dane i zapewniać odczyty po kilku określonych od początku atrybutach. Druga natomiast ma trzymać pełne szczegółowe dane i umożliwiać odczyty po wielu różnych zapytaniach (elastyczne podejście) oraz udostępniać analityki.

Dla pierwszej bazy wstępnie myślę o Cassandrze lub Big Table od Google.
Dla drugiej Elasticsearch lub Big Query również od Google.

Koszty nie grają roli.

Co o tym sądzicie?

Ktoś bardziej doświadczony w takich obszarach mógłby się bardziej wypowiedzieć?
Z góry dzięki :)

Wszystko oczywiście zależy co to znaczy "szybkie odczyty" dla jednego przypadku szybkie to kilkanaście sekund a dla innego 100ms to długo... Musisz bardziej sprecyzować swoje potrzeby:

1. Opisz co dokładnie chcesz osiągnąć
2. Jak wyglądają zapisywane rekordy tych zdarzeń?
3. Po czym dokładnie będziesz szukał?
4. Ile będzie zapytań wyszukujących z tej bazy np. na minutę albo sekundę?
5. Ile dokładnie tych Peta bajtów będzie, bo 2 to też peta bajty, a taką ilość można od biedy ogarnąć na odpowiednio przygotowanym PC z macierzą dyskową.

Czuję jednak, że temat można spokojnie ogarnąć zwykłym dobrze skonfigurowanym MySQL lub inną klasyczną bazą SQL.

Trzeba się jednak skoncentrować na:

1. Mądrym zapisywaniu danych w postaci int (co się da to słownikować przed zapisem).
2. Dobrze przemyśleć indeksy.
3. Zaplanować partycjonowanie tabeli.
4. Partycje najlepiej aby były na różnych dyskach.

Są także inne narzędzia i techniki ułatwiające szukanie i zwiększające wydajność wyszukiwania w dużych zbiorach ale na podstawie założeń, które podałeś pozostaje wróżyć z fusów...
Wynika z tego jedynie tyle, że czegoś będzie dużo i kogoś strach obleciał bo usłyszał "Peta bajty".

Intuicja mi podpowiada, że już na etapie zapisu z tych peta bajtów zrobią się co najwyżej dziesiątki tera bajtów a kolejne optymalizacje czekają na moment jak tylko pokażesz przykłady danych, które chcesz zapisywać.

To, że wybierasz produkt na początku, pokazuje, że źle do tego podchodzisz. Powinieneś wyjść od wymagań:

• regulacje prawne - czy dane mogą być przechowywane w chmurze? Czy masz zapewnić zgodność z GDPR, SOX, PCI DSS, ...
• czy możesz utracić dane? ile czasu może poświęcić na odtworzenie wszystkiego z backupu? czy dane mogą być niedostępne przez 10 minut, dzień, miesiąc?
• co z danymi historycznymi? trzymasz wszystko "forever", czy np. po 2 latach musisz usunąć (regulacje...)
• jak szybko musisz zapisywać? jak szybko odczytywać? jaki będzie rozkład ruchu: zapisy vs odczyty?)
• jak te dane będą przetwarzane (write -> read only, a może też update?)
• ile tych danych będzie po roku, 2, 5, 10?
• czy te dane mają jakąś naturalną segmentację (np. rejony geograficzne, oddziały firm, etc.)
• piszesz, że koszty nie grają roli. Chodzi o CAPEX i OPEX ? Czy może tylko jedna z kategorii nie gra roli?

Możliwości architektonicznych masz sporo. Skoro koszty nie grają roli, to nie bawiłbym się w rozwiązania typu "postawimy sobie XYZ na ...", tylko spisał wymagania i wysłał do vendorów RFI/RFQ.
Będziesz miał i koszt i architekturę.

@Bambo czuję jakbym czytał taska stworzonego przez Scrum Mastera humanistę "Wybierz bazę danych" / 10 SP.

Takich decyzji nie podejmuje się na podstawie 2 czy 3 zdań.
Przygotuj tabelę która będzie zawierać wymagania oraz mocne i słabe strony wszystkich rozważanych rozwiązań.

Z opisu wynika petabajty danych z jednej strony oraz zdarzenia z drugiej - to sie nie kleji...
Czy ty zamierzasz robić Even Source'ing na systemie który ma być wydajny? To się nie uda.

Cassandra to nie jest baza którą można olać, gdy klaster się rozrośnie potrzebna będzie specjalistyczna wiedza jak go utrzymać. Poza tym ta baza nie słynie z wydajności, jeżeli wydajność jest ważna to można próbować ScyllaDB lub ClickHouse.

O ElasticSearch niewiele wiem więc się nie wypowiem.

Myślę że powinieneś określić dokładnie co masz na myśli przez petabajty danych (małe pliki czy duże bloby?) oraz przez "eventy". Być może ci potrzeba bazy dla metryk i logów? Ale w takim razie lepiej zapłacić za DataDog niż rzeźbić samemu.

Innymi słowy: garbage in (twoje pytanie) garbage out (moja odpowiedź).

Jeżeli tu będzie tylko odczyt danych, bez aktualizacji to równie dobrze może to być baza relacyjna a nie jakiś NoSQL, tylko z dobrze opracowanym partycjonowaniem danych/indeksów i clusterem serwerów.

Oczywiście wszystko na jak najszybszych dyskach NVM i dobrych serwerowych płytach głównych.

Edit

Chociażby Postgresql:

https://www.postgresql.org/docs/current/high-availability.html

To ja dodam, że warto mieć listę tego co ma współpracować z tą bazą. Bo zaraz okaże się, że implementacja bazy X dla języka Y i frameworka Z nie jest prosta dla tak zamodelowanych danych jak byście chcieli.
No i zawsze koszty wchodzą w grę. Jak się uprzesz to pewnie wyklikasz w jakieś chmurze opcje by to postawić nawet na pamięci RAM bez użycia dysku np. w REDIS tylko jak przyjdzie rachunek za chmurę to będzie to przedostani dzień pracy bo włodarze bedą musieli wrócić z OIOMU po podejrzeniu zawału, żeby Cie zwolnić.

Nie wiem czemu w ogóle zaczynasz od wyboru bazy konkretnej. Zacznij od use-case'u biznesowego; co ta baza ma niby robić? Idę o zakład że najpewniej przez pierwszych x miesięcy głupie mysql (albo nawet nie) spełni Twoje wszystkie potrzeby. Jeśli chcesz móc zmienić bazę w przyszłości, to nałóż odpowiedni interfejs na nią, tak żeby jej zmiana była prosta.