topology - 一致性拓扑建议

Question

要缓存的数据:

100 Gb 数据

大小为 500-5000 字节的对象

平均每分钟更新/插入 1000 个对象(峰值 5000)

需要对生产和测试中的 Coherence 拓扑提出建议(与备份一起分发)

服务器数量

每个服务器的节点

每个节点的堆大小

问题

与缓存数据使用的内存相比，每个节点需要多少可用内存(假设不可能使用 100%)

每个缓存元素 1-2 个额外索引会产生多少开销？

我们不知道将完成多少读取操作，该解决方案将被客户端使用，其中低响应时间至关重要(不仅仅是数据一致性)并且取决于每个用例。缓存将通过以固定频率轮询并填充缓存从 DB 更新(因为缓存是数据主控，而不是使用缓存的系统)。

Answer 1

为 Coherence 调整 JVM 大小的经验法则是，假设 1 个备份，数据是堆的 1/3:1/3 用于缓存数据，1/3 用于备份，1/3 用于索引和开销。

调整大小的最大困难是没有很好的方法来估计索引大小。您必须尝试使用​​真实世界的数据并进行测量。

JDK 1.6 JVM 的经验法则是从 4GB 堆开始，因此您需要 75 个缓存服务器节点。有些人已经成功地使用了更大的堆 (16GB)，因此值得尝试。对于大堆(例如 16GB)，您不应该需要 1/3 的开销，并且可以容纳超过 1/3 的数据。对于大于 16GB 的堆，垃圾收集器调整变得至关重要。

为了获得最佳性能，每个节点应该有 1 个核心。

服务器机器的数量取决于可管理性、容量(核心和内存)和故障的实际限制。例如，即使你有一个可以处理 32 个节点的服务器，当一台机器出现故障时，你的集群会发生什么？集群将是机器安全的(备份不在同一台机器上)，但鉴于要移动到新备份的大量数据，恢复将非常缓慢。另一方面，75 台机器很难管理。

我已经看到 Coherence 对于 1K 对象放置的延迟为 250 微秒(不是毫秒)，包括网络跃点和备份。因此，您正在寻找的插入和更新数量应该是可以实现的。使用多个线程插入/更新进行测试，并确保您的测试客户端不是瓶颈。