临时数据的最佳存储选项

Question

在我正在开发的应用程序的上下文中，我需要在有限的时间内存储相当多的数据 - 从对象桶的角度考虑场景 - 对于某些有限的时间对象在某些桶中然后他们转移到其他人和其他人......等等。对象（数百万的顺序）和存储桶（数千到数万）之间基本上存在n到m的关系

此存储层必须具有持久性，以便在应用/服务器发生故障时，我可以重新创建最后一个状态。

实施此类临时存储的最佳选择是什么

• 关系型SGBD - 我们目前正在使用PostgreSQL，它会是一个 选项？我主要关心的是它对这种反应的能力 使用场景。另一个SGBD可以选择吗？
• NOSQL持久性提供程序 - 我主要在Redis上思考 令人印象深刻的写入/读取速度，但其他DB，不一定来自 Key-Value系列也可能没问题。

由于

Answer 1

如果一个对象一次只能属于一个桶，那么这应该适合Postgres - 你只需要一个带有一组唯一桶标识符的buckets表，然后是对象＆＃ 39;表格将有一个currentbucket列，用于指示它们当前所属的存储区。

如果一个对象可以属于无限数量的存储桶，那么您仍然可以使用Postgres，但是您需要从对象中删除currentbucket列＆＃39;表，而是有一个bucketobjectjoin表，其中包含用于存储桶标识符的列和用于对象标识符的列。由于你已经在使用Postgres，我建议以这种方式实现它作为第一遍。如果您对性能不满意，则可以将bucketobjectjoin表缓存在Redis中（作为对象标识符键入的桶标识符的Set和/或{{1}键入桶标识符的对象标识符） - 您只需存储对象＆＃39; Redis中的键（不是完整的对象）因此内存不应成为问题，并且您可以让后台任务偶尔将Redis与Postgres的Set表同步，以防Redis服务器崩溃。 / p>

作为一个完整的nosql方法，您可以使用Cassandra来存储完整的对象; Cassandra像Redis一样支持bucketobjectjoin，但没有Redis的内存限制。

Answer 2

我们曾经在我们的SQL Server中保留临时数据，但后来我们转移到memcached，我们可以看到大的性能改进 - 主要是因为数据在内存而不在磁盘上。从去年开始，我们只使用Redis，它具有更多优势，例如支持更多类型，或者由于大小限制而无需破坏这些对象。

因此，如果您的数据很大且变化很大并且它也是暂时的，那么我建议使用redis。你可以拥有一个由1个主服务器和2个从服务器组成的redis集群，它将为你提供你正在寻找的HA。