Terracotta + Compass = Hibernate + HSQLDB + JMS？

Question

我目前需要一個高性能的Java存儲機制。

這意味着：

1）我有10,000多個具有1 - 多關系的對象。

2）對象每5秒更新一次，在系統出現故障時最新的更新會持續存在。

3）對象需要在合理的時間內（1-5秒）查詢。 （IE：給我帶有這個時間戳的所有對象，或者給我這些位置邊界內的所有對象）。

4）對象需要在各種Glassfish安裝中可用。

目前：

我一直在使用JMS來分發對象，Hibernate作為ORM，以及HSQLDB來提供所需的可恢復性。

我對表現並不滿意。 特別是JMS的一部分。

在做了一些Stack Overflow研究之后，我想知道這是否是一個更好的解決方案。 請記住，我對Terracotta給我的經驗沒有任何經驗。

我會使用Terracotta在系統周圍分配對象，而其他東西需要能夠“查詢”這些對象的屬性。

這聽起來合理嗎？ 它會滿足這些性能限制嗎？ 我應該考慮哪些其他解決方案？

Answer 1

我知道這不是你問的問題，但是，你可能想從HSQLDB切換到H2 。 H2是一個相對較新的純Java DB。 它是由編寫HSQLDB的同一個人編寫的，他聲稱性能要好得多。 我現在用它已經有一段時間了，我很高興。 它應該是一個非常快速的過渡（添加一個Jar，更改連接字符串，創建數據庫）所以它值得一試。

總的來說，我相信在重寫不同架構中的應用程序之前，我試圖充分利用我所擁有的東西。 嘗試對其進行分析以首先確定瓶頸。

Answer 2

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

Terracotta將在Logical層進行擴展！ 您的問題似乎與處理邏輯無關。 它更多地圍繞存儲/通信點。

1. 找出你的瓶頸！ 對存儲/邏輯/ JMS處理時間和開銷進行基准測試！
2. 使用良好的JMS框架（例如ActiveMQ）和良好/優化的配置來解決JMS問題。
3. 也許分布式密鑰=>價值商店是你的朋友。 嘗試Project Voldemort ！
4. 如果你想留在Hibernate和HSQL，請查看Hibernate二級緩存和連接池（c3po，容器驅動......）！

Answer 3

幾個Terracotta用戶過去已經建立了這樣的系統，所以我可以通過存在的證據告訴你它可以完成。 :)

Compass確實支持使用Terracotta進行群集，因此可能對您有所幫助。 我懷疑你可以通過小心創建集群數據結構來獲得更快的速度。

關於您的要求和兵馬俑：

1）從兵馬俑的角度來看，10k物體非常小

2）5秒更新率似乎不是問題。 可能取決於有多少節點以及是否有任何自然分區可以利用。 所有更新都將持久。

3）1-5秒查詢時間似乎相當容易。 構建自己組織良好的數據結構以進行查找是棘手的部分。 顯然你想避免掃描所有數據。

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

如果你在Terracotta論壇上發帖，你可能會在這個問題上獲得更多Terracotta眼球。

Answer 4

我目前正致力於為非常（非常）快速的Key / Value分布式散列數據庫編寫客戶端，該散列數據庫提供集合+列表語義。 DB是C99並且需要GCC，現在我正在與好的舊Java網絡IO進行斗爭，以打破我目前每秒30,000次獲取/設置的障礙。 希望在一周內完成。 通過我的帳戶給我留言，我會在展示時間回來。

Answer 5

由於具有如此高的更新率，Lucene幾乎絕對不是您想要的，因為一旦文檔被索引，就無法更新文檔。 您必須將所有對象版本保留在索引中並選擇具有最新時間戳的對象版本，這將導致您的性能下降。

我不是數據庫專家，但我認為你應該研究最近在新聞上發布的任何一個分布式數據庫解決方案。 （CouchDB，Cassandra）

Answer 6

你沒有說你正在為JMS使用什么供應商，但如果你有一些瓶頸，我不會感到驚訝。 我無法從ActiveMq每秒獲得超過100條消息，無論我在確認，隊列大小等配置方面做了什么，我們都無法將CPU超過百分之幾。

解決方案是將許多查詢批處理為一個JMS消息。 我們有一個簡單的類，當它有200個查詢或達到超時（我們使用了20ms）時發送了一批消息，這使我們的消息吞吐量大幅增加。

Answer 7

也許你應該看看： Prevayler 。

你的對象總是在mem中。 對象的“更改”將保持不變。 您可以不時拍攝快照：每個對象都是持久的。

Answer 8

Terracotta + jofti =可查詢的持久性聚類數據結構搜索谷歌的terracotta querymap或訪問tusharkhairnar.blogspot.com查詢地圖博客您可能還想集成timasync以更新數據庫。 數據庫是你的記錄使用兵馬俑系統作為緩存和數據庫卸載機制你甚至可以批量異步更新，使其更快，以便我的db包含相當近期的數據

Tushar tusharkhairnar.blogspot.com

Answer 9

保證消息傳遞將比易失性消息傳遞慢得多。 鑒於每隔幾秒鍾更新一個對象，您可以考慮批量更新（比如說500個更改或時間說1-10毫秒），發送易失性消息，批量處理事務。 在這種情況下，您更有可能受到帶寬的限制。 調整您的用例您可能會發現較小的批量大小也可以有效地工作。 如果帶寬很關鍵（假設您有10 MB連接或更慢，那么您可以使用壓縮而不是JMS）

使用自定義解決方案（也可能更簡單）可以實現更高的性能，例如Hazelcast和JGroups是免費的（您可以添加一個節點來執行數據庫同步，因此您的主應用程序不會變慢）。 有商業產品處理大約50萬耐用消息/秒。