对于一个可以回答的更直接的问题 - Druid 是否提供了与 Cassandra 相同的功能的超集，并且立即使用 druid 不是更好吗？对于所有用例？
根本不是，它们没有可比性。我们在这里谈论两种截然不同的技术。简单的方法是将 Cassandra 视为分布式存储解决方案，而将 Druid 视为分布式聚合器（即一个很棒的类似开源 OLAP 的工具 (: )。在我看来，您所指的帖子在某种意义上有点误导它比较了数据挖掘领域的两个项目，这不是 cassandra 的重点。
德鲁伊根本不擅长点查找。它喜欢时间序列，它的分区主要基于基于日期的段（例如，每小时/每月等段，可以根据大小进一步分片）。
Druid 根据预定义的聚合器预先聚合您的数据——这些聚合器是数字（例如，将您网站中的点击事件数量与每日粒度相加等）。如果一个人想从一个字符串中存储一个键查找来表示另一个字符串或一个确切的数字，那么 Druid 是他/他可以寻找的最糟糕的解决方案。
不确定这真的是一个 SO 类型的问题，但简单的答案是这是一个用例问题。简而言之，当 Druid 促进对实时摄取的数据进行非常快速的即席查询时，它就大放异彩了。它现在读取一致，并且您不受预先计算的查询的限制以获得速度。另一方面，你不能写入它保存的数据，你只能覆盖。
Cassandra（从我读过的内容来看；没有使用过）更像是一个最终一致的数据存储，它支持写入并且在预计算方面做得很好。它不打算在提供对相同数据的即席查询的实时访问的同时持续摄取数据。
事实上，这两者可以一起工作，正如 planetcassandra.org 在“Cassandra 作为 Druid 实时分析引擎的深度存储机制！”中所提出的那样。.
这取决于用例。例如，我将 Cassandra 用于聚合目的，即统计信息，例如用户、部门等域的聚合数量。具有可配置时间窗口的事件趋势（带宽、用户、应用程序等）。用 Druid 替换 Cassandra 对我来说效果很好，因为 druid 在聚合方面非常高效。另一方面，如果您需要具有最终一致性的时间序列数据，Cassandra 更好，您可以在其中获取事件的详细信息。
Druid 和 Elasticsearch 的结合非常有效地从我们的 Big Dada 基础架构中移除了 Cassandra。