NoSQL和AdHoc查詢 - 百萬行

Question

我目前運行一個MySQL支持的網站，用戶在每次有人完成廣告時都會宣傳廣告並獲得收入。每次有人查看廣告（「展示」）時，我們都會記錄一次，每次用戶點擊添加（「點擊」）時，以及每次有人完成廣告（「潛在客戶」）。

由於我們獲得瞭如此多的流量，因此我們在這些相應的表中都有數百萬條記錄。然後，我們必須查詢這些表以讓用戶看到他們賺了多少，所以我們最終在一個請求中多次對數百萬和數百萬行執行多個查詢，併發數百次。

我們正在尋求擺脫MySQL並轉向鍵值存儲或其他方面。我們需要一些能夠讓我們存儲所有這些數以百萬計的行，並以毫秒爲單位來查詢它們，最重要的是，使用adhoc查詢來查詢任何單個列，因此我們可以執行如下操作：

FROM leads WHERE country = '美國' AND USER_ID = 501（NoSQL的等同，很明顯）

FROM點擊WHERE ad_id = 1952 USER_ID = 200和國家= 'GB'

等

有沒有人有什麼好的建議？我正在考慮MongoDB或CouchDB，但我不確定他們是否可以每秒多次處理數百萬條記錄以及我們需要的特殊查詢類型。

謝謝！

Answer 1

如果您的工作集可以放在內存中，並且索引文檔中的正確字段，那麼您將全部設置。你的要求並不是非常典型的，我相信有適當的硬件，正確的收藏設計（denormalize！）和索引你應該很好。閱讀Mongo查詢，並使用explain()來測試查詢。遠離IN和NOT IN條款，這將是我的建議。

Answer 2

有了這些要求，如果您遇到加載問題，您可能會更好地堅持使用SQL並設置複製/集羣。您可以在文檔數據庫上設置索引，以便可以查詢這些查詢，但是您對當前系統沒有任何收穫。

NoSQL系統通常會忽略關係系統的一些更復雜的功能，從而提高性能。這意味着只有在您的方案不需要這些功能時，它們纔會有所幫助。對錶格數據運行即席查詢正是SQL設計的目的。

Answer 3

CouchDB的map/reduce是incremental這意味着它只處理一次文檔並存儲結果。

讓我們暫時假設CouchDB是世界上最慢的數據庫。有數百萬行的第一個查詢需要20個小時。聽起來很糟糕。但是，您的第二個查詢，第三個查詢，第四個查詢和第一個查詢將花費50毫秒，可能包括100個HTTP和網絡延遲。

你可以說CouchDB沒有通過基準測試，但在硬敲門的學校獲得榮譽。

我不擔心性能，而是如果CouchDB可以滿足您的特定查詢需求。 CouchDB想知道會發生什麼查詢，所以它可以在查詢到達之前預先做好工作。當查詢確實到達時，答案已經準備就緒，並且結束！

您所有的示例都是可能與CouchDB。所謂的合併加入（很多平等條件）是沒有問題的。但是，CouchDB不能同時支持多個不等式查詢。對於18-40歲之間點擊次數少於10次的用戶，您無法在單個查詢中詢問CouchDB。

關於CouchDB的HTTP和Javascript界面​​的好處是，很容易做一個快速的可行性研究。我建議你試試看！

Answer 4

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

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

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

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

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

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

我的建議是實際上玩幾個不同的系統。然而，對於您的用例，我認爲Column Family數據庫可能是最好的解決方案，我認爲有幾個地方對類似的問題實施了類似的解決方案（我認爲NYTimes使用HBase監控用戶頁面點擊）。另一個很好的例子是Facebook和類似的，他們正在使用HBase。這裏有一篇非常好的文章，可以幫助你一路走，並進一步解釋以上幾點。 http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html

最後一點是，NoSQL系統不是全部，最終都是。把你的數據放入NoSQL數據庫並不意味着它將比MySQL，Oracle甚至文本文件更好地執行...例如，看到這篇博文：http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html

我會看看;

的MongoDB - 文檔 - CP

的CouchDB - 文檔 - AP

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

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

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

Hadoop的/蜂房 - 也看看Hadoop的流...

Hypertable的 - 另一個CF CP DB。

VoltDB - 一個非常好看的產品，分佈式的關係數據庫，可能適用於您的案例（可能更容易）。他們似乎也提供了可能更適合產品環境的企業支持（即爲企業用戶提供安全感）。

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

Answer 5

大多數人可能會建議MongoDB像這樣的跟蹤/分析系統，原因很多。您應該閱讀「MongoDB權威指南」一書中的„MongoDB for Real-Time Analytics」一章。根據您的數據大小和擴展需求，您可以獲得所有性能，無模式存儲和臨時查詢功能。您需要自行決定系統的耐久性和不可預測性問題是否對您有風險。

對於一個更簡單的跟蹤系統，Redis將是一個非常好的選擇，提供豐富的功能，超快的速度和真正的耐用性。要了解Redis如何實施這樣的系統，請參閱this gist。缺點是，您需要自己定義所有「索引」，而不是像「MongoDB」那樣爲「免費」獲取它們。儘管如此，沒有免費的午餐，而MongoDB的指數絕對不是免費的午餐。

我想你應該看看到ElasticSearch如何將使您：

• 驚人的速度
• Schema的免費存儲空間
• 分片和分佈式架構
• 強大的分析在原語形式facets
• 易於實現「滑動窗口」型數據存儲與索引阿里ases

它是一個「全文搜索引擎」，但不要讓自己感到困惑。閱讀„Data Visualization with ElasticSearch and Protovis「文章，瞭解ElasticSearch的真實世界用例作爲數據挖掘引擎。

看看these slides爲「滑動窗口」場景的真實世界用例。

ElasticSearch有很多可用的客戶端庫，例如Ruby的Tire，所以很容易用原型快速起步。

爲了記錄（根據我的經驗，所有應有的尊重:)，根據我的經驗，我無法想象一個實施，其中Couchdb是一個可行和有用的選項。不過，這將是一個非常棒的備份存儲空間。