的預期（不追溯）搜索數據庫解決方案

Question

比方說，我們有一個要求，以創建消耗的文檔的高容量，實時數據流的系統，並針對一組定義的用戶，這些文件匹配搜索查詢，因爲這些文件可用。這是一個前瞻性的，而不是回顧性的搜索服務。什麼是適當的持久性解決方案？

假設用戶希望看到的匹配他們的查詢的文檔活飼料 - 認爲谷歌快訊 - 和飼料必須顯示爲每個文檔的某些元數據。讓我們假設比賽的無限期壽命;即，系統將允許用戶從創建特定查詢的時間開始查看查詢的所有匹配。因此，流中的每個文檔的元數據以及文檔和與該文檔匹配的用戶查詢之間的關聯必須保存到數據庫中。

讓我們拋出另一個要求，即用戶希望能夠面向某些元數據：例如，用戶只想查看其元數據字段「結果類型」等於「博客」的特定查詢的匹配文檔， 「並且希望計算博客比賽的數量。

下面是一些假設性的數字：

1. 200000新的數據文件每天都絡繹不絕。

   - 每個文檔的元數據都會保留。

2. 1000用戶提供約5個搜索查詢每個：約5000總用戶搜索查詢。

   - 這些查詢是簡單的布爾查詢。

   - 在每個新文檔進入時，將針對所有5000個查詢處理它，以查看哪些查詢匹配。

3. 每個進料 - 一個用於每個用戶的查詢 - 被刷新到每分鐘用戶。換句話說，對於每個訂閱源，每分鐘都會執行一次針對數據庫查詢最近一次匹配頁面的查詢。

向用戶顯示飼料的速度至關重要。可擴展性和高可用性也非常重要。

用戶和查詢之間的關係是關係型的，如查詢和匹配文檔之間的關係，但文件的元數據本身只是鍵 - 值對。所以我最初的想法是將關係數據保存在像MySQL這樣的關係數據庫和NoSQL數據庫中的元數據中，但是在NoSQL數據庫中可以實現關係數據嗎？另外，構建一個feed將需要調用兩個獨立的數據存儲，這是額外的複雜性。或者可能將所有內容都推送到MySQL中，但這需要大量的連接和計數。如果我們將所有數據作爲鍵值對存儲在某種其他類型的數據存儲中，那麼我們將如何進行刻面？對於匹配多個搜索查詢的文檔，會有大量的冗餘元數據。

什麼樣的數據庫將很適合這種情況？我知道諸如Twitter Storm和雅虎的S4等工具可用於構建此類系統的整體架構，但我想關注數據庫，因爲數據存儲，數據量和查詢/刻面要求。

Answer 1

首先，我不同意本。每天新增200,000條記錄，而一天的記錄數爲86,400秒，因此我們正在討論每秒三條記錄。這不是驚天動地，但它是新數據的一個可敬的剪輯。

二，我認爲這是一個人們面臨的現實問題。我不會說這個論壇不適合這個話題。

我認爲這個問題的答案與被支持的用戶查詢的複雜性和類型有很大關係。例如，如果查詢包含一堆二元謂詞，則可以從文檔數據中提取特定規則，然後輕鬆應用規則。另一方面，如果查詢包含對文檔文本的複雜評分，那麼您可能需要爲每個用戶查詢使用倒排索引與評分算法配對。

我對這樣一個系統的方法是將查詢解析爲可以從每個文檔確定的單個數據元素（我可能稱之爲「查詢簽名」，因爲結果將包含滿足查詢所需的所有字段） 。每次加載文檔時都會創建這個「查詢簽名」，然後可以用它來滿足查詢。

添加新查詢需要處理所有文檔以分配新值。考慮到數據量，這可能需要更多的批量任務。

SQL是否合適取決於您需要從數據中提取的功能。這又取決於用戶查詢的性質。 SQL可能足夠了。另一方面，您可能需要更復雜的工具，特別是如果您使用文本挖掘概念進行查詢。

Answer 2

想到這裏，這聽起來像一個事件處理任務，而不是一個普通的數據處理操作，所以它可能是值得研究Complex Event Processing系統 - 而不是一個常規數據庫建設的一切，用它處理查詢的系統在傳入數據流入系統時。有商業系統可以達到高可用性標準的速度，但我還沒有研究可用的OSS選項（幸運的是，quora上的人員已這樣做）。

Answer 3

看看Elastic Search。它具有一個percolator功能，可將文檔與註冊的查詢進行匹配。 http://www.elasticsearch.org/blog/2011/02/08/percolator.html