1.數據存儲css
a.集中式----》分佈式html
複製m/s、切分前端
a.1切分html5
垂直切分(按功能模塊)java
難點:跨域的表關聯---》應用程序mysql
事務----------》分佈式的事務(單獨數據源的小事務,而後經過程序控制)nginx
某些表訪問劇增-----》讀寫分離web
讀寫分離(異構數據源之間的讀寫分離)redis
相同數據源,只須要master/slave算法
難點:異構數據源之間的全量複製問題
異構數據源之間的增量同步問題(解析日誌)
水平切分(按記錄切分----》找規則)
a.2 數據切分及整合的中間件
瞭解其它中間件(服務框架中間件、消息中間件)
mysqlProxy---->只針對mysql LUA腳本
amoeba ----->框架
----->amoeba for mysql
----->amoeba for Aladin
corba ---->文檔較少,能夠關注 14年會有新版本發佈。
b.引入NOSQL---》多種存儲方案(不一樣類型的數據,存儲在不一樣的數據源)
nosql分類
key/value 內存數據庫------->Memcached、redis
bson 文檔數據庫------->Mongodb
db----database
collections----table
document----record
Column-Family 列數據庫----->Cassandra/hbase
---------------------------前三種是聚合模型
關係 圖數據庫-------> neo4j
nosql --->CAP理論
互聯網的應用AP+BASE原則
c.統一數據服務平臺(讓數據透明)-----》如何設計
c.1 對外提供的統一的查詢API,持久API
c.2 可以支持異構數據源(關係、非關係)
c.3數據源改造不須要大面積重構數據平臺
c.4性能優化(延遲加載、按需加載、熱點緩存、異步並行加載)
熱點緩存:(熱點規則、key規則、過時規則)
異步並行加載
d.數據同步
d.1 相同的多數據源直接使用master/slave機制(數據量不太大)
d.2 數據量特別大or異構數據源
TimeTunnel2(tailFile組件、saveFile組件,dfswrite組件)
tailFile組件抓取日誌增量、爬蟲增量數據
saveFile 保存到磁盤
dfswrite寫入hdfs
DataX
異構數據源之間的導入導出工做
框架+插件的模式(讀插件、寫插件)
Dbsync
e.分佈式緩存Memcached(key/value)
e.1特色
內存存儲(對內存要求高,對CPU要求低,選擇對內存要求低對cpu要求高的應用部署在一塊兒,節約硬件資源)
集中式的緩存(每臺實例都是獨立的,不支持通信,單點問題支持橫向擴展,把客戶端包含在一塊兒是分佈式的)
分佈式擴展(支持動態添加機器)
Socket通信(只要支持socket得語言均可以支持其客戶端。以java爲例,就須要注意序列化的問題、序列化優化的問題)
特殊的內存分配機制(每一個對象最大隻能1m)
緩存機制簡單(就兩次hash,一次定位實例,一次放入HashMap)
e.2 安裝啓動
啓動參數:-d,-m內存大小,-n、-f未來對調優很重要
e.3Memcached基本命令
set/add/replace/cas/get/gets/incr/decr/delete/stats
e.4 客戶端操做
java客戶端的操做優化:
e.4.1提煉接口
e.4.2用配置文件的方式代替硬編碼初始化客戶端
e.4.3單點問題---》備份
Memcachedb-->新浪BerkeleyDB
淘寶實現的cluster機制---》經過java語言實現的
e.4.4本地緩存(OSCache/EhCache)結合Memcached
e.4.5Memcached提供的java源碼中都是用java5以前的
線程處理技術,會影響性能。用鎖對象替換synchronized,用java5提供的線程安全的集合類提供性能
e.4.6java中客戶端讀數據時,是單字節讀取的
e.5集羣操做
一致性hash運算 c(libMemcached已經實現了該操做)
自己服務器端是不直接支持集羣的。
Memcached不少時候都用在了數據庫前端緩存
MSM(Memcached session manager)
網站架構中的緩存
頁面緩存(OSCache,EhCache)
頁面靜態化(io/xml+xslt)
頁面局部緩存(OSCache/EhCache/Etag)-->用的都是標籤
瀏覽器緩存(header操做/瀏覽器插件/html5)
反響代理服務器緩存(nginx+squid)
webServer自己的緩存
e.6 redis
支持更豐富的數據類型 key/value(二進制)
支持持久化(單點問題就解決了)
master/slave(master宕機以後slave自動升級)
e.6.1string/ list/hashes(hashmap)/set/sorted-set
e.6.2rdb方式 aof的方式
e.6.3master/slave機制
當slave斷開,從連以後,沒有增量操做,會刪除
slave以前全部的數據而後,從master重新所有獲取
解決:增量讀取
master宕機以後,slave自動升級(切換達到秒級實現redis自動切換功能達不到這個效率)
解決:keepalived
e.6.4java客戶端jedis(集羣的問題)
e.6.5redis優化
2.數據庫的查詢優化
硬件規劃:tpc(非盈利性組織,測試服務器性能,tpcc,tpmc科學數據)
mysql查詢優化:
a.優化器模塊
a.1計算出最優的執行計劃、
a.2mysql新技術繞過它---handlersocket(把mysql改形成了nosql) 批量處理、長鏈接性能極高、全部數據都適合放入內存
b.優化原則
找高併發的query語句
反覆查看執行計劃和性能瓶頸分析
用小結果集驅動大結果集---》和join算法有關
儘量在索引中完成排序
只返回本身須要的列
只用最有效的條件
儘可能減小join和子查詢
c.索引
利:排序的時候減低cpu的使用,查詢的時候下降了IO
弊 : 若是列中創建索引,每次修改這列數據,都會更新索引
何時用:頻繁做爲查詢條件,且修改較少的字段
索引失效:
在查詢語句中索引字段上作任何的計算、函數、類型轉換都會使得索引失效,變成全表掃描
在索引列上作模糊查詢以通配符開頭索引失效全表掃表
在索引列上使用!=,索引列失效
非等值鏈接 hash索引失效
d.join優化
mysql join效率自己不好 join必定是不多用的(切分、適當的冗餘)
d.1小結果集驅動大結果集
d.2儘可能被驅動表經過索引查詢(注意索引失效的問題)
d.3 join_buffer_size的配置,儘可能增大
e. order by優化
e.1儘可能在索引列上完成排序(注意索引失效問題)
e.2若是不能再索引列上要求增大max_length_for_sort_data
參數的設置,比返回的最長的列要大便可。
mysql內部有兩種排序算法(老、新)
e.3只返回本身須要的列
e.4增大sort_buffer_size參數的設置
f.group by 優化
先排序再分組
f.1同上e
f.2能再where中限定的不要去having限定(若是能夠的話)
g:DISTINCT
先排序再分組,而後每組取一條(同f)
mysql Server優化:
a.安裝 ---》使用二進制、源碼安裝(gcc編譯器)
icc(intel c comiler)編譯器是新的技術,提升了源碼中計算性能,使得查詢性能默承認以提升30%左右(泛化的數字)
b.淘寶80%的服務器安裝的percona數據庫
percona公司---》產品persona(對mysql源碼進行了修改)
IO性能處理、內存處理、併發處理等方面都作了優化,並
提供了豐富的性能檢測工具,percona必須源碼安裝,提供
了不少插件的接口,能夠加入新技術。如flashCache(把mysql
的一級緩存改形成了二級緩存)
c.Mysql query Cache
優勢:
缺點:計算有消耗、存的結果集會重複存
mysql 存儲引擎
MyISAM
1.不支持事務、表關係
2.操做的是表鎖、併發太多服務會宕掉
3.緩存的時候,只緩存索引不緩存真實的數據
,真實的數據時經過OS級別的緩存,因此對內存要求低。
INNODB
1.支持事務和關係
2.操做的時候是行鎖,支持併發操做
3.緩存的時候既要緩存索引也要緩存真實數據,對內存要求
高,有一個很是關鍵的參數設置,直接決定了數據庫的性能
innodb_buffer_pool_size除掉獨佔內存和適當冗餘所有 給它。
xtrdb
percona出品的xtrdb存儲引擎徹底能夠替代innodb
而且在併發和內存使用上有更多的提升
mysql新技術:
handlersocket(淘寶內部客戶端操做是封裝成了中間件)
percona/xtrdb
flashCache
高性能的編譯器intel c compile
瞭解高性能的分佈式文件系統 ext3/ext4
Oracle查詢優化
1.oracle共享池原理(必需要如出一轍簡單的sql語句大小寫、空格 、參數名稱等要徹底如出一轍)
2.不要讓oracle作的太多
2.1避免複雜的join和子查詢
2.2不要使用* (查詢數據字典、列出全部列、用別名能夠提升效率)
2.3用EXISTS替換DISTINCT
DISTINCT 排序分組取單一
2.4用UNION-ALL 替換UNION ( if possible)
UNION會先作union-all而後排序
3.給優化器更明確的命令(索引使用--->避免索引失效)
3.1若是有惟一性索引和非惟一性索引oracle只
識別惟一索引
3.2若是是複合索引,複合索引的第一列必須出現纔會使用索引
不然會作全表掃描
3.3任何在索引列上的操做(函數、計算、類型轉換等)
都會使得索引失效,而進行全表掃描
3.4模糊查詢時避免在索引列上使用前置通配符,不然索引失效
,進行全表掃描
3.5不要索引列上使用NOT操做,is null ,is not null
4.細節上的影響
4.1多表查詢的時候把條件限定後結果集最少的放在條件的最右邊
4.2儘可能不要在列上作任何計算、函數、轉換等,防止索引失效
4.3order by放在索引列上,並禁止使用表達式
4.4用where子句替換having字句(可能的話)
4.5用NOT EXISTS 替代NOT IN
4.6儘可能少使用等值鏈接替換非等值鏈接
3.數據庫的設計優化
3.1第一範式、二範式... ...五範式(解決數據的冗餘)
3.2範式和非範式集合使用(有的時候須要適當冗餘數據減小join)
3.3大字段垂直拆分、列的訪問存在差別(有的列特別頻繁,有的列不多訪問)也要作垂直拆分
3.4大表水平拆分
3.5儘可能使用小的空間、儘可能使用運算快的數據類型(儘可能能用數字的用數字表示)
4.數據集成(統一數據服務平臺)
a.統一API,而且可以適應數據源的改造(面向對象的操做)
關係數據庫---->hibernate
非關係型數據庫---->spring-data for Mongodb
spring-data for Mongodb for Reids
b.對象的屬性和數據中的類型不必定直接匹配
對象到數據源之間的類型映射轉換
數據源到對象之間的類型映射轉換
c.性能優化
c.1熱點緩存
熱點可配置
二級緩存(一級緩存索引、二級緩存對象,過濾重複)
過時(相對過時、絕對過時、事件過時--->消息中間件)
c.2 異步並行加載(線程的異步設計)
代理思想(代理模式實現)
並行的執行容器(線程的操做)
5.業務層----》分佈式架構---》soa
6.前端
js/css合併
js動態加載(labjs/require js/control js)
mvc