tl;dr:
Use NoSQL for unstructured high volumes like: logging results, website search data etc.
Use Relational database: when you have a hierarchical structure like: the in and outs of the workflow of a sales process.
Well, in general, there is a lot around on the net on this subject. In general, in a relational database, the schematics are known "upfront" - although it can change over time, it's pretty static.
The big "benefit" of most Not-only-SQL is that they:
- do not require a fixed schematic and fixed relations to maintain data consistency. This means - e.g. a graph database - you can relate to other objects easier and more flexible or you have must a couple of independent tables.
- by design are capable of (better) horizontal scaling, which is - in bigger systems - is a big benefit in solving performance related issues. (Consider of to be a couple of independent tables to see why)
- data does not need to be (very) structured. This again, is a benefit if you need to include external data sources or typical unstructured data in your database.
note: there are multiple NoSQL database types, all with a different approach and their own pro's and con's.
Beyond my particular use case, when generally to prefer RDMBS over NoSQL for Time Series storing?
When using RDMBS you need to - at least - know your schematics upfront, and they are not expected to change very often.
You prefer RDMBS if:
- this kind of structured data and consistency checks are an intrinsic property of the data you are storing. For example: to maintain a warehouse inventory listing, keep track of work-hours, etc.
- your data store can be seen as an isolated authority. For example: a file system indexer or product test result storage.
When to prefer NoSQL over RDBMS?
You prefer NoSQL if:
- You cannot determine all relationships upfront and expect to add data, sources and relations on a frequent basis. Typical use cases are big-data stores, relationship stores; more concrete: social networking, advanced statistical correlations or frequently changing external data providers.
- You need high-scalability, which is more natural in most NoSQL systems.
- You just want to dump some data somewhere in a cloud in a more or less structured way. Create, for example, a simple table to hold settings records.
As for your use case:
It seems that your data structure is well known and fixed. This pleads for a relational database.
As for the high load: the data structure is known upfront as well. Nevertheless, there are some catches involved to deal with the high load. A relational database can be configured to coupe with this amount and perform very well, but NoSQL is usually better optimized for reading it.
So other then - it's a nice experience - I don't see a very strong argument to go for NoSQL (although I might be missing something [like performance]).
On the other hand, it does pose another question: Since you are monitoring 24/7; how often do you need data of last year, or the year before? Last month or week?
I am just asking because there are more options to coupe with these amounts of data. Historical data is often treated as a log and requested only "now and then". In that case, you could store data chucks on different servers, or even in different forms. For example, the 10kHz vibration data could also be stored on a dedicated server, in the form of a blob, or stored data stream.
