solteen schrieb am 14.08.2020 11:37:
Datenmengen waren nie ein Problem gewesen, tatsächlich sind die aber ein Problem für HBASE/H2, da hier der verteilte Speicher mit kostspieliger Kommunikation überwunden werden muss.
Die bestenfalls linerare Optimierung eines Zugriffes schaffe ich locker auch mit einem dicken 64 Core Server, das Problem bei großen Datenbeständen ist aber immer der IO. Unter der tut in einer H2 Knotenverteilung deutlich mehr weh auf auf meinem monolythischen DB Server.
Wie soll ein einzelner DB-Server den I/O auf mehr Disks verteilen können, als ein verteiltes System bestehend aus n Servern? Klar, wenn man alles erst mal auf einem Rechner hat, dann spart man sich den Netzwerk-I/O. Wenn man aber auf 32 Knoten parallel die Daten gelesen und voraggregiert hat, fällt der Netzwerk-I/O nur auf wenige Restdaten an.
Ansonsten sind - IMHO - 64 Cores ein sehr kleines System. Was mich an Spark reizt, ist dass ich für viele (nicht jeden) Workload die Anzahl der Executor Nodes verdoppele, und die Ausführungszeit oft (nicht immer) fast halbiere, mithin also fast lineare Skalierung erreiche.
Datensatz: 30*10^12 records, 10^6 neue Records jede Sekunde.