我们正在研究存储和读取大量不可变数据（事件）的选项，我想就 Cassandra 是否适合提供一些反馈。
要求：
以任何其他方式查询数据不是主要问题，并且由于 Cassandra 是一个模式数据库，我认为当事件以多种不同形式出现时它是不可能的？ Cassandra 是否适合这种情况？如果有，有什么需要注意的吗？
【问题讨论】：
一年前我对一个“项目”（而是一个工具）有完全相同的要求，我使用了 Cassandra，我并不后悔。一般来说，它非常适合。您可以在 Cassandra 集群中容纳相当多的数据，并且性能令人印象深刻（尽管您可能需要调整）并且自然排序是一件好事。
与其表达使用它的好处，我更愿意专注于你在开始之前可能没有考虑到的可能的陷阱。
您必须考虑您的架构。数据自然地按集群键在一行内排序，在您的情况下，它将是时间戳。但是，您不能对不同行之间的数据进行排序。它们可能在查询后被订购，但不能以任何方式保证，所以不要考虑它。我相信在 2.1 之前有某种方法可以编写查询（使用order by 并禁用分页并允许过滤），但这会带来糟糕的性能，我认为现在甚至不可能。因此，您应该在查询端的行之间对数据进行排序。
如果您有多个变量类型（例如温度和压力）必须同时重放，并且您将它们放在不同的行中，这可能会出现问题。您必须获取具有不同变量类型的那些行，然后在查询端进行处理。另一种方法是将所有变量类型放在一行中，但仅过滤一个子集是一个需要解决的问题。
行长度被限制为 20 亿个元素，虽然这看起来很多，但对于时间序列数据来说确实不是无法达到的。尤其是因为您不想接近那 20 亿，所以最好将其保持在数亿以下。如果您放置一些参数来拆分行（一些增加索引或按日/月/年四舍五入），您也必须在查询逻辑中实现它。
首先在一个虚拟示例上对您的查询进行实验。您不能在查询中随意使用<、> 或=。 There are specific rules in SQL with filtering, or using the WHERE clause..
总而言之，这些事情看起来很重要，但是当您稍微了解一下 Cassandra 时，它们真的不会太麻烦。我在它们下划线只是为了提醒您。如果一开始有什么不合逻辑的，那就回过头来理解为什么会这样，以及关于数据分布和环形拓扑的整个理论。
不要对列中的集合抱有太多期望，它们的长度限制在 ~65000 个元素。
不要误以为批处理语句更快（这个是经典的：））
【讨论】：
根据您表达的要求，Cassandra 可能是一个不错的选择，因为它是一个写入优化的数据存储。时间序列是一种非常常见的模式，您可以定义一个聚类顺序，例如，在事件的时间戳上，以便按时间顺序检索所有事件。我发现this article on Datastax Academy 在想了解时间序列时非常有用。
可变数据结构这不是问题：您可以将数据存储在 BLOB 中，然后在应用程序内部对其进行解析（即，将其存储为 JSON 并在模型中读取），或者您甚至可以将数据存储在map，尽管 Cassandra 中的集合有一些注意事项，但最好注意。 Here you can find docs about collections in Cassandra 2.0/2.1。
Cassandra 与 SQL 数据库完全不同，尽管 CQL 有一些相似之处，但在使用模式上却存在根本差异。了解 Cassandra 的工作原理以及如何为数据建模以追求效率非常重要——Datastax 的一篇精彩文章解释了 the basics of data modelling。
简而言之：Cassandra 可能非常适合您，但在使用它之前需要一些时间来了解它的内部结构，因为如果您使用不当，它可能会成为一个坏野兽。
【讨论】：