2015-06-22 110 views
0

我只是好奇如果我試圖讓我的節點服務器上運行一個機器人,我可以玩二十一點反對最好的方法。什麼類型的數據庫是最好的存儲數組或數據對象

但是對於通過套接字連接的多個客戶端來說,每個連接的套接字都會有自己的機器人來對抗,但是我需要某種方法來保證機器人每次發送POST請求時都使用它們,甲板。

我覺得MySQL會非常迅速地變得混亂,因爲我不能僅僅存儲一個數組或對象,並在每張卡被使用時拼接出來,但我並不十分熟悉哪種數據庫專門用於這種使用。

如果我沒有任何意義,基本上是:

我需要存儲卡機器人(但每個連接的用戶會話)不只是1臺1人,但多個甲板多個人。

我不是要求你爲我編寫任何代碼,只是指出我對哪種數據庫非常適合這種設置的方向。

我在想也許Redis或MongoDB?

+0

我知道你在徵求建議和總體指導,但這可能會被標記爲基於意見。無論如何,我認爲需要更多關於您的應用程序的信息以作出明智的選擇。您是否需要數據一致性和原子性,而不是潛在的一些操作,即交易?讀取和寫入的比率是多少?你看的規模有多大? – light

+0

@ light可能有100多位併發玩家對自己的機器人進行遊戲(機器人撲克牌和客戶端套牌只會在服務器上生成/修改,以至於他們無法使用控制檯製作一堆21並贏得勝利win) – Datsik

+0

我認爲你的意思是僅在服務器上生成/修改? – light

回答

1

Redis的很可能是最快的,特別是如果你不需要的耐用性保證 - 在比賽的大部分可使用Redis的播放了內存數據存儲,這可能會是快於寫入任何磁盤在世界上。也許週期性地,你可以將「整個遊戲」寫入磁盤。如果該項目不是用於商業目的,即計算機錯誤不會導致玩家賠錢,這絕對是一個誘人的選擇。

MongoDB很受歡迎,特別容易開始使用Node,而且肯定比大多數關係型SQL解決方案更快,但交易可能會成爲問題。對於原型或概念驗證項目,它應該沒問題。但是你也可能想看看其他的「NoSQL」解決方案。

Cassandra是另一個受歡迎的面向文檔的數據庫,很多人更喜歡MongoDB,出於各種原因 - 最值得注意的是,爲了獲得更好的可伸縮性。

這個選擇非常依賴於你如何建模你的數據。在你當前的場景中,我知道你只想簡單地存儲一個對象/數組,這聽起來像你基本上去聚合文檔(MongoDB)的方式。實際上,您將整個數據庫「非規範化」爲一個聚合,並且每次對整個對象執行讀/寫操作以實現一致性。這是MongoDB和其他面向文檔的數據庫中的流行技術。但請注意,此解決方案僅適用於您不跨分區操作。考慮一下當你有多臺服務器爲應用程序寫入一個單獨的數據庫集羣時會發生什麼。

如果可擴展性是一個問題,你真的需要分析和決定什麼是建模數據的最佳方法。是不是不是不斷寫入這個陣列更好的模型?例如,生成一次卡序列,將其作爲Game存儲在數據庫中,並且只讀取它以繪製卡片?然後,每個玩家的移動都可以作爲一個非常簡潔的數據結構存儲起來Hit引用Game中的卡片。雖然數據變得非常關係(回到舊學校的SQL),但寫入的數據要小得多,並且服務器永遠不會進入鎖定狀態,等待玩家釋放對象。它可能會或可能不會適用於您的用例,但請考慮如何爲最大讀取數和最小獨立寫入數據建模。

個人(IMO),如果這個項目是爲了好玩,我會和Redis一起作爲內存緩存層進行大部分讀/寫操作,並將遊戲日誌寫入Cassandra。但如果這是嚴肅的業務,而且我需要一些真正的一致性保證,那麼我可能會回到關係數據庫,並使用Redis緩存層來加快讀取速度。

因爲沒有一個正確的答案,所以任何人都可以給出的唯一建議是衡量應用程序的持久性需求與每個數據庫解決方案的優缺點之間的關係,並且在做出諸如「哪個技術用於持久性「。例如,您忽略了MongoDB可能存在的長期問題 - 如果您只是Google「MongoDB問題」或「MongoDB糟糕」。地獄,就交易或一致性而言,目前的所有NoSQL產品甚至可能存在長期問題。

相關問題