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.
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.