彈性搜索+ CouchDB的OR獅身人面像+ MYSQL ....對文件審查的SaaS

Question

我有：爲提供

集預處理辦公文檔（Word，Excel和PDF文件，電子郵件，電源點等） 「加載文件」（約每組2-4兆兆字節）。

「加載文件」組成：

1. 單PG的TIFF（從辦公文檔打印.. 15頁字 文檔將有15 tiffs）
2. 從官方提取的元數據在包含全文的帶分隔符的.dat文件中提供。
3. 其相關聯的.TIFF & .DAT .log文件（.dat文件放在一起& .log文件包含的數據集大小的約7-10％）
4. 原始的辦公文檔

用戶通過BROWSERS WILL：

1. 做各種關鍵字搜索的全文&中的.dat發現的元數據
2. 查看TIFF圖像偶爾ORI ginal辦公文檔
3. 分類每個文檔的一些用戶定義的標籤，有時做筆記
4. 排序在各種方式的數據...例如發送日期，作者，主題等

試圖之間做出選擇： 彈性搜索+ couchdb或sphinx + mysql

我已被建議搜索將是主要的工程問題，所以決定使用它作爲確定其他一切的基礎。

隨着未來的發展，我想我會選擇所有的東西「雲」。我關注的是彈性搜索，我認爲它與couchdb搭配得很好（沒有特別的原因，除了與ES廣泛的緊密集成之外）...還有symfony2 +原則（不是與這些人結婚，而是讀取它們與ES配對）而不是zend。

但是後來有人說數據看起來結構非常好，所以sphinx/mysql是一個更好的路徑，「隨機」的獅身人面像被雲中的節點分開。

背景：

我的主要目標是速度和服務了TIFF圖像的搜索&的性能。可擴展性是一個次要問題，因爲用戶數量可能會增長到成千上萬......也許10萬，但不是「網絡規模」（數千萬）。然而，其中一些用戶將每天8小時在應用程序上。

問題：

對於這個特定的應用程序，你覺得彈性搜索+ NoSQL的是矯枉過正在這個意義上，這將需要更多的時間/複雜度/資源比我真正需要的，沒有顯著的性能優勢配置？或者，獅身人面像最終會成爲一個瓶頸更大的數據集/更多的用戶？

Answer 1

作爲評論不僅僅是一個答案...（太長雖然）

我真的不能對CouchDB的評論，但我想我會分享我關於MySQL /獅身人面像的想法。

首先，搜索極快，即使複雜的標準。 索引的某些方面需要存儲在RAM中。如果你有一個巨大的數據集，你將需要分配足夠的資源給獅身人面像，以獲得這種表現。

一個潛在缺點獅身人面像，是在我的經驗「獅身人面像開箱即用」，只有當你有相當簡單的要求會發生。 如果你想之前索引預處理文件（即運行文件的正則表達式的，替補論壇bbcodes等），然後就變成複雜得多（在我的情況下，我必須使用xmlpipe2數據指標，而不是獅身人面像說話直接到MySQL）。

與獅身人面像另一個潛在的問題是，雖然有實時指數，他們還沒有（IMO）成熟的特點，並有一定的侷限性太大。 因此，您可能需要定期對數據集進行重新索引（或者更有可能的是，索引新的位，然後將它們合併到主索引中 - 稱爲主+增量）。這不一定是一個問題，但它又是一個更動人的部分。

「我的主要目標是速度和搜索的性能」 - 獅身人面像不會在這裏讓你失望，它會很好地進行縮放。