我有大數據集，我想查詢。查詢不會更改，但底層數據會。從我閱讀的內容中，我可以構建一個「視圖」並對其進行查詢。另外，我讀到Couch DB知道如何在數據更改時更新視圖，因此我認爲再次查詢視圖仍然很快。速度，CouchDB的意見和替代
我的問題是，我是否正確理解CounchDB的觀點？我不需要CouchDB的任何其他功能，我甚至不需要SQL，我只需要快速查詢數據。我可以使用別的東西嗎？如果我會使用比較好的舊MySQL，它會比CouchDB慢（請閱讀：在上述情況下，各種DB如何執行？）。
我不認爲任何人都可以根據您提供的信息回答您的問題。
關係數據庫中的索引類似於CouchDB視圖。在這兩種情況下，它們都存儲一個預先排序的數據實例，並且數據庫將該實例與規範化數據保持同步。這兩種類型的數據庫都透明地使用索引/視圖來加速對索引/視圖設計的表單的後續查詢。
沒有索引/視圖，查詢必須掃描整個n記錄的數據集合，並且它們在O(n)時間內執行。當查詢受益於索引/視圖時，它會在O(log n)時間內執行。
但是，這是關於數據量的性能曲線非常廣泛的說法。給定的數據庫在某些情況下可以具有如此快速的性能，以至於無論如何它都可以超越其他產品。很難概括說明品牌X總是比品牌Y更快。要確定具體案例的唯一方法是在兩個數據庫中嘗試這種情況並衡量其性能。
您的評估是完全正確的。請享用！
值得一提的唯一性能技巧是，如果您從視圖中需要所有數據並從不使用?include_docs功能，您可能會看到一個提升，因爲include_docs會導致CouchDB返回到主數據庫並檢索導致該視圖行的原始文檔。換句話說，你可以將emit()所需的所有東西放到你的視圖索引中（空間更大但速度更快），或者你可以使用參考返回原始文檔（空間更小但速度更慢）。
我知道索引是預先分類的（即O（log N）），但我認爲視圖會自動填充新更新的數據，所以根本沒有搜索。換句話說，我認爲視圖與索引非常不同，表現如何......順便說一句，你說我提供的信息不夠多，請問你能更具體些嗎？像數據量？我還認爲查詢保持不變並且數據更改比任何其他更重要...... – 2010-08-12 22:47:39
哪個產品具有最佳性能取決於您的特定查詢以及您定義的索引/視圖。這就是我沒有足夠的信息。每個產品都有其優點和缺點，因此只有在知道需要優化哪些查詢後才能進行優化。 – 2010-08-12 23:08:14
另外：如果索引包含結果中需要的所有列，則可以使用索引來避免搜索。這被稱爲*覆蓋索引*。當然，在許多RDBMS品牌中，您一次只能爲一個表中的列定義索引，因此它可能不如CouchDB視圖的通用性。 – 2010-08-12 23:10:14