最適合數十億指標的數據存儲

第一類將是數十億的數量級，每個數值在1到1000之間，每個值是一個或兩個64位整數。
第二類將以數百萬的順序排列，每個約有200個值，每個值的大小在1KB到1MB之間。

而我們的使用模式將是這樣的：

這兩種指數將有值添加到頂部高達每秒數千次。
指標將被頻繁讀取，但他們讀的時候它會被讀取
指標應修剪該指數的整體，無論是在寫值索引或在某種間歇式工作

現在我們已經考慮了很多數據庫，目前我們最喜歡的是Cassandra和PostreSQL。然而，我們的應用程序在Erlang中，它沒有Cassandra的生產就緒綁定。而且一個主要的要求是它不需要太多的人力來維護。我感覺Cassandra會拋出意想不到的擴展問題，而PostgreSQL只會給分片帶來痛苦，但至少對我們來說這是一個知道的數量。我們已經很熟悉PostgreSQL，但對Cassandra並不熟悉。

所以。對於哪個數據存儲最適合我們的用例，有哪些建議或建議？我願意接受任何和所有建議！

感謝，

-Alec

來源

2012-02-02 Max

請澄清一下索引（例如第一個）：一個鍵下有多少個索引成員？如果可以，請發佈數字示例。 – Niloct 2012-02-02 21:46:07

「這將是整個索引的讀取」 - 那是一個非常奇怪的索引類型。通常，索引的要點是避免讀取所有的東西。你能解釋一下你想要達到的目標嗎？ – DNA 2012-02-03 00:17:37

您還沒有提供足夠的信息來支持很多答案：您的索引設計。然而，Cassandra通過增長羣集很容易擴展。

你可能想看看這篇文章：http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

對Cassandra的一個更顯著的問題是它是否支持你所需要的類型的查詢 - 可擴展性將不會是問題。從你給出的數字來看，這聽起來像我們正在談論TB或者數十TB，這對Cassandra來說是非常安全的領域。

來源

2012-02-03 00:23:56 DNA

十億是不是今天的標準一個巨大的數字，爲什麼不寫一個基準，而不是猜測？這會給你一個更好的決策工具，這很容易做到。只需安裝目標操作系統和每個數據庫引擎，然後運行查詢，讓我們說Perl（因爲我喜歡它）它不會花你一天多的時間來完成所有這些，我之前做過類似的事情。一個很好的基準測試方法是編寫一個隨機的腳本，或者像高斯鐘形曲線一樣的腳本，執行查詢，「模擬」實際使用情況。然後繪製數據或像老闆一樣閱讀日誌。

來源

2012-02-02 20:28:18 AlfredoVR

最適合數十億指標的數據存儲

回答

相關問題