Wierzę, że dosłownie wszystkie główne bazy danych NoSQL będą wspierać to wymaganie, zwłaszcza jeśli w rzeczywistości nie masz dużej ilości danych (co nasuwa pytanie, dlaczego NoSQL?).
To powiedziawszy, musiałem ostatnio zaprojektować bazę danych NoSQL dla danych szeregów czasowych i pracować z nią, więc mogę dać pewne dane wejściowe do tego projektu, które można następnie ekstrapolować na wszystkie inne.
Wybraną przez nas bazą danych była Cassandra , a nasz projekt wyglądał następująco:
- Pojedyncza przestrzeń klawiszy dla wszystkich „symboli”
- Każdy symbol był nowym wierszem
- Za każdym razem wpis był nową kolumną dla odpowiedniego wiersza
- Każda wartość (może być więcej niż pojedynczą wartością) była częścią wartości we wpisie czasu
Pozwala to osiągnąć wszystko, o co prosiłeś, w szczególności odczytać dane dla pojedynczego symbolu i użyć zakresu, jeśli to konieczne (wywołania zakresu kolumn). Chociaż powiedziałeś, że wydajność nie była krytyczna, to było dla nas i to również było całkiem wydajne - wszystkie dane dla dowolnego pojedynczego symbolu są z definicji sortowane (sortowanie według nazw kolumn) i zawsze przechowywane w tym samym węźle (brak komunikacji między węzłami dla prostych zapytań ). Wreszcie, ten projekt dobrze przekłada się na inne bazy danych NoSQL, które mają dynamiczne kolumny.
Oprócz tego, oto kilka informacji na temat używania MongoDB (i w razie potrzeby ograniczonych kolekcji) do przechowywania szeregów czasowych:MongoDB jako baza danych szeregów czasowych
Na koniec omówienie SQL vs NoSQL dla szeregów czasowych:https://dba.stackexchange.com/questions/7634/timeseries-sql-lub-nosql
Do tej dyskusji mogę dodać:
- Krzywa uczenia się dla NoSQL będzie wyższa, nie otrzymasz dodatkowej elastyczności i funkcjonalności za darmo w postaci „kosztów miękkich”. Kto będzie operacyjnie wspierać tę bazę danych?
- Jeśli spodziewasz się, że ta funkcjonalność będzie się rozwijać w przyszłości (albo w miarę dodawania większej liczby pól do każdego wpisu czasu, albo znacznie większej pojemności pod względem liczby symboli lub rozmiaru szeregu czasowego symbolu), zdecydowanie wybierz NoSQL. Korzyść z elastyczności jest ogromna, a skalowalność, którą otrzymujesz (przy powyższym projekcie) zarówno na podstawie „na symbol”, jak i „liczby symboli” jest prawie nieograniczona (mówię prawie bez ograniczeń - maksymalna liczba kolumn na wiersz jest w miliardach, maksymalna rzędów na kluczową przestrzeń jest nieograniczona, jak sądzę).
