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