> 作者NateWiger發布于 2014年10月9日 AmazonDynamoDB正迅速成為世界上發展勢頭最強勁的游戲數據庫。《水果忍者》（由Halfbrick工作室開發）、《戰斗營地》（由PennyPop開發）等游戲都充分利用AmazonDynamoDB的一鍵式擴展性功能，支撐游戲高速的發展，為全球數百萬玩家提供服務。AmazonDynamoDB還得到包括Supervillain工作室在內的眾多開發人員的贊賞，該工作室的知名作品包括《塔炮戰爭》與《特隆：進化》。 在今天的文章中，大家將了解AmazonDynamoDB如何幫助大家為自己的移動游戲快速建立起可靠且極具可擴展性的數據庫層。我們將分步剖析設計示例并了解如何以每天不足一杯咖啡錢的成本為游戲提供彈性資源支持。我們還將模擬一家快速發展的客戶，觀察AmazonDynamoDB如何在時間與成本效率的前提下將玩家支持規模擴展至數百萬之巨。 **數據庫層的重要性** 在為規模化應用程序設計架構時，一大關鍵性因素在于數據庫層。這一點對于游戲尤為重要，畢竟屬于寫入密集型應用。游戲數據會隨著玩家收集道具、擊敗敵人、獲取金幣、角色升級以及完成成就而不斷更新。每一個事件都必須被寫入到數據庫層，從而保證內容不會丟失。可以想見，一旦進度損壞玩家將變得極為暴躁。 游戲與Web應用開發人員通常會使用MySQL等開源關系型數據庫作為自己的數據庫層，這是因為此類方案更為人們所熟悉。遺憾的是，以MySQL為代表的關系型技術方案在開發之初更多考慮到的是高強度讀取工作負載，而這種機制并不太適合游戲、社交媒體應用以及圖片分享站點。有鑒于此，NoSQL解決方案應運而生，它利用強大的寫入數據吞吐能力與橫向擴展能力替代了傳統關系型數據庫在查詢靈活性領域的優勢。 **AmazonDynamoDB**適合游戲開發人員需求的三個理由 **Amazon包攬運營任務** 開發游戲本身就很累人，對吧？AmazonDynamoDB是一項托管服務，其中包含全方位運營支持以及多數據中心高可用性。大家用不著再為軟件安裝、硬件故障處理或者性能表現調整而煩心。**只需調用單一API，大家就能對AmazonDynamoDB進行動態縮放 每一個AmazonDynamoDB數據庫表都與數據吞吐能力密切相關。大家可以將每秒寫入操作設定為1000次，而AmazonDynamoDB會處理全部后臺數據庫調整工作。根據用戶需求的變化，大家可以更新該容量，AmazonDynamoDB則會依要求完成資源重新分配。這種彈性能力對于游戲開發者幫助巨大：當游戲推出之后，大家可能需要在短時間內將玩家支持規模由數千位增加到數百萬位。同樣重要的是，大家可以快速調低資源規模——這種調整對于MySQL數據庫來說頗具挑戰。 **無論游戲玩家規模如何變動，性能表現都將保持穩定** AmazonDynamoDB可在任意規模水平下保持可預測、低延遲性能表現。如果大家的游戲對于延遲較為敏感、并且需要面對數百萬玩家，那么這種特性將變得至關重要。使用AmazonDynamoDB，大家不必再為性能調整浪費任何精力。 **在AmazonDynamoDB中保存游戲數據** 我們不妨想象一下，大家希望創建一款角色扮演游戲。游戲設計遵循常見機制：與怪獸戰斗、收集戰利品并進行角色升級。在這種情況下，各位顯然需要保存用戶的當前進度，這時我們應該為每位玩家創建一個鍵-值對配置文件，其中包括現有道具、角色等級以及賺得金幣的數量。大家的數據結構可能如下所示： ~~~ { ????player_id:3612458, ????name:"Gunndor", ????class:"thief", ????gold:47950, ????level:24, ????hp_max:320, ????hp_current:292, ????mp_max:180, ????mp_current:180, ????xp:582180, ????num_plays:538, ????last_play_date:"2014-06-30T16:27:39.921Z" } ~~~ 在這個示例中，player_id應該是個獨特的值。將其與MySQL等關系型數據庫相映射非常簡單：為每個鍵創建一個列。這種方式當然可行，但對結構中的每一列進行解析及檢索將給數據庫帶來沉重負擔，而且主鍵（即player_id）幾乎每時每刻都要接收查詢請求。很明顯，大家不太可能利用玩家的記錄點位置或者經驗值進行記錄查詢。 好的，下面來看將其映射至AmazonDynamoDB會發生什么。在AmazonDynamoDB當中，我們只需要定義需要進行檢索的列即可。在這種情況下，我們將創建出單一散列鍵作為主鍵，并借由player_id的獨特性利用它實現記錄查詢。我們會定義一套名為“player_profiles”的表，并為“player_id”設定散列鍵。下面來看Python語言編寫的示例： ~~~ player_profiles=Table.create('player_profiles',schema=[ ????HashKey('player_id',data_type=STRING) ],throughput={ ????'read':5, ????'write':5, }, ~~~ 我們已經創建了一套包含5個讀取容量單位與5個寫入容量單位的表，其被包含在AWSFree Usage Tier當中。大家也可以利用AWS管理控制臺創建這套表。如果不知道該如何操作，請[點擊此處](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedCreateTables.html)查看指導信息。 該表創建完成之后，我們的配置文件將如下所示： ~~~ player_profiles.put_item(data={ ????'player_id':'3612458', ????'name':'Gunndor', ????'class':'thief', ????... }) profile=player_profiles.get_item(player_id='3612458') ~~~ 這只是Python環境下的示例，大家也可以使用任何AWSSDK以put/getAmazon DynamoDB中的鍵。 **主鍵值** 關系型數據庫使用自動遞增的整數，其典型會被作為主鍵。在規模化場景下，自動遞增的主鍵往往會成為性能瓶頸，因此AmazonDynamoDB等NoSQL并不會將其進行保存。那么我們該如何生成獨特的player_id值呢？我們使用UUID，由于UUID的內容彼此不同、因此不同客戶端總會生成獨立的相應數值。UUID能夠為我們生成相當長的字符串，例如a8098c1a-f86e-11da-bd1a-00112444be1e。UUID與AmazonDynamoDB匹配效果極好，這是因為它有助于確保主鍵的隨機分布與訪問、從而讓AmazonDynamoDB始終擁有良好的性能表現。 生成UUID非常簡單： ~~~ player_id=uuid.uuid1() player_profiles.put_item(data={ ????'player_id':player_id, ????'name':'Gunndor', ????'class':'thief', ????... ??}) ~~~ **原子遞增** 除了put與get，AmazonDynamoDB還支持原子遞增。這種機制在值發生變化之后的更新流程中非常實用，因為來自應用程序的多項請求不會出現沖突——正是此類狀況引發了在線游戲中的大部分進度丟失問題。如果玩家拾取到100金幣，大家可以直接要求AmazonDynamoDB自動將100金幣增量以原子化方式進行添加，而無需經歷獲取記錄、添加金幣再將其返回AmazonDynamoDB的過程。 **選擇合適的容量水平** AmazonDynamoDB允許大家指定自己所需要的數據吞吐能力容量。但如果大家不清楚這一水平該怎么辦？當大家開始游戲開發時，先創建自己的第一套表（例如5個寫入容量單位與10個讀取容量單位）。隨著流量的增長，我們可以在AmazonDynamoDB控制臺中利用CloudWatch圖形監控使用情況并作出調整。 [DynamicDynamoDB](http://aws.amazon.com/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/)是另一款實用性工具，這是一套開源庫、旨在幫助我們對表容量進行自動擴展。我們的客戶之一[tadaa](http://www.tadaa.net/)公司利用DynamicDynamoDB在流量水平下降時及時調整資源、從而控制成本支出。  **我們真能用每天一杯咖啡的成本為數千玩家提供支持嗎？** 是的！我們利用保存游戲這個例子來估算成本。假設游戲每個月平均玩家數量為10萬名，其中大部分玩家并不會在同一時間登錄游戲，因此我們粗略估算其中的十分之一將同時在線。另外，我們假設這1萬名玩家每一分鐘保存一次游戲，而每位玩家的進度數據記錄不足1KB。最后，我們假設每位玩家在游戲過程中每一分鐘需要從數據庫中讀取一次游戲狀態。由于一分鐘里有60秒，相當于我們的AmazonDynamoDB表每秒必須能夠支持167次寫入與讀取操作（10000除以60）。大多數企業都會保留一部分緩沖容量，因此我們將每秒寫入與讀取接納能力提升到200次，而總存儲空間則設定為50GB。 根據目前US-EAST-1區域的資源計費標準，這樣的資源每天只會帶來4.16美元的開支！也就是說，每天一杯咖啡的價錢完全可以為10萬名玩家提供支持（當然，這里指的是花式意大利濃縮那種相對較貴的咖啡類型）。作為起步，大家也可以先免費使用AWSFree Usage Tier與AmazonDyamoDB相配合。 **客戶示例：《戰斗營地》**? 作為一款由PennyPop公司開發的高人氣手機游戲，《戰斗營地》利用AmazonDynamoDB作為其首選數據存儲機制。《戰斗營地》截至目前的下載總量已經超過1000萬次，而且在超過四十個國家的應用程序商店中占據下載榜的前百名位置。在比較了其它幾套NoSQL選項之后，PennyPop公司的技術人員選擇了AmazonDynamoDB，因為他們希望能夠將精力集中在應用程序編程、而非服務器維護與擴展方面。 《戰斗營地》的開發人員首先下載了[fake_dynamo](https://github.com/ananthakumaran/fake_dynamo)，一款開源客戶端，來進行本地開發。（Amazon還發布并支持一款本地Dynamo客戶端。）他們構建起自己的對象關系映射(ORM)以使其能夠與RubyonRails協作。這套ORM方案對DynamoDB的功能進行了大幅度簡化，因為開發人員們只需要在應用程序層中用到鍵-值檢索。該ORM將值作為JSON對象進行保存——所謂JSON對象，也就是經過壓縮的base64字符串。這種機制允許他們將JSON對象壓縮至原始體積的不足十分之一。大多數Web應用程序數據庫查詢操作可以通過獲取與保存簡化實現削減，而整個遷移工作也在數周后徹底完成了——在此期間他們還構建起自己的定制ORM。 下圖所示為《戰斗營地》游戲如何將AmazonDynamoDB整合至自己的架構當中。  結果如何？極大節約了時間與成本。正如PennyPop公司聯合創始人CharlesJu的解釋： AmazonDynamoDB的成本節約效果一方面借由效率與易用性實現，同時也體現在了維護成本的顯著縮減身上。構建、維護以及拆分以數據為中心的大型實時項目一直非常困難，項目的創建與維護也一直要求大量技術人員的參與。然而現在我們在為數百萬玩家提供滿意的游戲體驗的同時，仍然只擁有兩位服務器工程師。我們的規模比已知的任何一家MMORPG廠商都更具精簡特性。 他們還發現，DynamoDB在其它規模更大的場景中同樣運作良好、甚至能夠與MapReduce分析協議順利對接，這要歸功于其出色的擴展靈活性。他們完全可以構建內部MapReduce協議，進而以并行方式執行數據分析。 **最后一項：分析** 除了實時游戲服務之外，AmazonDynamoDB還集成了一系列其它AWS服務，其中包括AmazonElastic MapReduce（簡稱EMR）以及AmazonRedshift。AmazonEMR與AmazonRedshift都能夠直接從AmazonDynamoDB當中加載分析數據，從而簡化分析工作流的構建方式。如果大家想了解更多在AWS上對游戲內容加以分析的信息，請在評論欄中發表意見、我們將在未來的文章中專門探討這個話題。 本文原載于AWS[博客](http://blogs.aws.amazon.com/bigdata/post/Tx27Y7HOQ4V6393/Powering-Gaming-Applications-with-Amazon-DynamoDB)。 查看原文：[AmazonDynamoDB](http://www.infoq.com/cn/news/2014/10/amzon-dynamodb-game-dev)[在游戲開發中的應用](http://www.infoq.com/cn/news/2014/10/amzon-dynamodb-game-dev)