最好的NoSQL方法來處理1億多條記錄

我正在一個項目上工作，我們正在批量加載和存儲Oracle數據庫中的大量數據，這是不斷通過Hibernate查詢這個1億多記錄表（讀取是比寫更頻繁）。爲了加快速度，我們使用Lucene進行一些查詢（特別是地理邊界框查詢）和Hibernate二級緩存，但那還不夠。我們仍然在針對Oracle的Hibernate查詢中遇到瓶頸（由於缺乏那麼多的內存，我們不會在Hibernate二級緩存中緩存超過1億個表實體）。最好的NoSQL方法來處理1億多條記錄

什麼額外的NoSQL解決方案（除Lucene外）我可以在這種情況下利用？

我想到的一些選項有：

使用分佈式的Ehcache（兵馬俑）對Hibernate第二級跨機器利用更多的內存，並減少重複緩存（現在每個虛擬機都有自己的高速緩存）。
要完全在內存中使用像H2這樣的SQL數據庫，但不幸的是，這些解決方案需要將100 + mln表加載到單個VM中。
使用Lucene進行查詢，使用BigTable（或分佈式hashmap）進行實體查找。什麼BigTable實現將適用於此？我正在考慮HBase。
使用MongoDB來存儲數據和按ID查詢和查找。

來源

2011-06-23 tsolakp

你能分解數據嗎？ –

如果通過ID查找是BigTable或MongoDB的潛在選項，爲什麼它不是SQL的潛在選項？ –

你的數據看起來像什麼？ – NightWolf

你能集團要求&分裂他們特有的一組數據&有一個（或一組服務器）過程，在這裏你可以在緩存中可用來提高性能的數據。使用10個表被處理

例如，

說，僱員&可用性數據，這些可以B A小組服務器（S）的處理時，配置休眠緩存加載&處理請求。

爲此，您需要負載均衡器（通過業務場景平衡負載）。

不知道這裏可以實現多少。

來源

2011-06-23 18:08:31

推薦Cassandra和ElasticSearch用於可擴展系統（1億對他們來說不算什麼）。使用cassandra處理所有數據和ES以進行臨時和地理查詢。然後你可以殺死你的整個遺留堆棧。您可能需要像rabbitmq這樣的MQ系統來實現Cass之間的數據同步。和ES。

來源

2011-06-23 18:44:46 sirmak

在100M記錄你的瓶頸可能是Hibernate，而不是Oracle。我們的客戶通常在我們基於Oracle的數據倉庫的各個事實表中擁有數十億條記錄，並且處理得很好。

你在桌子上執行什麼類型的查詢？

來源

2011-06-23 20:26:42 Olaf

下面是一個修改爲在內存數據庫中使用的同一方法的運行時間示例：一直到Oracle：116,201ms vs 20ms（根據yourkit，116201ms用於oracle.jdbc.driver.OraclePreparedStatement.executeQuery（））。我的目標是儘可能接近20ms。 – tsolakp

@Tsolak Petrosian：如果您的性能目標是在中等規模的100M記錄表上搜索幾十毫秒，那麼您可能應該考慮內存數據庫或緩存，而不僅僅是NoSQL。 – Olaf

正如您所建議的，MongoDB（或任何類似的NoSQL持久性解決方案）是適合您的。我們運行的測試數據集比您在MongoDB上建議的測試數據集要大得多，並且工作正常。特別是如果你閱讀過大量的MongoDB的分片和/或散佈閱讀跨越複製集成員將允許你顯着加快你的查詢。如果你的用例允許保持你的索引正確平衡，那麼接近20ms查詢的目標應該是可行的，而不需要進一步的緩存。

來源

2011-06-24 11:39:18

你也應該看看莉莉項目（lilyproject.org）。他們已經將HBase與Solr整合在一起。他們在內部使用消息隊列來保持Solr與HBase同步。這使他們能夠擁有高度可靠的數據存儲系統所支持的索引索引（分片和複製）的速度。

來源

2011-06-24 16:05:23 David

這真的取決於你的數據集。 NoSQL設計的首要規則是首先定義您的查詢場景。一旦你真正瞭解你想要如何查詢數據，那麼你可以看看那裏的各種NoSQL解決方案。分配的默認單位是關鍵。因此，您需要記住，您需要能夠有效地在節點機器之間分割數據，否則最終將得到一個水平可伸縮的系統，並且所有工作仍在一個節點上完成（儘管根據情況可以更好地進行查詢）。

您還需要回想一下CAP定理，大多數NoSQL數據庫最終是一致的（CP或AP），而傳統的關係數據庫管理系統是CA.這會影響你處理數據和創建特定事物的方式，例如密鑰生成可能會帶來詭計。

還記得比在HBase等系統中沒有索引概念。您的所有索引都需要由應用程序邏輯構建，並且任何更新和刪除都需要按照這種方式進行管理。有了Mongo，你可以在字段上創建索引並相對快速地查詢索引，也可以將Solr與Mongo集成。您不僅需要在Mongo中通過ID進行查詢，就像您在HBase中所做的那樣，它是一個列家族（又名谷歌BigTable樣式數據庫），您基本上擁有嵌套的鍵值對。

因此，再次涉及到您的數據，您想要存儲的內容，您計劃如何存儲它，最重要的是您希望如何訪問它。莉莉項目看起來很有希望。我參與的工作是從網絡上獲取大量數據，並存儲，分析，剝離，分析，分析，流式處理，更新等。我們不僅僅使用一個系統，而是使用多個系統這最適合手頭的工作。對於這個過程，我們在不同的階段使用不同的系統，因爲它使我們能夠在需要的地方快速訪問，提供了實時流式處理和分析數據的能力，重要的是，隨時瞭解所有事情（如數據丟失）系統是一件大事）。我使用Hadoop，HBase，Hive，MongoDB，Solr，MySQL甚至是優秀的舊文本文件。請記住，使用這些技術生產系統比在服務器上安裝Oracle要困難一些，某些版本不夠穩定，而且您確實需要首先進行測試。在這一天結束的時候，它確實取決於業務阻力水平和系統的關鍵任務性質。

到目前爲止，還沒有人提到過的另一種路徑是NewSQL--即水平可伸縮的RDBMSs ......有一些像MySQL集羣（我認爲）和VoltDB可能適合您的原因。

它再次涉及到了解您的數據和訪問模式，NoSQL系統也是非Rel，即非關係型，並更適合非關係型數據集。如果您的數據具有固有的關係性，並且您需要一些SQL查詢功能，而這些功能確實需要做笛卡爾產品（又名連接），那麼您最好堅持使用Oracle，並投入一些時間進行索引，分片和性能調整。

我的建議是實際上玩幾個不同的系統。看着;

的MongoDB - 文檔 - CP

的CouchDB - 文檔 - AP

Redis的 - 在存儲器鍵值（未列族） - CP

卡桑德拉 - Column Family - Available &分區容錯（AP）

HBase的 - 柱族 - 一致&分區容錯（CP）

Hadoop的/蜂房

VoltDB - 一個非常漂亮的產品，被分發和可能工作的關係數據庫中的案例（可能更容易）。他們似乎也提供了可能更適合產品環境的企業支持（即爲企業用戶提供安全感）。

任何方式，這是我的2c。玩弄這些系統真的是你找出真正適合你的案例的唯一方法。

來源

2011-07-04 17:07:40 NightWolf

最好的NoSQL方法來處理1億多條記錄

回答

相關問題