Baza danych z mnóstwem wejść

Mam zagwozdkę. Jestem na wstępnym etapie (jeszcze koncepcyjnym) pracy nad systemem, który będzie służył do gromadzenia i wizualizowania danych - w wielkim skrócie można to nazwać "klonem Google Data Studio". Co mam na myśli?

1. Liczba źródeł danych będzie przyrastać w czasie tzn. będzie ich coraz więcej. Każde ze źródeł danych będzie uruchamiane w innym momencie oraz będzie dostarczało inny zestaw danych.
2. Ilość przetwarzanych danych będzie rosła geometrycznie (bo nie tylko będzie więcej źródeł, ale również więcej "powodów", aby je przetwarzać).
3. Baza danych musi być bardzo szybka (zarówno w odczycie jak i w zapisie), ponieważ będziemy aktywnie przetwarzali dane.

Jak ugryźć taki problem od strony architektury? Z czymkolwiek się Wam to kojarzy?

PS. Do płatnej konsultacji dotyczącej wspomnianego przeze mnie projektu poszukuję dwóch specjalistów:

• Płatna konsultacja - Specjalisty ds. baz danych
• Płatna konsultacja - Doświadczony Programista

mało konkretów !

Adamek Adam napisał(a):

mało konkretów !

Nie mam ich więcej. Kierunek projektu zależy ode mnie. Konkrety powstaną na podstawie rad, które otrzymam. Nie oczekuję też gotowego rozwiązania, a raczej wskazanie kierunku.

MP5A4 napisał(a):

Nie mam ich więcej. Kierunek projektu zależy ode mnie. Konkrety powstaną na podstawie rad, które otrzymam. Nie oczekuję też gotowego rozwiązania, a raczej wskazanie kierunku.

Przy takim poziomie zaangażowania to musisz znaleźć ogarniętą osobę, która będzie Ci zadawała pytania jak na przesłuchaniu. Inaczej się nie da tego zrobić. Z tego co widzę (oczywiście nie mogłeś tego zawrzeć w poście, bo po co) to chcesz zrobić coś ala Looker Studio a to ciężkie zadanie, bo przechowywanie ogromnych ilości danych nie jest tak dużym problemem jak robienie skomplikowanych zapytań na takim wolumenie

slsy napisał(a):

MP5A4 napisał(a):

Nie mam ich więcej. Kierunek projektu zależy ode mnie. Konkrety powstaną na podstawie rad, które otrzymam. Nie oczekuję też gotowego rozwiązania, a raczej wskazanie kierunku.

Przy takim poziomie zaangażowania to musisz znaleźć ogarniętą osobę, która będzie Ci zadawała pytania jak na przesłuchaniu. Inaczej się nie da tego zrobić. Z tego co widzę (oczywiście nie mogłeś tego zawrzeć w poście, bo po co) to chcesz zrobić coś ala Looker Studio a to ciężkie zadanie, bo przechowywanie ogromnych ilości danych nie jest tak dużym problemem jak robienie skomplikowanych zapytań na takim wolumenie

Jak najbardziej jestem skłonny zapłacić za takie konsultacje, vide: https://4programmers.net/Forum/Og%C5%82oszenia_drobne/364181-platna_konsultacja_specjalisty_ds_baz_danych?p=1873390#id1873390 ale dodatkowo szukam opinii i pomysłów.

MP5A4 napisał(a):

Z czymkolwiek się Wam to kojarzy?

Duża ilość danych kojarzy mi się z Cassandrą. Ale w zasadzie to zalezy od rodzaju zapytań jakie będziesz wykonywać

czy dane zebrane muszą być widoczne "od razu" do analizy? Pytam bo generalnie Baza danych musi być bardzo szybka (zarówno w odczycie jak i w zapisie) to się nawzajem wyklucza. Rozwiązaniem może być gromadzenie danych online do jednego worka a potem, np. raz dziennie przerzucanie ich hurtem do drugiego worka na którym będzie działać przetwarzanie danych

Podstawowe pytanie:

• jaki rodzaj/struktura danych
• jaka wielkosc (np. Kafka bardzo nie lubi duzych rekordow)
• jaki klucz, po czym odczytujemy
• czy potrzebujemy modyfikowac/usuwac dane

MP5A4 napisał(a):

1. Liczba źródeł danych będzie przyrastać w czasie tzn. będzie ich coraz więcej. Każde ze źródeł danych będzie uruchamiane w innym momencie oraz będzie dostarczało inny zestaw danych.

Kolejki, Kafki na wejścia. Co znaczy będzie rosła? Ile danych będzie wysyłać jedno źródło. Co się ma wydarzyć z tymi danymi.

1. Ilość przetwarzanych danych będzie rosła geometrycznie (bo nie tylko będzie więcej źródeł, ale również więcej "powodów", aby je przetwarzać).

To jest enigmatyczne, że jedyna słuszna odpowiedź to zależy.

1. Baza danych musi być bardzo szybka (zarówno w odczycie jak i w zapisie), ponieważ będziemy aktywnie przetwarzali dane.

Nie ma takich baz dlatego między innymi robi się hurtownie danych.

Jak ugryźć taki problem od strony architektury? Z czymkolwiek się Wam to kojarzy?

Chyba porywasz się z motyką na słońce. Takie rzeczy robią firmy z milionowymi budżetami: MS, Google itp

Najlepiej jaki problem chcesz rozwiązać to będzie można jakoś ugryźć temat. Na tą chwilę jest on nie określony.

abrakadaber napisał(a):

czy dane zebrane muszą być widoczne "od razu" do analizy? Pytam bo generalnie Baza danych musi być bardzo szybka (zarówno w odczycie jak i w zapisie) to się nawzajem wyklucza. Rozwiązaniem może być gromadzenie danych online do jednego worka a potem, np. raz dziennie przerzucanie ich hurtem do drugiego worka na którym będzie działać przetwarzanie danych

Wspaniałe pytanie. Czyli opóźnienie rzędu kilku godzin byłoby pomocne? Dane nie musiałby być dostępne od razu. Gdyby były dostępne następnego dnia, to byłoby OK.

WhiteLightning napisał(a):

• jaki rodzaj/struktura danych

W zasadzie to próbuję odpowiedzieć na to pytanie.

WhiteLightning napisał(a):

• jaka wielkosc (np. Kafka bardzo nie lubi duzych rekordow)

To będą bardzo małe rekordy rzędu 1KB ale będą ich setki milionów.

WhiteLightning napisał(a):

• jaki klucz, po czym odczytujemy

Dla uproszczenia możemy przyjąć, że to będzie data.

WhiteLightning napisał(a):

• czy potrzebujemy modyfikowac/usuwac dane

Świetne pytanie. Nie.

S4t napisał(a):

Chyba porywasz się z motyką na słońce. Takie rzeczy robią firmy z milionowymi budżetami: MS, Google itp

Mam jakieś 100k USD na opracowanie MVP, które zadziała w małej skali (mniej więcej 1/10000 tego co będzie oczekiwane jako wersja publicznie dostępna).

S4t napisał(a):

Najlepiej jaki problem chcesz rozwiązać to będzie można jakoś ugryźć temat. Na tą chwilę jest on nie określony.

Dzięki. Pomyślę o tym jak go doprecyzować bez zdradzania szczegółów, których zdradzić nie mogę.

To jest rozwiązanie dla konkretnego jednego podmiotu czy chcesz zrobić z tego ogólnodostępną usługę?

Kilkaset milionów rekordów nie brzmi zbyt groźnie, pracowałem nad aplikacją zbierającą dane z kilkuset źródeł, bazy danych po kilka terabajtów skompresowanych danych, liczba rekordów liczona w miliardach, raportowanie real time i wszystko działało błyskawicznie na zwykłym MS SQL Server z indeksami columnstore https://learn.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview

Czy potrzebujesz tego co oferują silniki bazodanowe?
Czy dane będziesz miał relacyjne?
Czy chcesz obrabiać dane w SQLu?
Czy ma to byc cloud native?

Możliwe, że nie potrzebujesz bazy danych, tylko rozproszonego storage, schedulera jobów i elastyczności w tworzeniu jobów przetwarzających dane.

Istnieją rozwiązania oparte zazwyczaj na Hadoopie, które pozwalają ciągnąć i zapisywać dane z różnych źródeł, np. możesz napisać SELECT * FROM myEntity JOIN anotherEntity WHERE myEntity.id = anotherEntity.id, gdzie myEntity może oznaczać zarówno plik CSV lub topic Kafkowy, a anotherEntity to tabela z np. MySQLa.

Problem zaczyna się, kiedy wymagasz wydajności, bo masz tutaj kilka wąskich gardeł - z jednej strony wspomniany topic kafkowy może być wolny, tak samo jak i np. baza SQL. Do tego musisz mieć mocny klaster, na którym będzie hulało owo rozwiązanie. IMO o ile da się jeszcze zagwarantować względną szybkość odczytu to w tej chwili bardzo trudno jest mi wyobrazić sobie sytuację, w której zapis do dowolnego źródła będzie bardzo szybki.

Natomiast jeśli zejdziesz trochę z wymagań, tj. stwierdzisz, że czytać można z dowolnego źródła, ale zapisywać będziesz do np. jakiegoś cache'a, który po pewnym czasie będzie wypychał dane do jakichś plików, to da się to wykonać. Natomiast ostrzegam, że stworzenie systemu opartego na tego typu rozwiązaniach jest czymś mega ciężkim i czasochłonnym.

Różnego rodzaju narzędzia mają swoje niskopoziomowe quirki. Np. hadoopowy sterownik do S3 pozwala zapisywać timestampy jako int32, int64 lub long - i jeśli spróbujesz porównać jeden timestamp zapisany jako int32 oraz longa to apka się wywali. A tutaj mówimy tylko o wykorzystaniu tego samego sterownika na różne sposoby.