2

我目前需要一个高性能的java存储机制。

这表示：

1)我有 10,000 多个具有 1 - 多关系的对象。

2)对象每 5 秒更新一次，最近的更新在系统故障的情况下保持不变。

3）对象需要在合理的时间内（1-5秒）可查询。（即：给我所有具有此时间戳的对象或给我这些位置边界内的所有对象）。

4)对象需要在各种 Glassfish 安装中可用。

目前：

我一直在使用 JMS 来分发对象，使用 Hibernate 作为 ORM，并使用 HSQLDB 来提供所需的可恢复性。

我对表演并不完全满意。尤其是其中的 JMS 部分。

在做了一些 Stack Overflow 研究之后，我想知道这是否是一个更好的解决方案。请记住，我对 Terracotta 给我的东西没有经验。

我会使用 Terracotta 在系统中分布对象，而其他东西需要能够“查询”这些对象的属性。

这听起来合理吗？它会满足这些性能限制吗？我应该考虑哪些其他解决方案？

4

9 回答 9

4

我知道这不是您所要求的，但是，您可能想从从 HSQLDB 切换到H2开始。H2 是一个相对较新的纯 Java DB。它是由编写 HSQLDB 的同一个人编写的，他声称性能要好得多。我已经使用了一段时间了，我对它非常满意。这应该是一个非常快速的过渡（添加一个 Jar，更改连接字符串，创建数据库），所以值得一试。

总的来说，我相信在用不同的架构重写应用程序之前尝试充分利用我所拥有的东西。尝试对其进行分析以首先识别瓶颈。

于 2009-04-06T03:59:10.257 回答
2

起初，Lucene 不是你的朋友。（只读）

兵马俑将在逻辑层进行缩放！您的问题似乎与处理逻辑无关。它更多地围绕存储/通信点。

  1. 找出你的瓶颈！对存储/逻辑/JMS 处理时间和开销进行基准测试！
  2. 使用良好的 JMS 框架（例如 ActiveMQ）和良好/调整的配置来解决 JMS 问题。
  3. 也许分布式键=>值存储是您的朋友。试试伏地魔计划！
  4. 如果您喜欢使用 Hibernate 和 HSQL，请查看 Hibernate 二级缓存和连接池（c3po、容器驱动...）！
于 2009-04-06T13:11:21.130 回答
2

过去有几个 Terracotta 用户构建了这样的系统，所以我可以通过存在证明告诉你它可以完成。:)

Compass 确实支持使用 Terracotta 进行集群，因此可能会对您有所帮助。我怀疑只要注意创建集群数据结构的方式，您可能会变得更快。

关于您的要求和兵马俑：

1) 从兵马俑的角度来看，10k 个物体非常小

2) 5 秒的更新率似乎不是问题。可能取决于有多少节点以及您是否可以利用任何自然分区。所有更新都将是持久的。

3) 1-5 秒的查询时间似乎很容易。为查找构建自己的组织良好的数据结构是棘手的部分。显然，您希望避免扫描所有数据。

4) Terracotta 目前支持 Glassfish v1 和 v2。

如果您在Terracotta 论坛上发帖，您可能会得到更多关于这个问题的 Terracotta 眼球。

于 2009-05-27T14:31:49.840 回答
1

我目前正在为提供集合+列表语义的非常（非常）快速的键/值分布式哈希数据库编写客户端。数据库是 C99 并且需要 GCC，现在我正在与旧的 Java 网络 IO 作斗争，以打破我目前每秒 30,000 次获取/设置的障碍。希望一周内完成。通过我的帐户给我留言，我会在演出时间回来。

于 2009-04-06T03:41:39.910 回答
1

凭借如此高的更新率，Lucene 几乎绝对不是您想要的，因为一旦文档被编入索引，就无法更新它。您必须将所有对象版本保留在索引中并选择具有最新时间戳的版本，这会影响您的性能。

我不是数据库专家，但我认为您应该研究最近出现在新闻中的任何一种分布式数据库解决方案。（沙发数据库，​​卡桑德拉）

于 2009-04-06T06:38:48.843 回答
1

您没有说您为 JMS 使用的供应商是什么，但如果您在那里遇到瓶颈，我不会感到惊讶。我每秒从 ActiveMq 收到的消息不能超过 100 条，无论我在确认配置、队列大小等方面尝试什么，我们都无法将 CPU 占用超过百分之几。

解决方案是将许多查询批处理到一个 JMS 消息中。我们有一个简单的类，当它达到 200 个查询或达到超时（我们使用 20 毫秒）时发送一批消息，这使我们的消息吞吐量显着增加。

于 2009-04-06T07:35:58.520 回答
1

也许你应该看看：Prevayler。

你的对象总是在内存中。您的对象的“更改”将被保留。您可以不时拍摄快照：每个对象都被持久化。

于 2009-04-06T11:26:50.867 回答
0

有保证的消息传递将比易失的消息传递慢得多。鉴于每个对象每隔几秒更新一次，您可能会考虑批量更新（比如 500 次更改或时间说 1-10 毫秒的值），发送易失性消息，并批量处理您的事务。在这种情况下，您更有可能受到带宽的限制。调整您的用例，您可能会发现较小的批量大小也可以有效地工作。如果带宽很关键（假设您有 10 MB 或更慢的连接，那么您可以使用 JMS 上的压缩）

您可以使用自定义解决方案（也可能更简单）获得更高的性能，例如 Hazelcast 和 JGroups 是免费的（您可以添加一个执行数据库同步的节点，这样您的主应用程序就不会变慢）。有一些商业产品可以处理大约 50 万条持久消息/秒。

于 2009-05-27T06:02:11.707 回答
0

Terracotta + jofti = 可查询的持久集群数据结构 在 google 上搜索 terracotta querymap 或访问 tusharkhairnar.blogspot.com 的 querymap 博客 您可能还需要集成 timasync 以更新您的数据库。数据库是您的记录系统，使用 terracotta 作为缓存和数据库卸载机制，您甚至可以批量异步更新以使其更快，以便我的 db 包含相当新的数据

Tushar tusharkhairnar.blogspot.com

于 2009-07-03T18:07:51.710 回答