|
創新性應用： 分表+通行證：和一般的通行證一線之隔，但從長遠的角度卻提供了很大的方便。對於用戶數量的暴增，或者需要將某個地方大量的用戶引入系統，如果保障系統在數據量在數量級增長的時候，依然保證數據庫的正常運行。我採用的是按照用戶的唯一標誌(用戶ID)的範圍對用戶進行邏輯分區，各個範圍的登陸讀寫，都由一箇中間調度接口指向不同的表，這樣分散數據量。但是我還加上一個通行證，只保存用戶的ID和邏輯分區號，一方面解決了用戶ID生成的統一要求，另外也讓以後的擴展變得非常容易。理論上來看，按這個模式以後是可以無限拓展的。假如是照400萬分一個邏輯區，400萬的數據操作，只要代碼比較合理，幾乎不會產生阻塞，所以我選擇了這個數字。用戶增加400萬已經是比較大的一個數字了，根據我的設計，只需要新建一個邏輯區，然後在中間調度過程新加入這個處理過程的流轉，甚至可以提前加入這個過程，讓下次在增長400萬不用你做任何處理。 在我跟一些資深的數據庫專家交流的時候，我也知道了幾乎所有的大型平臺，都使用的是數據庫集羣，用他們的話說，做了集羣，基本不用優化，基本不用考慮數據庫有瓶頸。的確，大量的硬件投入，的確是很直接的解決方法，但沒有硬件條件的時候，靠優化操作，靠優秀的結構，也可以發揮出很強的性能。在他們知道我們這裏用一臺數據庫服務器，支撐兩個遊戲平臺，其中一個在線人數已在萬人一上，他們都認爲單PC級別的服務器，達到這樣的功能，已經是奇蹟了。不過即使到現在，數據庫依然有優化的餘地，也就是還有潛能可以發揮，或者這有限的硬件條件，對數據庫工程師也是一種挑戰。
行業借鑑經驗： 我前面提到的，我所實踐出來的數據庫同步和用分表並且由統一接口生成通行證的方案應該有比較強的借鑑意義。數據同步方案的操作流程公佈在我的blog 上之後，以後有很多朋友聯繫過我，說明他們有相同的需要。關於分表和通行證的方案，我在創新性應用裏已經比較詳細的說明了。 另外還有一點，就是要根據自己的情況，進行靈活的處理。我在工作的過程中，有這麼個表，數據量約2000萬，每天增長約150萬，主要是寫入操作。當然讀操作只是相對小，但是一方面，寫操作頻繁的表不該多建索引，另外讀也很重要，這個數據量如果不建立合適的索引，是沒辦法進行讀操作的。那麼我之前做了同步這個工作，我就讓備份數據庫上的表結構和主數據庫這個表結構不同。我在備份數據庫這個表建立了多個和查詢條件關聯的索引，由於只有10分鐘的數據差別，所以讀操作我直接用聯接服務器指向了這個備份數據庫。
應用難點技巧： 至於技巧這方面，網上有很多人整理了自己的看法。我覺得也是根據各自工作的特點，很多說法，也只是相對而言。我在工作的過程中，細節上，也有些自己的規則。 1． 代碼習慣：寫存儲過程，前面寫明功能，註釋參數的含義，中間註釋出各個代碼段的含義。變量命名也根據類型有對應的規則。 2． 表的寫入操作：主要是建立表的時候，不爲空的字段我還是會設置默認值，要不很容易出現寫入失敗的情況，同結構表的生成避免使用select into 生成，因爲它把約束和鍵信息會丟失的。插入表儘量避免insert …select ..這樣的寫法，應該用insert(字段1,2,3) values或者insert(字段,…) select …,讓字段和輸入值有對應關係，這樣以後表進行修改的話，也不至於有些字段沒有輸入值而讓相關的寫入操作失敗。 3． 在查詢上，如果可能，儘量在備份庫執行，並且儘量發揮索引的作用。關聯的時候，也儘量用聯接查詢，避免用子查詢，因爲子查詢效率明顯要低很多。 4． 4
|
|
4．數據維護：對於數據產生數據量大的表，也寫好定時清理過期信息的代碼。這樣把最新的數據放到一個表，比較老的數據放另一個表，對很多操作會比較方便的。 |
文章請同時提交信箱：[email protected] [email protected]