Odkładanie 2.5mld wierszy dziennie, jaki storage?

2

Przenoszę pytanie z mikrobloga do posta
Dyskusja wciąz jest raczej luźna, chętnie poznam propozycje

Screen z dotychczasowymi odp poniżej ze względu na to że wpis będzie usunięty

screenshot-20180906133552.png

0

@azalut: 2,5 MILIARDA dziennie?
Czy jesteś pewien tej ilości? Co takiego będziesz robić, że tyle danych Ci się pojawi? Napisz coś więcej, bo samo źródło tego problemu wydaje się interesujące

@Artur Protasewicz: Z OCR jest pewien problem. Nieważne, jak by nie był cudowny, zawsze są pomyłki. Zwłaszcza, jak masz kilka kolumn, jakieś tabelki, wykresy czi grafiki. Poza tym skany też nie są idealne - czasami krzywo się kartka wsunie, jakieś zbrudzenia czy zagniecenia. Dlatego Twoje rozwiązanie jest OK, ale raczej w charakterze wstępnej archiwizacji, przy czym trzeba pamiętać, że moga się pojawić jakieś błędy. Dlatego np. danych księgowych bym w ten sposób nie obrabiał.

1

Z estymacji wychodzi ok 2,2mld, realnie pewnie będzie max 2mld ale pesymistycznie napisałem 2.5 ;)

Wiele szczegółow jeszcze nie znam, ale wstępnie: mamy wiele bytów w aplikacji, które sa ze sobą powiązane. np 10 bytów A i 5 bytów B powoduje 50 wierszy (taki crossjoin :))
Musimy zapisać informacje o wiadomościach przychodzących z kolejek bardzo szczegółowo dla każdego bytu z każdym w każdej możliwej konfiguracji
Musimy to robić co jakiś krótki okres czasu (sekundy)

Nie jesteśmy pewni czy to w ogóle będzie wdrażane w życie, bo jest na etapie negocjacji, ale problem wydal się na tyle ciekawy że postanowiłem zapytać

przykładowo:
byt A: 10el
byt B: 20el
byt C: 100el

spowoduje powstanie 20 tys wierszy (10 x 20 x 100), tzn każdy z każdym
i tak co np 5 sekund

0

Nie wiem oczywiście, ale strzelam, że w jednym snapshocie większość z tych krotek AxBxC będzie pusta i nie warto ich w takim razie trzymać. To powinno drastycznie zmniejszyć zapotrzebowanie na storage. Czy zgadłem?

1

Nie chodzi mi też o analizę mojego przypadku
Jest on na bardzo wczesnym stadium i może się bardzo wiele zmienić, choćby dlatego pierwotnie pytanie zadane było na mikroblogu, a nie w postcie

Bardziej ciekaw jestem jakie technologie trzeba by użyć mając już pewność, że z tej ilości danych nie da się zejść

Tym bardziej, że wiem że się da to zrobić wydajnie patrząc np na google, facebook, twitter i tym podobne mające spory ruch i śledzące wszystko co możliwe strony ;)

0

da to zrobić wydajnie patrząc np na google, facebook, twitter i tym podobne

Tylko nie porównuj Twojego budżetu z budżetem Google. Wiadomo, że się da, ale ich sprzęt i cała infrastruktura nie może się równać z tym, co Wy tam macie.

To trochę jakby ktoś na forum Golfa3 zadał pytanie, jak przyspieszać do 250km/h w 5 sekund oraz jak zmienić komplet kół w 3 sekundy. Przecież wiadomo, że się da - w końcu w Formule1 tak robią :P

1

@cerrato
skąd wiesz jaki mamy budżet? :P

napisałem, żeby nie analizować tego pytania na moim przypadku

1

Wiadomo, że się da, ale ich sprzęt i cała infrastruktura nie może się równać z tym, co Wy tam macie.

Od tego jest AWS albo Google Cloud ;)

0
cerrato napisał(a):

@Artur Protasewicz: Z OCR jest pewien problem. Nieważne, jak by nie był cudowny, zawsze są pomyłki. Zwłaszcza, jak masz kilka kolumn, jakieś tabelki, wykresy czi grafiki. Poza tym skany też nie są idealne - czasami krzywo się kartka wsunie, jakieś zbrudzenia czy zagniecenia. Dlatego Twoje rozwiązanie jest OK, ale raczej w charakterze wstępnej archiwizacji, przy czym trzeba pamiętać, że moga się pojawić jakieś błędy. Dlatego np. danych księgowych bym w ten sposób nie obrabiał.

To się zgadza, dlatego trzeba też przewidzieć funkcje (funkcjonalności) weryfikujące poprawność tabelek, cyfr, tekstów, etc. po zebraniu danych, ale tak, czy inaczej trzeba to zobaczyć już teraz, a nie za pół roku. W architekturze np. drapaczy chmur prowadzi się najpierw eksperymenty w skali o wiele mniejszej (proporcjonalnej - ta sama skala w każdym wymiarze ukł. kartezjańskiego), to samo w konstrukcji statków oceanicznych, badanich klimatu i pływów oceanicznych, robi się makiety, zdjęcia do obsypanego oskarami "Tytanica" były robione w odpowiednio zmniejszonej skali na modelu w którym odwzorowano każdy zauważalny szczegół w basenie w którym symulowano fale oceanu itp. itd. 1. Rachunek kosztów, 2. Badania w zminiaturyzowanej skali. 3. Szukanie analogii i podobnych modeli.

4

To ja powtórzę S3 + Spark i rozwinę:
Dlaczego S3? Jest względnie tani, możesz ustawić retention policy i dane same z siebie będą znikały po 6 miesiącach, praktycznie bezinwazyjne. Ponadto da się to spiąć z masą narzędzi do wykonywania zapytań, co może pozwolić uniknąć kopiowania terabajtów danych we wszystkie strony.
Dlaczego Spark? Bo możesz wyklepać aplikację w miarę szybko, wystartować ją na EMR w 10 minut i zacząć czytać dane, a po skończeniu zwinąć i więcej nie płacić. Wprawdzie Spark nie będzie najszybszy, ale przelecenie tych danych raczej nie będzie problemem od strony technicznej, szczególnie jeżeli będziesz je przechowywał w sensownej strukturze katalogów, to wtedy łatwo odfiltrujesz niepotrzebne dane już na poziomie plików.

A jeżeli będzie za wolno? Stawiasz Redshifta, kopiujesz dane bezpośrednio z S3 i wykonujesz dowolne zapytani SQL. W tym tygodniu odpalałem trochę joinów na tabelce z 50+ miliardami wierszy i wyniki dostawałem po kilkudziesięciu sekundach, no ale za Redshifta płaci się jak za zboże.

0
azalut napisał(a):

Nie chodzi mi też o analizę mojego przypadku
Jest on na bardzo wczesnym stadium i może się bardzo wiele zmienić, choćby dlatego pierwotnie pytanie zadane było na mikroblogu, a nie w postcie

Bardziej ciekaw jestem jakie technologie trzeba by użyć mając już pewność, że z tej ilości danych nie da się zejść

Tym bardziej, że wiem że się da to zrobić wydajnie patrząc np na google, facebook, twitter i tym podobne mające spory ruch i śledzące wszystko co możliwe strony ;)

To się da, jak cię stać na wybudowanie miasta z własną elektrownią...

2

2,5 miliarda na pół roku daje 450 miliardów. Niech każdy wiersz ma 100 bajtów, to daje 45 terabajtów danych. Koszt na S3 = 0,023 * 45000 = 1035$ miesięcznie. Odpalamy zapytanie, stawiamy EMR na 10 węzłów r3.8xlarge w cenie $2.660 + $0.270 za każdy za godzinę, to nam daje 21096$ miesięcznie i możemy odpalać zapytania, o ile potrzebujemy klastra cały czas. Oczywiście to AWS, więc trzeba doliczyć ukryte koszty i opłaty manipulacyjne maści wszelakiej. @Artur Protasewicz: Coś tania ta elektrownia.

0
azalut napisał(a):

Z estymacji wychodzi ok 2,2mld, realnie pewnie będzie max 2mld ale pesymistycznie napisałem 2.5 ;)

Wiele szczegółow jeszcze nie znam, ale wstępnie: mamy wiele bytów w aplikacji, które sa ze sobą powiązane. np 10 bytów A i 5 bytów B powoduje 50 wierszy (taki crossjoin :))
Musimy zapisać informacje o wiadomościach przychodzących z kolejek bardzo szczegółowo dla każdego bytu z każdym w każdej możliwej konfiguracji
Musimy to robić co jakiś krótki okres czasu (sekundy)

Nie jesteśmy pewni czy to w ogóle będzie wdrażane w życie, bo jest na etapie negocjacji, ale problem wydal się na tyle ciekawy że postanowiłem zapytać

przykładowo:
byt A: 10el
byt B: 20el
byt C: 100el

spowoduje powstanie 20 tys wierszy (10 x 20 x 100), tzn każdy z każdym
i tak co np 5 sekund

Proponuję zacząć od normalizacji bazy danych. Czy nie lepiej trzymać każdy byt w osobnej tabeli? Myślę, że lepiej. Lepiej dzielić byty niż łączyć. Potem będziesz zadawał kwerendy SQL.

Trochę się bawiłem w estymatory i powiedziałbym dodaj stałą. Mnie pewien estymator kiedyś bardzo zmylił (ostatecznie zrobiłem to na wariacjach), otóż znalazłem poprawną funkcję, ale nie było to rozwiązanie. Byłoby, gdybym przesunął wykres liniowo względem osi odciętych i rzędnych.

Estymatory mogą ci pomóc w znalezieniu najbardziej istotnych (najbardziej oddziałujących na całą obserwowaną rzeczywystość w jakimś horyzoncie zdarzeń) bytów, ew. najbardziej istotnych związków między bytami. Spróbuj sobie wyobrazić pojedynczy estymator, jako generator stałej częstotliwości. Ze zbioru różnych estymatorów możesz otrzymać widmo, a to pozwoli zawęzić obszar obserwacji.

1

Wygląda na to, że kilka dysków 10T ogarnie sprawę. Do tego jakiś engine bazodanowy, nawet darmowy Postgres. Ma limit tabeli 32T. Czyli temat na jednego peceta. Aczkolwiek tu by było pewnie słabo ze skalowalnością. No i kto by się odważył :) Cassandra ze swoją skalowalnością poziomą wydaje się bezpieczniejsza.

0

Podaję link, bo sam byłem nieświadomy i sobie poszukałem:

http://cassandra.apache.org/

0

Nie wiem skad pomysł na cassandre, oprócz hype driven development. Cassandra spoko jak chcesz rozproszony storage, żeby zapisy były blisko nodów z systemem, z eventual consistency. Ale tutaj przecież to pasuje jak pięść do oka.

Ja też bym to pakował do s3 a potem to juz zależy jak bardzo złożone masz dane i jak złożone opreracje chcesz robić. Jeśli to będzie w miare proste to zrobiłbym tam orc schema i puszczał query przez Athene. Jeśli logika przetwarzania danych wykracza poza zwykłe sqlowe query, to faktycznie może Spark. A jeśli i to nie wystarczy to zapiąć hurtownie na tym, choćby tego Redshifta.

1

Jeśli chodzi o ilość readów to będzie bardzo mała, można powiedzieć średnio góra jedno zapytanie dziennie. Czas odpowiedzi nie jest bardzo istotny, ale żeby był w granicach rozsądku - jakby chcieć pobrać dane np z konkretnego dnia i przegrupować żeby to trwało max 1min

0

Dla informacji
2.5 miliarda / sekund = 28 935,19 op/sek

Postawiłem sobie pytanie o sieć, przyjąłem 100bajtów na jednostkę i 20% narzutu
28 Mbit/sek

0
azalut napisał(a):

Jeśli chodzi o ilość readów to będzie bardzo mała, można powiedzieć średnio góra jedno zapytanie dziennie. Czas odpowiedzi nie jest bardzo istotny, ale żeby był w granicach rozsądku - jakby chcieć pobrać dane np z konkretnego dnia i przegrupować żeby to trwało max 1min

No więc co mamy?:
Dane:
1 zapytanie dziennie
byty (kolumny tabeli) A, B, C, D, E
Przy założeniu trzymania 1 bytu w jednej tabeli (tj. w postaci znormalizowanej)

  • pojemność dysku na 1 zapis np. A = B = C = D = E = 100 => 500 wierszy => wymagania jednostkowe co do STORAGE
  • pojemność dysku i pamięci na 1 zapytanie wg. przykładu A x B x C x D x E => 100^5 wierszy => wymagania jednostkowe co do READ

Wg. mnie są mniejsze wymagania co do STORAGE niż co do READ, dlatego dane powinny być na tym 10T dysku lokalnie
i lokalnie zapuszczamy query SQL

0

Jedna jeszcze rzecz mi przychodzi do głowy. Znam z animacji obrazu. Chodzi o odnotowywanie tylko stanów, które się zmieniają. Trzeba wiedzieć trochę więcej o tej zmienności, bo jeśli wszystko jednocześnie się zmienia co 5 sekund, to nie ma sensu tak robić. @azalut Nie wiem czy taka metoda znajdzie zastosowanie.

3

Hej,
ja myślę, że przy takiej sporej bazie warto robić partycje bazy (nie wiem czy takie pojęcie istnieje), wtedy wyszukiwanie idzie dużo szybciej.

Przykład:
Mamy w bazie np.

Piotrek
Barbara
Zofia
Paweł
Rozemunda
Rozalia

Wtedy wprowadzamy następującą partycję (w oparciu o słownik):

V['B'] = ['Barbara']
V['P'] = ['Paweł', 'Piotrek']
V['R'] = ['Rozalia', 'Rozemunda']
V['Z'] = ['Zofia']

Można wprowadzać też podziały bazy w oparciu o np. pierwsze trzy litery. Jakie są plusy ?? Łatwiej migrować takie bazy (szczególnie te większe, czasem się to robi tygodniami), tak mi się wydaje, ale może bredzę, w sumie nie wiem jak wygląda zapis takiej SQLowej bazy.

Nie wiem czy takie podziały są rozpatrywane (może w bazach NoSQL, ale też wiem nie za wiele), natomiast mogłoby to znacznie przyspieszyć wyszukiwania szczególnie w Technologiach Big Data. Niby mamy możliwość obliczania równoległego, ale jak odpowiednio uporządkujemy dane (względem najczęstszych wyszukiwań, są nawet takie objekty w IT, samobalansujące się drzewa, splay trees), to mamy dość znaczne przyspieszenie wykonywanych obliczeń. Nie mam wątpliwości, że od procesorów dużo ważniejsze są Struktury Danych.

1

@hurgadion: Jestem po znalezieniu rozwiązania i zakończeniu wątku: https://4programmers.net/Forum/Delphi_Pascal/314470-powrot_do_delphi_na_przykladzie_ulepszania_mojego_programu?page=1 Teraz raczej się wyłączę z 4p i będę kodował interpreter. Twoje podejście mnie zainteresowało. Będę miał drugi temat, jakbym się jednym znudził. Dam ci znać jeśli coś z twojego pomysłu będę poruszał na forum albo na Mikroblogu. Zresztą myślę, że spokojnie możesz wydzielić własny wątek na forum, dotyczący partcjonowania w gromadzeniu i odczytywaniu danych. Myślę, że jednak trzeba napisać trochę kodu najpierw. Jeśli będziesz miał kod np. w Pythonie, Delphi lub czymś innym, nawet w dobrze opisanym pseudokodzie, to na pewno znajdziesz więcej czytelników.

@azalut: Dzięki za zaproszenie do wątku. Wyczerpałem swoje pomysły. Starałem się też zebrać w jednym poście, to co mamy dane, bo ta wiedza była trochę rozrzucona po wątku. Wyłączam się. Powtórzę: jestem zwolennikiem bazy SQL, a na początek normalizacji bazy danych, co znacznie zmniejsza objętość STORAGE.

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