Nie pozwól, aby skala przestrzenna (ponad 1000 urządzeń) zmyliła Cię co do skali obliczeniowej i/lub pamięci masowej. Kilkadziesiąt 35-bajtowych wstawek na sekundę to trywialne obciążenie dla każdego głównego systemu DBMS, nawet działającego na słabszym sprzęcie. Podobnie 142 miliony rekordów miesięcznie to tylko rzędu 1-10 gigabajtów pamięci miesięcznie, bez żadnej kompresji, w tym indeksów.
W komentarzu do pytania powiedziałeś:
„Chodzi o niezawodność, skalowalność i szybkość. Bardzo ważne jest, aby rozwiązanie łatwo się skalowało (autosharding MongoDB?) Po prostu wrzucając więcej węzłów, a szybkość jest również bardzo ważna
Niezawodność? Każdy główny DBMS może to zagwarantować (zakładając, że masz na myśli to, że nie uszkodzi twoich danych i nie ulegnie awarii - zobacz moje omówienie twierdzenia CAP na dole tej odpowiedzi). Prędkość? Nawet z pojedynczą maszyną, 10~100 razy większe obciążenie nie powinno stanowić problemu. Skalowalność? Przy obecnym tempie dane z całego roku, nieskompresowane, a nawet w pełni zindeksowane, z łatwością zmieściłyby się na 100 gigabajtach miejsca na dysku (podobnie ustaliliśmy, że szybkość wstawiania nie stanowi problemu).
W związku z tym nie widzę wyraźnej potrzeby egzotycznego rozwiązania, takiego jak NoSQL, czy nawet rozproszonej bazy danych — zwykła, stara relacyjna baza danych, taka jak MySQL, byłaby w porządku. Jeśli obawiasz się przełączenia awaryjnego, po prostu skonfiguruj serwer zapasowy w konfiguracji master-slave. Jeśli mówimy o 100- lub 1000-krotności aktualnej skali, po prostu podziel poziomo kilka instancji na podstawie identyfikatora urządzenia gromadzącego dane (tj. {indeks partycji} ={identyfikator urządzenia} modulo {liczba partycji}).
Pamiętaj, że opuszczenie bezpiecznych i wygodnych ograniczeń świata relacyjnych baz danych oznacza porzucenie zarówno modelu reprezentacyjnego i jego bogaty zestaw narzędzi . To znacznie utrudni „złożoną eksplorację danych” — nie musisz tylko umieszczać danych w bazie danych, musisz je także wydobyć.
Biorąc to wszystko pod uwagę, MongoDB i CouchDB są niezwykle proste we wdrożeniu i pracy. Są również bardzo zabawne i sprawią, że staniesz się bardziej atrakcyjny dla dowolnej liczby osób (nie tylko programistów – także kierownictwa!).
Powszechnie uważa się, że z trzech sugerowanych przez Ciebie rozwiązań NoSQL Cassandra jest najlepsza w przypadku dużej ilości wstawiania (oczywiście, relatywnie rzecz biorąc, nie wydaje mi się, że masz). duża objętość wstawek — ta funkcja została zaprojektowana z myślą o Facebooku ); można temu przeciwdziałać, ponieważ trudniej się z tym pracuje. Więc jeśli nie masz jakichś dziwnych wymagań, o których nie wspomniałeś, odradzałbym je w twoim przypadku użycia.
Jeśli jesteś pozytywnie ustawiony na wdrożenie NoSQL, możesz rozważyć twierdzenie CAP. Pomoże Ci to wybrać między MongoDB a CouchDB. Oto dobry link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Wszystko sprowadza się do tego, co rozumiesz przez „niezawodność”:MongoDB zamienia dostępność na spójność, podczas gdy CouchDB zamienia spójność na dostępność . (Cassandra pozwala na dopracowanie tego kompromisu dla każdego zapytania, określając liczbę serwerów, które muszą zostać zapisane/odczytane, aby zapis/odczyt zakończył się sukcesem; AKTUALIZACJA:teraz też CouchDB, z BigCouch! Bardzo ekscytujące...)
Powodzenia w Twoim projekcie.
