如果我试着看一下你的数据结构和数据访问模式，你会发现每个消息都有一个消息id，它的内容，还有很多计数器，每次有人打开它时都会更新，可能还有一些信息，比如用户id/打开它的人的电子邮件。
因为这些记录在每次打开一封邮件时都会更新，所以我相信写邮件的次数是相当高的。假设每封邮件平均每天被打开10次，那么每天的写邮件量将达到1000万至2000万封，邮件数量将达到100万至200万封。
与阅读相比，我不确定你的阅读模式，但如果它被用于分析目的，或者显示在一些 Jmeter 板上，它可能一天会被阅读几次。与写操作相比，基本上读操作的效率要低得多。
也就是说，如果您的read查询模式是这样的，即您总是使用消息id进行查询，那么cassandra/hbase是您的最佳选择。如果不是这样，而且你有不同类型的查询，或者你想做很多分析，那么我更喜欢mongodb。
ElasticSearch并不是一个真正的数据库，它更多的是一个查询引擎。而且在很多情况下，数据丢失发生在es中。如果您打算将其作为主要数据存储，那么ElasticSearch/elk不是一个好的选择。
你可以看看这个视频来帮助得出一个结论，在什么样的情况下哪个数据库是最好的。或者，可以在@codekarle的网站上查看摘要

elk stack（elastic search、logstash、kibana）是最好的解决方案。就我所使用的elk堆栈而言，它对日志处理速度很快。
Cassandra绝对不是正确的选择。
您可以使用mongodb，因为大多数查询都是get查询。
但我有几点要解释为什么ElasticSearch在日志处理方面比mongo更强大。
全文搜索：ElasticSearch实现了很多功能，如自定义的分词、自定义词干、分面搜索等。
模糊搜索：模糊搜索有利于拼写错误。即使你有拼写错误，你也能找到你要找的东西。
速度：ElasticSearch能够以极快的速度执行复杂的查询。
顾名思义，ElasticSearch就是为了搜索而进行的。而在mongo中搜索不如ElasticSearch那么快。
但保持ElasticSearch也有其自身的问题。
参考：https://apiumhub.com/tech-blog-barcelona/elastic-search-advantages-books/https://interviewbubble.com/elasticsearch-pros-and-cons-advantages-and-advantages-of-elasticsearch/
谢谢，我想这会有帮助的。