微博 請問你是怎么優化數據庫的？
原創【51CTO綜合報道】圍脖，織圍脖——這是什么？冬天到了，織條圍脖保暖嗎？錯，這是網絡流行用語。這還是大家的生活方式，生活態度。“找我？來我微博啊！”最近身邊的朋友都在織啊織，你不織？你就是“奧特曼”。那么大家是否知道微博的開發模式嗎？數據庫是如何部署的？又是如何優化的？這些問題一出，必要找達人為我們解惑。51CTO有幸請到新浪***DBA楊海潮先生來為我們解一解上述的疑惑。
專訪人物介紹
楊海潮，新浪***DBA，在大規模高并發，海量訪問有豐富的管理經驗。熱衷于數據庫設計，性能優化，分布式部署方案和高可用性方面的研究。
之前從事大訪問量網站的部署以及優化工作，加入新浪后主要負責整個公司的數據庫管理工作。
51CTO：新浪現在的開發模式還是LAMP嗎？
楊海潮：目前大部分業務還是使用LAMP方式，也有部分采用LNMP方式。
51CTO：新浪數據庫是如何部署的？
楊海潮：目前NoSQL和MySQL是結合使用的，根據應用的特點選擇合適存儲方式。
51CTO：Sharding策略是很好的數據庫擴展方案，但是這種方案也不是***的，新浪是如何選取sharding的形式，來適應不同的應用場景？
楊海潮：如圖：
sharding只用于數據量大同時有性能瓶頸的庫，大部分庫不進行sharding處理。
對于數據量比較大的庫，在一開始就考慮sharding策略，例如索引數據和內容數據分開設計，每類數據庫根據業務邏輯選擇恰當的partitioning key，拆分成一定數量的表。
然后隨著壓力的增加進行垂直拆分，垂直拆分后的庫再遇到性能瓶頸時首先考慮用硬件來解決。
當硬件解決不了時才開始考慮水平拆分。
在選擇sharding方案時仔細考慮業務邏輯。對于讀密集型應用，基本上通過增加slave來解決，對于寫密集型應用才進行垂直和水平拆分工作。
51CTO：跨越越多的sharding，帶來的開銷就越大，這個數量是如何控制的？
楊海潮：目前我在設計之前就避免跨表操作，選擇適當的paritioning key，也即合適的拆分維度，避免對后期業務的影響。
根據業務邏輯的重要程度，如果業務邏輯是查詢某一個用戶的信息，那么會按用戶進行拆分，那么保證一個用戶的數據是落在一張表里面。按時間維度進行拆分，那么會分析數據的冷熱程度，把80%以上的數據放在一個表，避免過多的跨表查詢。
在這種拆分維度滿足不了業務需求時，我們會利用空間換時間的思想，同一份數據按多種維度進行拆分，讓每種業務邏輯的查詢語句都有很高的效率。
51CTO：很多用戶都會把sharding和partitioning混淆，您能講講您是怎么區分sharding與partitioning的異同。
楊海潮：sharding通常是指垂直拆分和水平拆分，是一個總體的概念，mysql的partitioning是實現sharding的一種技術。
51CTO：新浪現在采用SQL+NoSQL結合的數據庫部署，那么對于兩種數據庫，分別是如何進行優化的呢？
楊海潮：目前NoSQL和MySQL是結合使用的，根據應用的特點選擇合適存儲方式。譬如：關系型數據，例如：索引使用MySQL存儲，非關系數據庫，例如：一些K/V需求的，對并發要求比較高的放入NoSQL產品存儲，或者通過關系數據復制到NoSQL(redis)來顯示不同的應用需求。
針對MySQL做的優化比較多，從硬件（使用SSD,Fusion-IO,Cachecade等），文件系統(嘗試XFS)，調整IO調度，優化參數，調整索引到減少應用對數據庫的訪問和交換等。
NoSQL(redis)通過修改源碼滿足自己的業務需求：完善它的replication機制，加入position的概念，讓維護更容易，同時failover能力也大大增強。改善Hashset在rdb里面的存儲方式，提升復雜數據類型的加載速度。
51CTO：如何保證數據庫的安全性的呢？
楊海潮：主要通過幾個方面進行考慮：
- 只通過內網進行訪問。
- 對來源IP做限制。
- 使用一定復雜度的密碼策略。
- 從程序的角度對于輸入進行檢查，例如使用綁定變量防止SQL注入。
- 對一些敏感的信息會記錄上操作日志，定期以報表的形式發給相關人員。
【編輯推薦】
