Вярвам, че буквално всички основни NoSQL бази данни ще поддържат това изискване, особено ако всъщност нямате голям обем данни (което повдига въпроса защо NoSQL?).
Въпреки това наскоро ми се наложи да проектирам и работя с NoSQL база данни за данни от времеви серии, за да мога да дам някои данни за този дизайн, който след това може да бъде екстраполиран за всички останали.
Избраната от нас база данни беше Cassandra , а нашият дизайн беше следният:
- Едно ключово пространство за всички „символи“
- Всеки символ беше нов ред
- Всеки запис беше нова колона за съответния ред
- Всяка стойност (може да бъде повече от една стойност) беше част от стойността на въведеното време
Това ви позволява да постигнете всичко, което сте поискали, най-вече да прочетете данните за един символ и да използвате диапазон, ако е необходимо (извиквания на диапазон от колони). Въпреки че казахте, че производителността не е критична, тя беше за нас и това също беше доста производително - всички данни за всеки отделен символ са сортирани по дефиниция (сортиране по име на колона) и винаги се съхраняват на един и същ възел (без комуникация между възли за прости заявки ). И накрая, този дизайн се превежда добре в други NoSQL бази данни, които имат динамични колони.
В допълнение към това, ето малко информация за използването на MongoDB (и ограничени колекции, ако е необходимо) за хранилище за времеви серии:MongoDB като база данни за времеви редове
И накрая, ето дискусия на SQL срещу NoSQL за времеви серии:https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Мога да добавя към тази дискусия следното:
- Кривата на обучение за NoSQL ще бъде по-висока, не получавате добавената гъвкавост и функционалност безплатно по отношение на „меките разходи“. Кой ще поддържа оперативно тази база данни?
- Ако очаквате тази функционалност да се разраства в бъдеще (или като повече полета да се добавят към всеки запис на време, или като много по-голям капацитет по отношение на броя на символите или размера на времевите серии на символа), тогава определено изберете NoSQL. Ползата от гъвкавостта е огромна и мащабируемостта, която получавате (с горния дизайн) както на базата „на символ“, така и на „брой символи“, е почти неограничена (казвам почти неограничена – максималните колони на ред са милиарди, максимум редове за ключово пространство е неограничен според мен).
