我正在考虑为以下内容构建架构，并希望了解其他人对此的看法。
假设系统在每个用户收集的数据上运行一些非平凡的算法（因此它不仅仅是某些东西的总和等）。有些用户会有10行数据，有些会有数万行。随着时间的推移，数据将成为用户地理位置。将有超过10-100万用户，并且许多用户的数据每天都在进入，对某些用户来说可能是每分钟都有。
每隔一段时间（1/5/15分钟，基本上尽快），我想对每个用户数据运行那个非平凡的算法，这会吐出几个数字，然后是报道了。
建模的一种方法是存储在NoSQL数据库中并处理Akka集群上的每个用户数据。有关DB的任何建议吗？
这里的用户数据基本上是一个附加日志，一旦添加，数据就不会发生变化 - 但它会一直在增长，而且有些用户拥有的数据比其他用户多得多。为了处理每个用户的数据，所有这些都需要在某个地方加载到内存中，因此最好的情况是所有数据都在内存中并以一分钟的间隔重新处理 - 缺点是我需要太字节数RAM要做到这一点，如果内存服务器出现故障，所有数据都需要重新加载，这需要一段时间。
答案 0 :(得分：2)
我目前正在处理类似的问题。我的系统有大约35000万条＆＃34;记录＆＃34;，每条记录大约有4-5个值。我目前能够在一个中档桌面（6核AMD，带有旋转盘片）的大约20个小时内处理它们（一个非平凡的处理）。
对于存储，我尝试了几乎所有东西，从Postgres开始，转移到Cassandra，Hypertable。然后我意识到，我的用例只涉及按顺序重放数据，无需在写入或读取中进行随机访问。我找到了Chronicle，这正是我想要的。由于我没有足够的RAM来存储所有数据，我需要从磁盘读取所有内容，而使用Chronicle，我得到了大约800.000条记录/秒。
我不知道Chronicle的当前版本，但我使用的版本创建了一个＆＃34;索引＆＃34;我发现的文件是多余的。从那时起，我使用自己的代码，基本上是没有索引文件的Chronicle（内存映射文件），这使我在平均30 MB /秒的旋转磁盘上达到1.300.000记录/秒。 / p>
存储的另一个方面是压缩数据。它制造了巨大的差异。我为 bit 对齐的数据写了压缩（当我将值压缩为3位时，它实际上只写3位，而不是8位）。我发现使用字节边界的压缩比使用我的数据差30-40％。例如，我希望一个人的GPS数据不会快速变化，因此每个连续的数据点可能只需要几个位。
由于我不需要像您这样的实时处理，我的主要目标是在一台（或至少只是几台）机器上尽可能多的处理性能。我试过Akka，Hadoop（它只是一个PITA，不会推荐它），围绕着Apache Spark玩。我的问题是，大多数这些都是在一个大型集群中运行，并且在一台机器上没有我想要的那么快（或者至少，我无法按照我想要的速度制作它们。）< / p>
我最终只是自己实现了一个处理链，正如我所说的那样，使用 I / O处理约500,000条记录/秒。由于我的数据很容易分成独立的分片，因此我可以扩展而无需协调节点。
如果你有更多的数据，并且需要实时处理，你可能需要比我更多地扩展，然后个人表现可能不是最重要的部分。
无论如何，我希望其中一些有帮助。