上次考試系統的資料量太大，導致有部分學生資料沒有寫進入，經討論研究，決定研究動態資料庫，現將第一版方案公布，大家研究！
將整體的資料庫優化分為四個部分，第一部分為基礎簡化部分，第二部分為動態建庫部分，第三部分為動態建表部分，第四部分為索引優化部分。
在乙個系統中，構成這個系統的必要組成部分，他們變化機會小，資料量穩定，我們稱為基礎部分，將這部分抽象，做成基礎資料庫，將基礎與變化分類封裝，這樣就保證了穩定性，和靈活性的合理平衡！
基礎資料庫建好，和基礎資料庫配套的是動態資料庫，也叫從資料庫，他是動態生成的，我們只對裡面的結構做個規範，不要求他的儲存量有多大，他的建立，是為了讓資料更優化地儲存，也是避免表的過多，造成邏輯混亂！
架構好動態資料庫後，庫里有些表也是動態生成的，這樣是因為，資料量大，單錶儲存不利於系統優化，動態儲存，將當前的錶用完後作為歷史表封存，這樣在保證資料量不超標的基礎上，增加靈活性與統一性！
在建立好資料庫基本機構後，要優化索引表，對系統的需求充分分析，建立合適的索引表，確保資料檢索的快速性和整體性統一。
認真分析系統需求，抽象出具體的表與字段，分析系統中可能出現問題的關鍵節點，將表分類：
大致分為以下幾類：
（1），資料變動類
將表按照資料變動的快慢分類表，一般分為三種，快，中和慢
（2），資料量大小類
將表按照資料量的大小分為，大，中和小三種
將表分好類後，將表按照以上兩種方案作圖：
（1），索引設計：
資料分類做好後，要仔細研究資料之間的關係，建立充足且合適的銜接表（索引表），原則是盡量簡單，讓銜接表最好只涉及到兩張表！
（2），關口設計：
關口設計，就是設計什麼時候動態建立庫，什麼時候動態建立表，要保證時間上和空間上的統一，保證使用者同時面對的表不能太繁瑣！
（3），操作設計：
一般而言，我們設計完動態庫後，必須有自動控制，手動控制，混合控制三個選項供使用者選擇，還要設計好，控制的時間，一般自動選在閒置時間！
（4），安全設計：
在設計完資料庫後，必須考慮資料安全性的問題，其中包括資料的一致性，完整性，保密性，操作許可權等，保證使用者整體資料不分離，使用者必要資料不丟失，使用者資料邏輯性不混亂！
（5），文件設計
設計完資料庫後，必須配備詳細的文件說明，不必到每個字段，但是關鍵字段要充分說明，方便後來者理解！
（6），維護設計
設計資料庫時，要考慮好後期維護的難易程度，給特定使用者開放維護介面，並配有相應的幫助文件！
（7），幫助設計
書寫詳細的幫助說明，使用者在拿到幫助文件後能夠快速上手，維護整個系統！
遇到問題多思考，多交流，請教高手，這是咱們死不要臉的革命精神的一部分，大家要好好總結自己的錯誤，有時候，錯誤是我們成長的關鍵所在
資料中心網路開放性解決之道
這幾年，資料中心得到了突飛猛進的增長。資料中心的建設規模越來越大，系統複雜性也越來越高，這給資料中心運維帶來了極大挑戰，資料中心運維人員忙於各種系統的維護工作，面臨的壓力也越來越大。網路是資料中心裡最為重要的組成部分之一，也是技術最為封閉的部分，仍是一片未開墾的 地，正是因為網路部分存在的問題最多，...
大資料解決方案
原文 大資料解決方案 1 資料庫 垂直拆分 根據業務把錶放到不同的資料庫，解決表之間的io競爭 水平拆分 根據某種規則把單錶資料分成多張表儲存，解決單錶資料量大的問題 索引 根據業務場景建立合理的索引，如果資料量很小建議使用索引 300條以內 索引使用場景 動作描述 聚集索引 非聚集索引 主鍵列是 ...
資料庫 大資料
spark 百萬級的資料，無論側重oltp還是olap，當然就是mysql了。過億級的資料，側重oltp可以繼續mysql，側重olap，就要分場景考慮了。實時計算場景 強調實時性，常用於實時性要求較高的地方，可以選擇storm 批處理計算場景 強調批處理，常用於資料探勘 分析，可以選擇hadoop...