Jame’sReading04.06—04.23
來(lái)源：懂視網(wǎng)
責(zé)編：小采
時(shí)間：2020-11-09 13:09:40
Jame’sReading04.06—04.23
JamesReading04.06—04.23:http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一點(diǎn)經(jīng)驗(yàn):1. slow log的切換處理,2. 使用playback在Slave上重放操作,以warm up備庫(kù)的Buffer Pool. http://t.cn/zT6JusR 根據(jù)數(shù)據(jù)的價(jià)值來(lái)選擇匹配的數(shù)據(jù)存儲(chǔ)成本, 數(shù)
導(dǎo)讀JamesReading04.06—04.23:http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一點(diǎn)經(jīng)驗(yàn):1. slow log的切換處理,2. 使用playback在Slave上重放操作,以warm up備庫(kù)的Buffer Pool. http://t.cn/zT6JusR 根據(jù)數(shù)據(jù)的價(jià)值來(lái)選擇匹配的數(shù)據(jù)存儲(chǔ)成本, 數(shù)
http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一點(diǎn)經(jīng)驗(yàn):1. slow log的切換處理,2. 使用playback在Slave上重放操作,以warm up備庫(kù)的Buffer Pool. http://t.cn/zT6JusR 根據(jù)數(shù)據(jù)的價(jià)值來(lái)選擇匹配的數(shù)據(jù)存儲(chǔ)成本, 數(shù)據(jù)有三個(gè)維度(新鮮度,訪問頻
http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一點(diǎn)經(jīng)驗(yàn):1. slow log的切換處理,2. 使用playback在Slave上重放操作,以warm up備庫(kù)的Buffer Pool.
http://t.cn/zT6JusR 根據(jù)數(shù)據(jù)的價(jià)值來(lái)選擇匹配的數(shù)據(jù)存儲(chǔ)成本, 數(shù)據(jù)有三個(gè)維度(新鮮度,訪問頻率,商業(yè)價(jià)值,即:Recency/Frequency/Monetization), 根據(jù)這三個(gè)維度去評(píng)估存儲(chǔ)的數(shù)據(jù),并選擇對(duì)應(yīng)的存儲(chǔ)設(shè)備(Flash/SAS Disk/Sata Disk; Local/SAN).
http://t.cn/zT6G2jE 可擴(kuò)展系統(tǒng)設(shè)計(jì),常見技術(shù):1.負(fù)載均衡,各節(jié)點(diǎn)無(wú)狀態(tài),2.數(shù)據(jù)分區(qū)(DB Sharding),3.批量處理(M/R),4.緩存(靜態(tài)數(shù)據(jù)/動(dòng)態(tài)數(shù)據(jù)/連接池/重復(fù)計(jì)算),都權(quán)衡一定的一致性損失,5.異步處理,與業(yè)務(wù)解耦組合使用,一般都涉及使用隊(duì)列(Queue),6. 關(guān)注并發(fā)(Shared Mutable State,本文沒有)
就@bluedavy 的一條微博消息,我自己的一點(diǎn)看法:規(guī)模非常大的時(shí)候,相對(duì)于小規(guī)模場(chǎng)景,主要的技術(shù)差異也就拆分(partitioning/sharding)加上運(yùn)維自動(dòng)化, 而實(shí)際上,小規(guī)模業(yè)務(wù)也是可以去做運(yùn)維自動(dòng)化的. 因此, 除了不怎么需要做拆分(業(yè)務(wù)層/數(shù)據(jù)庫(kù)層)外,技術(shù)差異是很小的,就在于你自己的追求了. 【說你呢】哈哈
當(dāng)然，規(guī)模大了，如何提高運(yùn)維效率、發(fā)布部署效率，如何切實(shí)的減少、控制系統(tǒng)依賴的規(guī)模，如何有效的控制故障的范圍與等級(jí)，都會(huì)有更多的挑戰(zhàn)，而這些內(nèi)容，在追求完美的工程師來(lái)講，規(guī)模較小時(shí)也是可以做較多的嘗試與實(shí)踐的，比如遠(yuǎn)比淘寶規(guī)模較小的Etsy在這方面就有較多也較深入的經(jīng)驗(yàn)。
技術(shù)是為場(chǎng)景服務(wù)的，但是，不是等到有場(chǎng)景才有技術(shù)，而是需要在場(chǎng)景未到之時(shí)，先從其它渠道盡可能的了解到相關(guān)的技術(shù)，別人在此過程中曾經(jīng)遭遇的痛與坑，盡量做到不要重復(fù)的遇到別人曾經(jīng)遭遇的同樣的痛與坑。希望 @bluedavy 畢玄同學(xué)可以深入的分享下自己遭遇的那些痛與坑
我周日在ACOUG上進(jìn)行分享的PPT，從方法論的角度討論Oralce數(shù)據(jù)庫(kù)的優(yōu)化，優(yōu)化的關(guān)鍵點(diǎn)還是在于如何定位瓶頸資源（Contention），并通過Scale Up（優(yōu)化）或Scale out（拆分）的方式進(jìn)行緩解：”Oracle 性能優(yōu)化.pptx” http://t.cn/zT6PcMw
我4月18日在DTCC數(shù)據(jù)庫(kù)大會(huì)的演講：”CAP 理論與實(shí)踐.pptx”，主要觀點(diǎn)：1. 過去的所謂CAP，Pick Two過于簡(jiǎn)單粗暴，不合理，2. 現(xiàn)實(shí)的情況是，根據(jù)業(yè)務(wù)的數(shù)據(jù)的含金量確定可接受的C，再盡可能提高A，類似于信息展示類的會(huì)更多的選擇犧牲C，而資金類則保全C http://t.cn/zTxf7wO
http://t.cn/zTVs1Ll 如何通過RMAN將Oracle的數(shù)據(jù)庫(kù)備份到Amazon S3，其實(shí)備份到其它的類似的云存儲(chǔ)上，也可以考慮類似的處理方式。 Amazon AWS提供的白皮書，http://t.cn/zTVs1Lj
http://t.cn/zTcJYvz http://t.cn/zTcMuJa http://t.cn/zTcJYvZ 如何基于Unreliable Cloud設(shè)計(jì)Reliable System. 1. 識(shí)別應(yīng)用的有狀態(tài)部分與無(wú)狀態(tài)部分，2.使用真正的分布式的數(shù)據(jù)存儲(chǔ)來(lái)對(duì)有狀態(tài)部分進(jìn)行冗余處理，3.確保冗余處在隔離的故障區(qū)域，4.識(shí)別故障依賴并降低故障影響,5.將服務(wù)細(xì)化并隔離Complexity + Scale => Reduced Reliability + Increased Chance of catastrophic failures，The higher the number of dependent components => the lower the overall availability and the bigger the impact of failure，http://t.cn/zTcMuJa 這兩句話值得細(xì)細(xì)思考。
“The marginal cost of reliable hardware is linear while the marginal cost of reliable software is zero.” 可靠硬件的邊際成本是線性的，而可靠軟件的邊際成本為零。也即：在一定的規(guī)模下，可靠的軟件相對(duì)于可靠的硬件會(huì)更加便宜。http://t.cn/zTcIsx3
這篇文章中，我同意關(guān)于Reliable/UnReliable;Software/Hardware的比較，以及可能的邊際成本比較，對(duì)于其所舉的例子持保留態(tài)度。
其實(shí)，目前的Reliable Software也是通過冗余(Replication)來(lái)實(shí)現(xiàn)Reliable，就如同Reliable Hardware更多是通過Pair（雙份）來(lái)實(shí)現(xiàn)冗余，其它都是軟件控制//@jametong: 這篇文章中，我同意關(guān)于Reliable/UnReliable;Software/Hardware的比較，以及可能的邊際成本比較，對(duì)于其所舉的例子持保留態(tài)度。
幾篇關(guān)于Performance與Scalability的文章，http://t.cn/zTc4oZm http://t.cn/zTc4oZu http://t.cn/zTc4oZ3 可以通過優(yōu)化減少資源使用或提供更多資源來(lái)增加可擴(kuò)展性，前提是你的架構(gòu)允許使用更多的資源，也即并行化處理請(qǐng)求的能力，這通常來(lái)自于限制完全并行化能力的數(shù)據(jù)庫(kù)，原理即Amdahl定律
http://t.cn/zTtDU3Z Quora的創(chuàng)始人Adam D’Angelo討論為什么Quora使用MySQL而不是NoSQL，1.如果支持Sharding的話，MySQL的擴(kuò)展性并不差，2.NoSQL并不像宣稱的那么可擴(kuò)展，穩(wěn)定性還有待改進(jìn)，3.主數(shù)據(jù)存儲(chǔ)不能冒太大風(fēng)險(xiǎn),4.不拆分，MySQL的擴(kuò)展性也還好，5.可通過中間層解決分區(qū)兩年時(shí)間觀察下來(lái): 發(fā)現(xiàn)搞傳統(tǒng)RDBMS或一直在RDBMS上做工具和產(chǎn)品的人還是一樣的敏感，總是試圖去尋找看看誰(shuí)又在說“不用NoSQL的理由了”，聽者從中得到安慰。在如今RDBMS、NoSQL邊界越來(lái)越模糊，科研、工程技術(shù)人員都鉆破頭想著如何把兩者融合的現(xiàn)實(shí)中，總有人憂慮自己會(huì)的東西會(huì)不會(huì)過時(shí)!怎會(huì)過時(shí)呢？
回復(fù)@zhh-2009:兩者在融合，只是從兩個(gè)不同的方向在往中間努力。1. NoSQL在考慮增加一定的ACID支持，由于大規(guī)模Scalability的需要，目前主要還是基于單Sharding維度的ACD整合，2. 傳統(tǒng)RDBMS在整合部分NoSQL的理念，a. pg支持Schema Free，b.M支持基于引擎的調(diào)用，c.簡(jiǎn)化Sharding管理的大量工具
回復(fù)@zhh-2009:是的，這幾年很多存儲(chǔ)引擎層的改進(jìn)，都出現(xiàn)在寫優(yōu)化算法的改進(jìn)上，從這個(gè)角度看，其實(shí)我更加看好TukoDB與Acunu的改進(jìn)， LSM-Tree對(duì)讀是很不友好的，同時(shí)，Merge對(duì)資源的浪費(fèi)也是比較嚴(yán)重的，性能與吞吐量也會(huì)由于Merge的存在無(wú)法做到持久穩(wěn)定的性能，這對(duì)于生產(chǎn)環(huán)境的容量規(guī)劃是個(gè)問題
http://t.cn/zTUHTum 如何禁用Oracle 11g的新的xml格式的listener.log以及如何指定listener.log的位置。對(duì)于我這種古董級(jí)別的人有用處，哈哈。
http://t.cn/zYexkvH 如何利用Thread Pool提升MySQL系統(tǒng)的吞吐量，參造交通系統(tǒng)的流量控制，以及排隊(duì)論的基本知識(shí)介紹如何通過Thread Pool來(lái)提升系統(tǒng)的吞吐量，在沒有Thread Pool的情況下，系統(tǒng)的用戶到達(dá)率會(huì)不斷增加，而從不斷增加對(duì)系統(tǒng)關(guān)鍵共享資源（CPU、內(nèi)存）的占用，損害到整體的吞吐量。
新浪的面試題：用戶更新數(shù)據(jù)時(shí)，修改了database數(shù)據(jù)的同時(shí)需要修改memcache，為什么facebook這篇文章里面推薦用delete key的方法來(lái)更新cache，而不是直接update？
我的理解,兩個(gè)關(guān)鍵點(diǎn):
1. Update處理，由于Key不會(huì)從緩存中消除掉，如果由于程序重啟或其它原因?qū)е轮袛啵瑒t會(huì)導(dǎo)致緩存中的數(shù)據(jù)必須到過期(Evicted)，都會(huì)是Stale的數(shù)據(jù)，可以通過其它的機(jī)制來(lái)進(jìn)行補(bǔ)償，但是，代價(jià)也不低。//@TimYang: 估計(jì)用update的人更多一些，ugc類型產(chǎn)品，只要不是共享資源修改，通常也沒問題
2. 并發(fā)問題處理, 關(guān)鍵還是Delete操作是冪等的，并發(fā)問題容易解決；Update操作是帶狀態(tài)的，如何做好并發(fā)控制是個(gè)難題. 所以通過Delete＋Select的PutKey更加容易控制，復(fù)雜度也更低。關(guān)于更新緩存與數(shù)據(jù)庫(kù)更新不一致的問題，DELETE與Update Cache，需要考慮補(bǔ)償方案來(lái)解決。
3. @一樂 同學(xué)跟我說,Memcache的Delete操作有一個(gè)Holdoff功能,可以更好的控制Cache處理的并發(fā)問題.
http://t.cn/zTXSeHC 關(guān)于Message系統(tǒng)的簡(jiǎn)要介紹,Message的作用(性能/解耦合/擴(kuò)展性/成本與高可用),消息處理的模式(路由規(guī)則/是否持久化/消息轉(zhuǎn)換協(xié)議),常見消息系統(tǒng)的簡(jiǎn)要實(shí)現(xiàn)與特性,消息系統(tǒng)的功能需求的總結(jié),消息系統(tǒng)的運(yùn)維需求(持久化/高可用/管理特性),常見消息系統(tǒng)在不同場(chǎng)景下的性能比較.與此博客文章,對(duì)照閱讀: http://t.cn/zTXowBV 1.Brokers perform much better with bigger messages, 2. ZeroMQ is a perfect message dispatcher among processes,3. Except for big messages, RabbitMQ seems to be the best, 4. 對(duì)于較小的消息,時(shí)間被消耗在processing上,而不是I/O上.
Related posts:
- Jame’s Reading 04-05
- Jame’s Reading 03-16
- CAP Reading List
原文地址：Jame’s Reading 04.06 — 04.23, 感謝原作者分享。
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
Jame’sReading04.06—04.23
JamesReading04.06—04.23:http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一點(diǎn)經(jīng)驗(yàn):1. slow log的切換處理,2. 使用playback在Slave上重放操作,以warm up備庫(kù)的Buffer Pool. http://t.cn/zT6JusR 根據(jù)數(shù)據(jù)的價(jià)值來(lái)選擇匹配的數(shù)據(jù)存儲(chǔ)成本, 數(shù)
