浅谈可扩展的MySQL数据库设计-整理

聽了一個視頻關於mysql的 http://www.infoq.com/cn/presentations/fengdahui-mysql
冯大辉，就职于阿里巴巴集团旗下支付宝（中国）网络科技有限公司（Alipay.com），担任数据库架构师，负责支付宝数据库架构规划、解决方案等相关 工作。2007 年国内首批 Oracle ACE. 网上 ID 为“Fenng”，业余时间关注 Web 2.0 网站架构技术。个人Blog：http://www.dbanotes.net。
這個哥們也是我比較欽佩的人之一。
整理如下：當然不全，不過有些東西是我原來犯過的錯誤：），很有意義！
以後工作中可以用上。


scale up and scale out
scale up 我的理解就是硬件上的升級；
scale out 可能對與無論是開發人員還是數據庫管理人員都是有一定的要求的，也就是下面要注意的東西：比如一些技巧，和架構上的調整；

一定要做基準測試，很多公司和個人都不愿意做基準測試，怕麻煩，其實應該做一下，在不同場景下的基準測試，心裡有個底。
最基本的基準測試包括：
IO, 文件系統的基準測試
網絡基準測試
Cache基準測試
App基準測試

對於IO，最簡單使用dd這個配合一些參數即可完成。
無論是那個廠家的產品，你心裡一定要有數，他們說的不算，你要實際的測試一下才可以
很多時候技能跟人有關係（是新手還是老手）跟公司（設備廠商）沒有關係

nfs的一些參數的設定還是很有講究的

網路基準測試：
最簡單的辦法就是dd結合ftp 壓一下。

如果應用上線前沒有進行基準測試，以後再找問題的所在就麻煩了，牽扯到生產環境的應用，對其肯定有影響。

Cache的基準測試：
Cache的命中率， 難點在於數據量大的情況下，模擬是一個比較難的事情

Mysql持久性connection
建議儘量使用pconnection(持久性connection)，如果使用非持久connection可能在數據量大的應用上出現連接風暴，
比如用戶大規模上線，用戶大規模下線，對應用衝擊是很大的。
在能控制總的數據庫連接的情況下，最好使用pconnection.我的理解是“儘量減輕數據庫顛簸”。

選取合適的數據類型
老生常談的問題， 但是也有一定意義。n多老DBA陰溝翻船的事。
主要是Mysql不允許在線DDL，（Mysql5不知道是否支持），帶來的問題就是，在應用跑過一段時間后，對相關表的修改是比較痛苦的過程。
可以想象一下：幾百萬用戶上線的情況下，修改表結構，肯定會造成用戶體驗上的影響。
建議，前期，可用可不用的加上去，避免後期添加的麻煩。
一個例子：
ipv4如果用varchar來存取，耗費空間
Tip:
eg:ip2long()/ long2ip() 存儲整數而非字符串
效果會好一些。

非關係型數據的存儲選擇
.圖片
--
.HTML內容的處理
--把html的放到db是糟糕的設計；
--圖片使用hash映射的機制
--數據庫存圖片，後期的處理很糟糕，非關係的處理
.行存儲vs. 列存儲
sebytes BI
列存儲

分區和sharding(分片）
mysql中就沒有分區；現在已經有了這個能力，性能不好說；

分區能解決的問題；分區是數據庫比較核心的功能，
可能都遇到，數據庫過對歷史的問題會很糟糕！
歷史數據在一個籃子里，比較麻煩

分區的物理屬性
mysql的分區的能力，不評價，有這個能力了
目前mysql還沒有全局索引，
sharding--分片，分庫；很多網站都在用
China-mobile--用戶的數據就分開了

拋棄存儲過程封裝業務邏輯的思路：
有些開發人員，用存儲熟了，外面用php,java調用就可以了，
所有的記賬系統都是在數據庫上（存儲過程），等業務到了一定的時候
麻煩來了，很少有人即懂業務，又懂數據庫， 還懂業務。

所以，業務邏輯儘量不要放在database中進行，在app中就可以了，要不問題在後面

合理的使用cache
cache用的很多也不是好事情，
最常見的，應用場景，read多, cache， 跟經驗值有關係

在不同的點放上cache有關係
在那個點上加入cache是有講究的。