Cloud a trzymanie dużej ilości danych binarnych.

1

Od dawna mam z tyłu głowy jeden problem i do tej pory nie natknąłem się na żadne sensowne rozwiązanie.

Mam w c**** danych binarnych pliki te mają od 100MB do 1 GB. A rząd wielkości wszystkich danych to 100TB. Operacje jakie wykonywane są na plikach to bardzo duża liczba odczytów pewnego zakresu bajtów z takiego pliku. W przypadku baremetal nie ma problemu jeden odczyt to 10-30ms więc nawet jak zrobię ich 100-200 na jedną operację to nie ma problemu.

W przypadku cloudowych rozwiązań zaczynają się schody.

  • Żaden provider cloudowy dla usług typu s3 nie obsługuje multi-range byte requests. A w większości czas jednego odczytu oscyluje >100ms czyli rząd wielkości więcej niż baremetal i obsługa systemu staje sie praktycznie niemożliwa.

  • Dla usług typu EBS cena samego trzymania danych wychodzi prawie 5k $ miesięcznie więc opłacalność tego żadna.

Także w sumie pytanie czy znacie jakieś rozwiązanie tego typu problemów. I tak z ciekawości znacie hostingi które udostępniają duże przestrzenie ? Bo zazwyczaj to jest tak ze jak już się znajdzie hosting który to odstępni to maszyna jest az za mocna ponad 12 rdzeni i ponad 128GB ramu i boostuje to cene samego hostingu. A na takim dedyku nie działoby się nic więcej niż odczyt i zwrócenie danych. A znów w słabszych konfiguracjach nie da sie wrzucic tyle pamięci dyskowej.

Edit:
Storage nie musi być backupowany jakoś super bo dane nie są źródłowe więc ich odtworzenie to nie problem.

2

Problem wygląda trochę jak baza danych 100TB z bezpośrednim dostępem do danych z plików :)

Możesz użyć:

  • najtańszych dysków co redukuje koszt do $1740 ale nadal sporo i brak gwarancji wydajnościowych
  • instance storage - ale nie ma nawet takich konfiguracji na 100TB a mniejsze dotyczą najmocniejszych maszyn
  • hybryda s3 + instance storage jeżeli tylko część plików jest gorąca
  • hybryda s3 + baza danych/cache jeżeli tylko część danych jest gorąca
0

@ralf: Tak myślałem właśnie, że ciężko będzie coś "urodzić z tego". Muszę sobie przeanalizować ale wstępnie idea hybrydy s3 + instance storage może mieć sens.

0

Możesz rozwinąć czym jest dla ciebie bare metal skoro porównujesz/przeciwstawiasz to "cloudowi"

0

@marian pazdzioch: Serwer w serwerowni. Nie wiem jakiej informacji chcesz się dowiedzieć. W serwerowni są macierze dyskowe spięte po lanie z serwerem. Komunikacja leci po protokole SMB 3.1.1.

0

po prostu nie wiem co znaczy bare metal w tym co napisałeś, dla mnie bare metal to

Bare-metal programming is a term for programming that operates without various layers of abstraction or, as some experts describe it, "without an operating system supporting it."

a to co napisałeś to, bo ja wiem, jakiś on-premises chyba

1

Screenshot from 2022-05-06 21-18-30.png
Raczej nie musisz tego trzymać na jednej maszynie więc możesz też zrobić własnej roboty hadupa (https://www.digitalocean.com/community/tutorials/understanding-database-sharding)
A po co chcesz zmienić on-prem na awsa? Żeby było drożej czy wolniej?

0

@vpiotr: Bo serwerownia jest w jednym miejscu a klienci po różnych stronach świata + bardzo nie odporna na awarie. Poza tym przyrost danych też jest spory. I ja nie mam problemu z danymi one są świetnie uporządkowane dokładnie wiem co znajduje się pod którym bajtem w każdym pliku. Mój problem jest inny. Ja często wykonuje te operacje i jedna operacja biznesowa to wiele odczytów aby zebrać wiele parametrów po prostu z takiego pliku.

Podział tych danych na wiele maszyn nie zmieni kompletnie nic. Bo co za różnica czy 100 z jednego pliku na s3 musze odczytać czy ze 100 ? Minimalny czas requestu będzie taki sam ~100ms. W przypadku s3 problem jest taki ze jak masz https://docs.aws.amazon.com/whitepapers/latest/s3-optimizing-performance-best-practices/use-byte-range-fetches.html to przyjmuje on tylko jedna wartość i możesz odczytać dane np od 100 bajta do 200bajta. Ale nie możesz w jednym zapytaniu podać wielu przedziałów.

2

Pracowałem z takimi plikami gdzie rozmiar jednego pliku szedł w setki MB i dostęp był randomowy. Plik miał bardzo ścisłą strukturę, ale pozycja w pliku zmnieniała się wielokrotnie. Koszmar optymalizacyjny.
Nie naprawialiśmy tego bo to był bardzo legacy kod, na szczęście dało się zrobić obejście.

Bez zmiany na dostęp sekwencyjny to raczej nie uda Ci się zmniejszyć czasu odpowiedzi. Nie wiem na ile nadaje się cloud - np. Netflix owszem działa na AWS, ale oni mają raczej długie strumienie danych i można je buforować.

Musiałbyś chyba całkowicie zmienić architekturę, bo to brzmi trochę jakbyś miał bazę danych zrobioną in-house. Ogólnie super, ale latanie seekiem po pliku w końcu przestaje wystarczać.
Potrzebne są jeszcze cache, buforowanie, indeksy, odczyt tylko indeksu, odczyt danych wg indeksu itd.

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