從MySQL切換到Cassandra - 優點/缺點？

有一點背景 - 這個問題涉及一個項目運行在一個小的EC2實例上，即將遷移到一箇中型項目。主要組件是Django，MySQL和大量使用python和java編寫的自定義分析工具，這些工具可以提升重量。同一臺機器也在運行Apache。從MySQL切換到Cassandra - 優點/缺點？

數據模型看起來像下面這樣 - 大量的實時數據通過各種網絡傳感器進行流式處理，理想情況下，我希望建立一個長輪詢方法，而不是每15分鐘進行一次當前輪詢（計算統計信息和寫入數據庫本身的限制）。一旦數據進入，我將原始版本存儲在MySQL中，讓分析工具在這些數據上鬆動，並將統計數據存儲在另外的幾個表中。所有這些都是使用Django呈現的。

關係的特點，我需要 -

排序[SliceRange在Cassandra的API似乎satisy這種]由多個表之間

多對多關係
集團[卡桑德拉SuperColumns似乎做以及一對多]
獅身人面像在這給了我一個很好的全文引擎，所以這也是必要的。 [開卡珊德拉，在Lucandra項目似乎滿足這種需要]

我的主要問題是，數據讀取非常慢（和寫是不是很燙兩種）。我現在不想在它上面投入大量金錢和硬件，我更喜歡隨着時間的推移輕鬆擴展的東西。縱向擴展MySQL在這個意義上（或便宜）並不是微不足道的。

所以基本上，在已經讀了很多關於NOSQL的，都像MongoDB的，卡桑德拉和伏地魔嘗試，我的問題是，

在中等EC2實例，我會獲得任何好處讀/寫轉移到像Cassandra？ This article（pdf）絕對似乎表明這一點。目前，我會說每分鐘寫幾百次就是常態。對於讀取 - 由於數據每5分鐘更改一次，緩存失效必須很快發生。在某些時候，它也應該能夠處理大量的併發用戶。即使創建了索引，MySQL在大型表上進行一些連接也會導致應用程序性能下降 - 大約32k行的內容需要超過一分鐘的時間才能呈現。（這也可能是EC2虛擬化I/O的人爲因素）。表格大小約爲4-5百萬行，並且大約有5個這樣的表格。
鑑於CAP定理和最終一致性，每個人都在討論如何在多個節點上使用Cassandra。但是，對於剛開始增長的項目，是否有意義部署單節點cassandra服務器？是否有任何警告？例如，它可以替代MySQL作爲Django的後端嗎？ [這是推薦？]
如果我換班，我猜我必須重寫應用程序的部分做更多的「administrivia」，因爲我必須做多個查找來獲取行。
難道任何意義，只是使用MySQL作爲一個鍵值存儲，而不是一個關係引擎，並與去？這樣我就可以利用大量穩定的API以及穩定的引擎（並根據需要去關聯）。（從Friendfeed的佈雷特·泰勒的帖子在這 - http://bret.appspot.com/entry/how-friendfeed-uses-mysql）

任何見解從誰做了一個轉變的人將不勝感激！

謝謝。

來源

2010-02-25 viksit

我很好奇，如果你最終轉向卡桑德拉。我已經在從php和asp.net切換到django的路線上，但我不確定現在從mssql和mysql遷移到Cassandra是否爲時過早。我還有每秒數百條記錄進來。 – avatar 2011-04-26 16:49:26

@itgorilla - 我使用cassandra進行非常具體的任務，現在它運行良好。我意識到將它用於「移動」數據庫可能不是一個好主意，我的結果驗證了（我同意下面的codemonkey的答案）。所以如果你想要真正快速的寫入，搜索和非規範化的數據，並且你想擴展，Cassandra是一個不錯的選擇。（最上面的數字會說，幾分鐘寫一分鐘！） – viksit 2011-05-07 19:09:42

看看這個Django Cassandra項目，如果你有興趣： https://github.com/vaterlaus/django_cassandra_backend – Alex 2011-01-24 23:42:49

Cassandra和其他現在可用的分佈式數據庫不提供您從sql中使用的即席查詢支持。這是因爲你不能通過連接來分配查詢，所以強調反規範化。但是，Cassandra 0.6（明天正式推出測試版，但如果您不耐煩的話，您可以從0.6分支開始自行構建）支持Hadoop map/reduce進行分析，這實際上聽起來非常適合您。

Cassandra爲無痛添加新節點提供了出色的支持，即使對於初始組也是如此。

也就是說，以幾百次寫入/分鐘的速度，你會很長時間地在mysql上很好。 Cassandra在成爲關鍵/價值存儲方面（甚至更好，鍵/列系列）要好得多，但MySQL在關係數據庫方面要好得多。 :)

尚無對Cassandra（或其他nosql數據庫）的django支持。他們正在討論在1.2版本之後爲下一個版本做些什麼，但是基於與pycon的django開發人員交談，沒有人確定它會是什麼樣子。

來源

2010-02-25 14:37:30 jbellis

Thx爲答案！幾點 - 當你說重點是非規範化時，基本上意味着任何需要完成的「連接」都發生在應用程序級別，但cassandra實際上分配了查詢（假設你使用隨機分區）？其次 - 我想我現在正在寫幾百個文件，但在這一點上肯定會轉而使用KV商店，而不是必須用幾個10萬次寫入操作:)最後 - 即使假設Django-NOSQL支持仍然存在不存在，是否有阻止通過REST API實時查詢Cassandra數據庫的內容？ – viksit 2010-02-25 18:24:13

Cassandra路由基於行密鑰，因此任何針對單行的查詢只需要擊中一臺機器並且性能相當高。由於REST客戶端API允許使用二進制數據，因此它不適合Cassandra，但更廣泛地說，沒有任何東西可以阻止您手動使用來自django的普通Python驅動程序。 – jbellis 2010-03-01 23:02:39

如果你是一個關係型數據庫開發人員（像我），我建議/指出：

獲取一些經驗與卡桑德拉工作，你承諾其在生產系統上使用之前..特別是如果這個生產系統有一個很難完成的截止日期。也許可以將它作爲後端，用於首先不重要的事情。
這比我預期的要做的簡單事情更具挑戰性，我認爲理所當然的事情是使用SQL引擎進行數據操作。特別是，索引數據和排序結果集是非平凡的。
數據建模也被證明具有挑戰性。作爲一名關係數據庫開發人員，您帶着大量的包袱來到桌面上......您需要樂於學習如何對數據進行非常不同的建模。

這些事情說，我強烈建議在卡桑德拉建東西。如果你和我一樣，那麼這樣做會挑戰你對數據存儲的理解，並讓你重新思考一個我甚至沒有意識到的關係數據庫適合所有情況的前景。

我找到一些很好的資源包括：

來源

2011-05-06 01:25:44 codemonkey

到WTF-is-a-SuperColumn.pdf的鏈接不起作用，你可能有它的副本嗎？ – Flo 2012-10-05 12:42:27

的Django-cassandra是早期的beta模式。另外Django沒有爲非sql數據庫做出。 Django ORM中的關鍵是基於SQL（Django建議使用PostgreSQL）。如果您只需要使用no-sql（您可以在同一應用程序中混合使用sql和no-sql），則需要冒險使用no-sql ORM（它比傳統SQL orm或直接使用No-SQL存儲要慢）。或者你需要完全重寫django ORM。但在這種情況下，我不能推定，爲什麼你需要Django。也許你可以使用其他東西，比如Tornado？

來源

2013-01-11 13:36:58 logan

從MySQL切換到Cassandra - 優點/缺點？

回答

相關問題