There were challenges with the query language and the development interface. The query language, in particular, could be improved for better optimization. These challenges were encountered while using the Java SDK. 

The product is a NoSQL database. While working with it, we have to structure the table the way we want the query. We cannot get data from another table because, in Cassandra, we do not have any joins. Depending upon our schema, we can't make ORDER BY or GROUP BY clauses in the product. 

We should know the data we want before making the table. Only after that we can create the table. Or else we will face issues with our server, and we will have to fetch all the data and compute it in the programming language. It will become messy. It is the main drawback of the solution.

It can be difficult to analyze what's going on inside of the database relative to other databases. It can also be difficult to troubleshoot sometimes.

There could be more integration, and it could be more user-friendly.

Cassandra can improve by adding more built-in tools. For example, if you want to do some maintenance activities in the cluster, we have to depend on third-party tools. Having these tools build-in would be e benefit.

One of the issues with the solution is that you cannot drop write like you're able to in MongoDB and MySQL, where you can join tables. Cassandra doesn't have joins between tables so you need other tools for that. You need to read all the data and put in memory and then add the joins. That is the area where I think they need improvement. Secondly, for example, when setting up your cursor, you have to be very sure about the read mechanism, because if you're not following the read mechanism and mistakenly build a key that is no longer unique then you start overriding data. There are a lot of improvements they could make including on the OS.

Cassandra could be more user-friendly like MongoDB.

The solution is not easy to use because it is a big database and you have to learn the interface. This is the case though in most of these solutions.

The secondary index in Cassandra was a bit problematic and could be improved.

Cassandra can improve by having an ecosystem integrator that was more complete. For example, in some maintenance operations, we needed to deploy external tools to perform tasks that were not packaged alongside Cassandra.

If you have a requirement of aggregation and joints, Cassandra doesn't support a solution that can give the aggregation. If they were to include these two areas, the aggregation and the complex joints, it would improve the solution a great deal. 

For my use case, it was more than sufficient. I used most of the features, whatever was available. I'm not sure what else can be improved.

The stability of the solution and the documentation available can be improved. The solution is limited to a linear performance, which should be improved in the next release.

The clustering needs to be better; it is getting there.

Maybe they can improve their performance in data fetching from a high volume of data sets. 

We actually find HBase to be faster and better than Cassandra.

The disc space is lacking. You need to free it up as you are working.

Out-of-the-box monitoring, troubleshooting, and maintenance are involved. There are several utilities/interfaces available for use, but one would have to educate himself and learn the intricacies of managing a Cassandra cluster.

For example, we recently hired a consulting firm to make recommendations on how to approach maintenance and the health of the cluster and we're learning from that experience.

Row-level locking is not available; might be very helpful in update use cases.

The interface could definitely be improved. It's a technical database and for me the features are not user friendly. I also think it's quite an expensive solution and I hope over time with more implementations, this will improve.