MongoDB vs Cassandra - Which one is best for Internet of Things Data [closed]

Question

Recently one of my client asked me to take a decision on choosing database for one Industrial project (Where there may be lots of sensors including Camera for photos or Videos) - Where data flow is huge.

I'm thinking about to either use MongoDB or Cassandra. Moreover, my client is asking to choose DB whose programming language bit similar to T-SQL (SQL Server) [I'm not sure if any one of these language is similar to T-SQL or NOT - if not, then may need to make client understand this] - May be they have people who can understand T-SQL.

Could any one please tell me which one would be best and why? Is there any other DB I can use for this?

Answer 1

tldr; I'm going to say that Cassandra is probably the better choice for you.

may be lots of sensors including Camera for photos or Videos] - Where data flow is huge.

Due to its log-based nature, tracking sensor data is a good use case for Cassandra. The ability to handle large amounts of write throughput is a strength of Cassandra, and you can scale linearly by adding as many nodes as necessary to handle the workload. You will also find that sharding replicas over multiple nodes will be easier to configure with Cassandra (due to its implementation of virtual nodes).

client is asking to choose DB whose programming language bit similar to T-SQL

The Cassandra Query Language (CQL) is very similar to SQL. Several of the commands are exactly the same. This was done intentionally to try and lower the learning curve for Cassandra.

However, this is also a double-edged sword. While similar in feel, CQL and SQL are not the same. The majority of my rep on StackOverflow comes from helping developers with CQL queries that they approached with a SQL/relational mindset. Long story short, you can get yourself into trouble by making SQL-based assumptions about CQL, so you and/or your client will need to be cautious about that.

MongoDB uses a Javascript based query language. While not even remotely similar to SQL, experienced Javascript hackers tend to do well with it.

Some additional cautionary points about Cassandra:

• The same log-based nature that allows Cassandra to perform well while handling large amounts of write throughput, also makes it troublesome when it comes to deleting data. If you plan to delete data often, then Cassandra may not be the best fit.
• The data model is everything with Cassandra. You will have to take a table-based design approach to modeling. This means that you could potentially have a table built for each query that could be performed, and usually means denormalizing and/or duplicating data across a few tables. MongoDB works the same way, but it's been my experience that Cassandra is less-forgiving if you have a bad data model.
• Secondary indexes can sometimes help with query flexibility. But they have a reputation as being a performance-killer, so it's best to avoid them with Cassandra. If you build an appropriate data model, you shouldn't need them at all. I don't have any experience using them at scale with MongoDB, but they may perform better.

In summary, Cassandra sounds like a better fit for you (assuming you build a good data model and don't delete often), as it fits these criteria:

• Ability to handle large amounts of data.
• Many existing Cassandra use cases for sensor-based data.
• CQL should pass as a "SQL familiar" query language.

Answer 2

First of all: If your customer asks you something you can not thoroughly answer based on your own knowledge and experience, it is very bad business practice to make any suggestion, imho.

Remarks on Cassandra vs/and MongoDB

The requirements are a bit squishy, too, to say the least.

Where data flow is huge

If properly set up, both Cassandra and MongoDB can handle huge loads of data. Again: if properly set up. Both DBMS require quite some knowledge and experience to handle load efficiently. Since it seems that both are non-existant either on your side not from the customers side, hiring someone who has both knowledge and experience is inevitable short to mid-term. Such a high-impact technology decision should be based on facts and analysis, not on mere assumptions or skimmed documentation.

Moreover, my client is asking to choose DB whose programming language bit similar to T-SQL

Of course he is, since the customer assumes that knowledge existing in the company can be reused. More often than not, that is a erroneous inference as @Aaron eloquently described. I strongly suggest not making a decision by access language, but by fitness for the intended purpose. As written before, this fitness has to be determined by analyzing the use cases and other requirements.

Alternatives

Albeit not explicitly stated, presumably we are talking of time series data. It might be worth to take a look at InfluxDB, which is one part of a whole collection of software to deal with time series data, from collecting to meta-analysis.