我正在考虑为以下内容构建架构，并想看看其他人对它的看法。
假设系统正在对收集到的每个用户的数据运行一些重要的算法(所以它不是简单的求和等)。有些用户会有10行数据，有些会有数万行。随着时间的推移，数据将是用户的地理位置。用户将超过1000 -1亿，并且每天都有许多用户的数据，对某些人来说可能每分钟都有。
每隔一段时间(1/5/15分钟，基本上是越快越好)，我想对每个用户的数据运行那个非平凡算法，它会吐出几个数字，然后报告出来。
建模的一种方法是存储在NoSQL数据库中，并在Akka集群上处理每个用户的数据。对DB有什么建议吗?这里的用户数据基本上是一个追加日志，一旦添加，数据就不会改变-但它一直在增长，并且一些用户的数据比其他用户多得不成比例。为了处理每个用户的数据，所有数据都需要加载到内存的某个地方，所以最好的情况是所有数据都在内存中，每隔一分钟重新处理一次——缺点是我需要tb的RAM来做这件事，如果内存服务器宕机，所有数据都需要重新加载，这将花费一段时间。
我目前正在研究一个类似的问题。我的系统大约有350亿条"记录"，每条记录大约有4-5个值。我目前能够在一台中档台式机(6核AMD，带有旋转盘片)上处理它们(一个不平凡的处理)大约20小时。
对于存储，我尝试了几乎所有的方法，从Postgres开始，转移到Cassandra, Hypertable。然后我意识到，我的用例只涉及按顺序重放数据，不需要在写或读中进行随机访问。我找到了《纪事报》，这正是我要找的。由于我没有足够的RAM来存储所有的数据，我需要从磁盘读取所有的数据，使用Chronicle，我可以达到每秒80万条记录的速度。我不知道Chronicle的当前版本，但我使用的版本创建了一个"索引"文件，我发现这是多余的。从那以后，我使用我自己的代码，这基本上是没有索引文件的Chronicle(内存映射文件)，这使我在平均30 MB/秒的旋转磁盘上达到130万条记录/秒。
存储的另一个要点是压缩数据。这有很大的不同。我为我的数据写了一个位对齐的压缩(当我把一个值压缩到3位时，它实际上只是写3位，而不是8位)。我发现使用字节边界压缩(在我的数据上)要差30-40%。例如，我希望来自一个人的GPS数据不会快速变化，因此每个连续的数据点可能只需要几个比特。
由于我不像您那样需要实时处理，所以我的主要目标是在一台(或至少几台)机器上尽可能地提高处理性能。我尝试过Akka, Hadoop(这只是一个PITA，不推荐)，围绕着Apache Spark玩。我的问题是，其中大多数都是在大型集群中运行的，并且在单个机器上没有我想要的那么快(或者至少，我不能使它们像我想要的那样快)。
我最终只是自己实现了一个处理链，正如我所说的，用 I/O处理大约500.000条记录/秒。因为我的数据很容易被分割成独立的分片，所以我可以在不协调节点的情况下进行扩展。
如果你有更多的数据，并且需要实时处理，你可能需要比我做得更多的扩展，然后个人性能可能不是最重要的部分。
无论如何，我希望这些能有所帮助。