@Bithub:

Istnieje strona internetowa o nazwie bitcoinfees.earn.com

To najbardziej ******* strona jaka istnieje i niewiele mówi ludziom
https://mempool.space/
Ta prognozuje nawet ile trzeba dać fee by wejść do konkretnego bloku i od razu widać

Trzymać w skompresowanych pliakch logów a nie bazie danych.

Mam podobny problem (rozwiązany), tyle że więpszą prędkością przyrostu danych.

Używałem do tego postgresql z partycjami dziennymi ale problem z wydajnością był gdy partycji było 200 (trzeba się namęczyć z optymalizacją i SQL wtedy nie jest czytelny, nie można używać prepared statemat i robić SELECT na konkretnej partycji w miarę możliwości). Dodatko baza zaczęła zajmować sporo miejsca. Najgorsze były migracja bazy na nowsze wersje...

OstatnioPokaż całość

@bi-tek: A może influxdb? Specjalnie przygotowana baza pod tego typu dane

@5z7k9: Dla Hadoopa to raczej niewiele, wszak to raczej "offline storage", a nie baza danych "online". http://www.techrepublic.com/article/why-the-worlds-largest-hadoop-installation-may-soon-become-the-norm/ - "Yahoo! has more than 100,000 CPUs in over 40,000 servers running Hadoop, with its biggest Hadoop cluster running 4,500 nodes. All told, Yahoo! stores *455 petabytes* of data in Hadoop."

Z góry przepraszam za wrzucanie tu i ówdzie angielskiego słownictwa - niestety taki nawyk, bo to język, w którym "pracuję" i niektórych słów nawet nie znam w Polskiej wersji, albo dziwnie mi po Polsku brzmią :P

Co do pytań - poPokaż całość

@dagon_666: Nie do końca od nowa. Nie chcę się rozpisywać, ale spróbuję w skrócie opowiedzieć:

Hadoop / Spark (tego teraz używam) generuje dane "przyrostowo" - tzn. cały czas dodaje nowe dane do starych (tworząc nowe "zbiory" danych - słowo klucz to "immutable"), ale nigdy nie nadpisuje starych i na każdym etapie przetwarzania tworzy "snapshoty", od których potem potrafi "wznowić" przetwarzanie kolejnego dnia, a następnie ładuje dane do bazy nadpisując "stary" stan świata nowym (słowo klucz - "idempotent").

Tzn. wyobraź sobie system, który codziennie zbiera dane z czujników w - dajmy na to - fabryce, które raportują swój stan co sekundę i prezentuje je w postaci statystyk. Statystyki mają być godzinowe, dzienne, tygodniowe, miesięczne, kwartalne i roczne (statystyki "real time" też da się z tego zrobić i idealnie nada się tu Kafka, ale to by był jeszcze dłuższy wykład). To, jak taki system może działać to: wszystko bez przerwy trafia na HDFS / Amazon S3 do katalogu, który zawiera datę z dokładnością do godziny, następnie co godzinę odpala się "job" (Spark / Hadoop), który w jakiś sposób agreguje te dane. Najpierw te godzinowe (po zakończeniu godziny), potem (na koniec dnia) te dziennie, potem dzienne do miesięcznych itd. Następnego dnia nie musisz przeliczać od "dnia 0" wszystkich danych co godzinę, bo dla danych miesięcznych masz gdzieś przeliczone wszystkie dni - jeśli masz przeliczone 30 dni i dzisiaj jest 31, ostatni dzień miesiąca, to używasz gotowych danych z 30 dni (być może nawet wstępnie zagregowanych to "niepełnego" miesiąca) i przeliczasz od zera tylko ostatni dzień, a potem wszystko to agregujesz do miesiąca. Dzięki temu każdego dnia dostajesz tylko "deltę" (różnicę), którą ładujesz w ciemno - ma ona np. 10, 20, może 50 GB, a nie 30 TB (całaPokaż całość