Szybka baza danych lub szybki cache z zapisem na dysk

1

Przymierzam się do nowszego projektu i zastanawiam się nad wyborem rozwiązania - pewnie jakiejś bazy danych (choć niekoniecznie).

Taki opis czego szukam:

  • musi być bardzo szybka i ogarniać jednocześnie duże ilości danych
  • samych tabel nie będzie dużo
  • bez żadnych update'ów czy usuwania danych (chyba, że w jakichś sytuacjach awaryjnych, ale wtedy można przyjąć że cały system leży i admin sobie będzie mógł grzebać do woli)
  • będą za to raczej skomplikowane query czytające duże ilości rekordów
  • raczej musi być programowalna - tj. zapis jednego rekordu będzie tworzył kilka rekordów (a z powodu wolumenu danych nie chcemy tego słać po sieci)
  • dobrze by było, żeby były relacje, ale nie jest to warunek konieczny
  • może być jakaś rozproszona, jeśli tylko nie będzie to miało wpływu na latency
  • na razie załóżmy, że infrastruktura jest dostępna w dowolnych ilościach, natomiast będzie stała na tyle daleko, że ruch sieciowy jest problemem
  • załóżmy też, że programiści którzy będą pracować na projekcie będą ogarnięci, więc nauka jakiegoś dziwnego języka nie jest problemem
  • po trzech-czterech dniach będą mogły być archiwizowane (tj. z punktu widzenia bazy danych - usunięte)
  • jeśli baza padnie to dane muszą być dostępne po starcie, więc samo in-memory odpada
  • jeśli chodzi o ramy czasowe to tak z 80% ruchu będzie się odbywać w ciągu 1:00 - 13:00, jakoś tak między 20:00-21:00 można będzie robić przerwę techniczną (np. wspomniane czyszczenie danych)
  • selecty będą głównie latały po danych z ostatniego dnia (na starym systemie to ok. 95% zapytań) i to one mają priorytet jeśli chodzi o czasy wykonywania.

Ewentualnie może ktoś ma inne propozycje, np. jakiś szybki cache + baza danych. Oczywiście nie chciałbym tego wszystkiego pisać prawie od zera (też padł taki pomysł), jedynie zestawić i oprogramować już istniejące rozwiązania - więc pytam o wasze doświadczenia.

2

Pytanie co oznacza wiele rekordów, bo dla jednego to 1e6, dla drugiego 1e9. Prawda nieobjawiona jest taka, że nie ma czegoś takiego jak relacyjna baza danych o dużej wydajności w zapisie i odczycie.

Czy potrzebujesz transakcyjności, czy wystarczy ci eventual consistency?
Bo mogę sobie to wyobrazić tak, że dane wlatują do jakiejś kolejki, za kolejka jest usługa, która je ładuje asynchronicznie do DB ze strukturą przygotowaną do odczytu.
Ewentualnie rozgłaszasz te dane jakimś topic'iem, za każdy z zelektów odpowiada osobna usługa, która robi na nich reduce i uaktualnia wynik każdego z tych rozbuchanych zapytań.

Jeżeli to naprawdę ma szybko działać i przetwarzać naprawdę dużo danych, to czeka cię zagłębienie się w big data. Czyli np. to map/reduce.
Czy casłość musi być on-premise, czy mogą to być usługi chmurowe?

https://cloud.google.com/products/#section-7
https://cloud.google.com/products/#section-8

0

Ile terabajtów na sekundę ma obsługiwać baza? Bo od tego wiele zależy

0

I co to za dane.

2

Strzał: Redis!
Używam i sobię chwalę, płacę, znaczy inwestorzy płacą xD

0

@piotrpo:

  1. W tej chwili "dużo" to ok. sześć miliardów rekordów wejściowych na te dwanaście godzin, (czyli jakieś 200 tys. na sekundę) natomiast będą wzrosty.
  2. eventual consistency raczej odpada.
  3. Jeżeli to naprawdę ma szybko działać i przetwarzać naprawdę dużo danych, to czeka cię zagłębienie się w big data - swoje doświadczenia mam, natomiast pytam innych :)
  4. Czy casłość musi być on-premise, czy mogą to być usługi chmurowe? - dane nie mogą być przechowywane w publicznej chmurze, natomiast jeśli coś da się zainstalować na mocnej maszynie to możemy negocjować.

@anonimowy: nie wiem, czy istnieje system ogarniający terabajty w real-time z SLA na poziomie minuty.

@S4t: wartości liczbowe (głównie floaty, long/timestamp), ewentualnie wartości, które da się łatwo przetłumaczyć na liczby (tj. enumy)

@lion137: też biorę opcję z cache'm pod uwagę, chociaż nie Redis.

1

Wejście na kafkę, za kafką usługi wyliczające wyniki, albo zbiór usług map-reduce?

0

To moze cos dla serii czasowych. Jakis influx osłoniety kafka albo jakas kolejka.

0

Dzięki za odpowiedzi, natomiast bardziej chodziło mi o nieco konkretniejsze rozwiązania.
Sam problem patrząc na dużych klockach nie jest jakoś specjalnie skomplikowany bo sprowadza się do czegoś in-memory z opcją zapisu na dysk. Jako, że jedynie dopisujemy rekordy to oczywiście mamy jakiś format kolumnowy.

Tyle tylko, że diabeł tkwi w szczegółach w stylu:

  • jaka baza in-memory?
  • jak konkretnie zapisywać dane na dysk?

Tak jak napisałem - mam swoje pomysły (których celowo nie podaję), i pytam czy może ktoś może pracował przy podobnych problemach i zna jakieś konkretne produkty. Oczywiście jeśli ktoś pracował przy obróbce danych w real-time i robił to inaczej to też z chęcią poczytam, jak wyglądał system :)

Samym streamingiem typu Kafka Streams niestety sprawy nie rozwiążę - bo te selecty będą robione ad-hoc, więc nie można sobie tworzyć raportów na zaś.

0

To może Apache Druid?

1 użytkowników online, w tym zalogowanych: 0, gości: 1