Baza danych, wiele danych statystycznych, map reduce

Cześć.

Mam jedną tabelkę z wieloma wierszami (dane statystyczne) na których jeden pojedynczy postgres się nie wyrabia.

Szukam bazy, która będzie wstanie rozłożyć obciążenie na kilka maszyn a jednocześnie wspiera update'y i ma funkcje agregujące. sortowanie też byłoby miło.
Coś co nie ma kosmicznych wymagań, jest wspierane i nietrudne w konfiguracji.
Ilość tych danych nie jest aż tak duża, rozwiązania typu cloudera impala i ichniejsze wymagania to dla mnie overkill.

Proszę o sugestie. mongo db, postgres w klastrze -ktoś ma z tym doświadczenia , jakieś fajne linki?
Dobrze byłoby, żeby na 3 maszyny przynajmniej jedna mogła paść i dalej wszystko działało.

a grafy ? jesteś to w stanie tak zamodelować ? więcej tam piszesz czy czytasz ? neo4j może mieć wiele nodów, no problemo

więcej czytam , ale nie mam tam żadnych relacji. poczytam może o grafach i zobaczę czy jestem w stanie to tak zamodelować. aczkolwiek wątpię

najbardziej popularne to będzie mongo i cassandra(a jak cos sobie pasc od czasu do czasu, to tutaj cassandra sie chwali), datastax ma darmowe kursy (na wideło)

okey czyli tak jak mi się wydawało. no dobra czyli będę musiała poczytać o tym. dzięki zdecydowany xdd

Nie mnie Cię uczyć, ale może baza danych nie radzi sobie ze: znakami i wyrażeniami specjalnymi lub zbyt dużymi obiektami wczytywanymi do bazy danych (zdarza się przy imporcie z excela i innych).
Szybkość transferu można można poprawić stosując indeksy. Można również wykorzystać DML, lub jak os nię tam nazywa do importowania danych.

"Dobrze byłoby, żeby na 3 maszyny przynajmniej jedna mogła paść i dalej wszystko działało" taką usługę zapewnia np. VMware High Availability (HA). Niestety jak zwykle wszystko zależy od funduszy jakimi dysponujecie bo nie jest to tanie rozwiązanie. Ogólnie jego idea polega na tym, że w klastrze możesz mieć 2 lub więcej serwery fizyczne na których stoi maszyna wirtualna z Twoją bazą. W razie problemów z jednym fizycznym serwerem, system sam przenosi dane na drugą maszynę i przełącza w sposób niezauważalny użytkowników.

Akurat sama Cassandra to się do tego nie będzie nadawała w ogóle, bo Cassandra jest systemem do obsługi obciążeń transakcyjnych, a nie analitycznych. Nie ma sortowania, złączeń, grupowania itp.

Cassandra + Spark (albo Hadoop) będzie działać, ale dość powoli, bo o ile hurtowe skanowanie rowków wprawdzie można rozbić na wiele maszyn, to sama Cassandra nie jest w stanie ich dostarczać tak szybko jak system dedykowany do operacji hurtowych. Format danych jest zorientowany na rowki, a nie kolumny, a i sposób ich przetwarzania jest zoptymalizowany pod wyszukiwanie po kluczu a nie operacje hurtowe. Jeden węzeł Cassandry jest w stanie przetwarzać raptem typowo jakieś 20k-100k rowków / sekundę (zależnie od wielkości rowka, szybkości dysków, mocy procesora, YMMV), przy czym wydajność skaluje się liniowo z liczbą węzłów. Ta opcja jest dostępna zarówno w DSE, jak i jako FOSS. Tylko że w wersji FOSS, musisz ręcznie zainstalować sobie Sparka, Cassandrę i połączyć naszym konektorem, w DSE masz to out-of-the-box.

Jeżeli to nie musi być produkcyjne, ale chcesz zrobić to poprawnie i osiągnąć dobrą wydajność i pełne HA, to możesz się pokusić o DSE 5.0, które wyjdzie niedługo i pożenienie tego z Parquetem już we własnym zakresie. Trochę eksperymentalne, ale znacznie prostsze do postawienia niż Spark na Parquet na HDFS[1]. No i daje gwarancję, że jak jeden z trzech padnie, to działa dalej, czego nie można powiedzieć o HDFS[1] ani Mongo[2]. W razie czego służę pomocą na priv.

/// Dopisane później:
Teraz dopiero zobaczyłem, że masz mało danych, a skomplikowane analizy. W tej sytuacji Cassandra + Spark (lub DSE) jest idealnym rozwiązaniem. Spark zrównolegli najbardziej rozbudowane zapytania, do tego potrafi dobrze trzymać wszystko w pamięci. Cassandra zapewnia porządne HA.

[1] HDFS ma Single-Point-of-Failure w postaci NameNode'a. Konfiguracja HA wymaga kilku NameNode'ów oraz dodatkowo JournalNode'ów współdzielących wolumen NFS.

[2] Mongo ma architekturę master-slave, gdzie teoretycznie mastera można w dowolnym momencie zastąpić slavem, ale nie jest to proces ani niezawodny, ani łatwy do poprawnego skonfigurowania i nie wiadomo nawet, czy teoretycznie poprawny wiadomo, że teoretycznie niepoprawny:
https://aphyr.com/posts/284-call-me-maybe-mongodb
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

@Krolik dzięki za post. Przeglądając ostatnio forum natrafiłam kilka razy na twoje wypowiedzi na różne tematy i zazdroszczę wiedzy. Jednocześnie widzę, że nie przepadasz za mongo, ale muszę z tym mongo przekonać się empirycznie.