走進(jìn)架構(gòu)新思維--分布式文件系統(tǒng)應(yīng)如何設(shè)計(jì)

cjfeii

樓主大才，先站樓，搶沙發(fā)

T-Bagwell

1、異構(gòu)存儲(chǔ)（磁盤、SSD、內(nèi)存）以及冷溫?zé)釘?shù)據(jù)存儲(chǔ)架構(gòu)您覺得如何設(shè)計(jì)？比如數(shù)據(jù)熱度由熱到溫最后到冷，對(duì)應(yīng)的存儲(chǔ)如何自適應(yīng)的將數(shù)據(jù)轉(zhuǎn)換和保存？
目前能夠想到的就是冷數(shù)據(jù)存入機(jī)械 SATA 盤，熱數(shù)據(jù)存入 SSD + 內(nèi)存，如果是非重要的熱數(shù)據(jù)，直接存入內(nèi)存，比如 Cache，如果是重要的熱數(shù)據(jù)，可存入 SSD，如果對(duì)性能要求并不是很高，可以考慮存入 SATA，新寫入的數(shù)據(jù)可以存入 SSD 或者內(nèi)存，如果熱度很低，可以切換至存儲(chǔ)到 SATA，不重要的基本上可以直接刪掉，根據(jù)業(yè)務(wù)場景設(shè)計(jì)，不同的業(yè)務(wù)的需求也不同。

2、有的應(yīng)用讀寫并發(fā)并不大，而對(duì)元數(shù)據(jù)的操作確異常頻繁，如何設(shè)計(jì)一個(gè)以讀為主的元數(shù)據(jù)服務(wù)架構(gòu)或者設(shè)計(jì)一個(gè)以寫為主的元數(shù)據(jù)服務(wù)架構(gòu)？
讀寫并發(fā)不大，對(duì)元數(shù)據(jù)操作頻繁這種一般很有可能是小文件，開銷主要用在對(duì)元數(shù)據(jù)操作部分了，根據(jù)場景不同設(shè)計(jì)的也不同，一般都是元數(shù)據(jù)集群，元數(shù)據(jù)存儲(chǔ)在 SSD + 內(nèi)存做元數(shù)據(jù) Cache，跟設(shè)計(jì)的算法也有關(guān)系。

3、當(dāng)前無論是 CEPH 還是GFS，都存在IO路徑過長的問題，有什么方法能緩解這種情況?
Ceph 的性能還不錯(cuò)， GFS 沒有用過，不過 Ceph 使用 API 方式性能還不錯(cuò)，但是穩(wěn)定性確實(shí)不太好說，目前我沒遇到問題，但是也沒商用過，因?yàn)槲也惶�喜歡API方式，一般還是 Posix 接口操作，方便，直接 mount 就當(dāng)本地盤使用了。

4、使用分布式文件系統(tǒng)后，如何快速的檢索數(shù)據(jù)？
最快的方式當(dāng)然還是 Hash 表，O(1), 也有其他的方式應(yīng)該，只不過我沒有用過，因?yàn)槲疫�是比較喜歡 Gluster 這種 Hash 計(jì)算文件存儲(chǔ)位置的方式，加上一直以來都是做大文件，所以這個(gè)并不是太大的問題。

5、云存儲(chǔ)的數(shù)據(jù)分享、隔離和安全性怎么做？
這個(gè)主要還是在應(yīng)用層去做，直接從業(yè)務(wù)部分去劃分好些，如果必須在文件系統(tǒng)層做，可以增加 ACL ，或者根據(jù) UID 進(jìn)行權(quán)限控制，因?yàn)?GNU/Linux 本身就有相關(guān)的控制設(shè)計(jì)了

6、你對(duì)IT架構(gòu)的發(fā)展前景怎么看？有什么新的想法嗎？
目前沒什么看法，需要的還是創(chuàng)新，單玩存儲(chǔ)也玩不出什么太多的花樣了，而且都是跟著開源的改來改去的，要么就是都覺得自己開發(fā)出來的好，其實(shí)好多也是自 high 的狀態(tài)

ruochen

數(shù)據(jù)一般有一下幾個(gè)劃分緯度:
1）數(shù)據(jù)訪問頻度：熱、溫、冷
2）數(shù)據(jù)安全等級(jí)：高、低
3）數(shù)據(jù)大小量級(jí)：大、小

數(shù)據(jù)安全性要求高且比較熱的數(shù)據(jù)，數(shù)據(jù)量級(jí)中等或者偏小，一般用memory+PCIe SSD的方案來解決，特別是那種隨機(jī)io比較高的，再配合cache、cdn等方法解決，按成本和重要性也可以將PCIe SSD改為SATA SSD
數(shù)據(jù)安全性要求高比較冷的數(shù)據(jù)，數(shù)據(jù)量級(jí)偏大，一般用SATA+本地cache
介入上兩種之間的溫?cái)?shù)據(jù)，就看自己色的投入多少成本了，數(shù)據(jù)的安全性等如何考慮了，數(shù)據(jù)的冗余分?jǐn)?shù)和重復(fù)數(shù)據(jù)刪除等方法都可以用上

隊(duì)列、CDN、CACHE等方法綜合應(yīng)用特點(diǎn)和成本因素來考慮吧，畢竟每家公司的業(yè)務(wù)都有一些自己的特殊性在里面

對(duì)于大規(guī)模的存儲(chǔ)應(yīng)用，創(chuàng)業(yè)型互聯(lián)網(wǎng)應(yīng)用我偏向無中心的并行擴(kuò)展架構(gòu)，這樣在用戶規(guī)模快速增加的時(shí)候增加人手和服務(wù)器是能抗住的
目前永久留存的的小圖片和小語音采用的余總的FastDFS，冗余2份、3份不等
在小隨機(jī)的GPS數(shù)據(jù)采集上用的Redis（寫cache）+LevelDB（持久化），冗余2份、3份不等

myworkstation

1、異構(gòu)存儲(chǔ)（磁盤、SSD、內(nèi)存）以及冷溫?zé)釘?shù)據(jù)存儲(chǔ)架構(gòu)您覺得如何設(shè)計(jì)？比如數(shù)據(jù)熱度由熱到溫最后到冷，對(duì)應(yīng)的存儲(chǔ)如何自適應(yīng)的將數(shù)據(jù)轉(zhuǎn)換和保存？
     數(shù)據(jù)的冷熱與存儲(chǔ)介存的訪問性能應(yīng)該是直接對(duì)應(yīng)關(guān)系:內(nèi)存=熱,SSD=溫,磁盤=冷，在SSD價(jià)格不斷下滑的情況下磁盤應(yīng)該在不遠(yuǎn)的將來被會(huì)替換為SSD，最終冷數(shù)據(jù)的訪問應(yīng)該從硬件層面上得到相關(guān)程度的緩解。數(shù)據(jù)的轉(zhuǎn)移可以假設(shè)以下情況：存儲(chǔ)介質(zhì)根據(jù)訪問情能分為了3個(gè)層次，數(shù)據(jù)的冷熱程度分為9個(gè)層次(熱1-3,溫4-5,冷6-9)，數(shù)據(jù)定期的根據(jù)冷熱系數(shù)轉(zhuǎn)移到特定的存儲(chǔ)介存，可以增加冷熱系數(shù)調(diào)整轉(zhuǎn)移的緩沖期和頻率。
2、有的應(yīng)用讀寫并發(fā)并不大，而對(duì)元數(shù)據(jù)的操作確異常頻繁，如何設(shè)計(jì)一個(gè)以讀為主的元數(shù)據(jù)服務(wù)架構(gòu)或者設(shè)計(jì)一個(gè)以寫為主的元數(shù)據(jù)服務(wù)架構(gòu)？
     大文件和小文件是兩個(gè)完全不同的問題，小文件常常導(dǎo)致無數(shù)據(jù)操作頻繁，那么元數(shù)據(jù)服務(wù)干脆就分開處理，一個(gè)完整的元數(shù)據(jù)服務(wù)架構(gòu)由分別偏向讀寫的兩個(gè)異構(gòu)的元數(shù)據(jù)架構(gòu)組成而成。
3、當(dāng)前無論是CEPH還是GFS，都存在IO路徑過長的問題，有什么方法能緩解這種情況?
     根據(jù)最近訪問記錄緩存路徑信息來提供快速訪問貌似是比較可行的，但是如何在訪問文件時(shí)減少內(nèi)部容器和模塊間的信息訪問和傳遞得視具體實(shí)現(xiàn)而定了。
4、使用分布式文件系統(tǒng)后，如何快速的檢索數(shù)據(jù)？
     檢索數(shù)據(jù)分為定位和讀取兩個(gè)操作，相對(duì)于定位來講讀取是絕對(duì)的慢操作，那么在讀取時(shí)可以合并讀取請(qǐng)求，盡可能一次讀取服務(wù)多個(gè)請(qǐng)求。
5、云存儲(chǔ)的數(shù)據(jù)分享、隔離和安全性怎么做？
     分享與安全是個(gè)永恒的話題，目前大多數(shù)數(shù)據(jù)安全問題出現(xiàn)在用戶端，與訪問終端合作定制對(duì)用戶透明的更嚴(yán)格和復(fù)雜的訪問規(guī)則是一個(gè)方向，同時(shí)針對(duì)數(shù)據(jù)訪問本身應(yīng)該提時(shí)效性處理，每一次外部數(shù)據(jù)訪問都不是可持續(xù)的，其時(shí)效長度由用戶的安全等級(jí)決定。
6、你對(duì)IT架構(gòu)的發(fā)展前景怎么看？有什么新的想法嗎？
     軟件的實(shí)現(xiàn)一直受限于硬件的能力，所以很難在有效的條件下有顛覆性的創(chuàng)新，隨著硬件能力的快速提升和應(yīng)用規(guī)模的急劇擴(kuò)大，IT架構(gòu)總會(huì)不斷變化以適應(yīng)需求的。

cokeboL

板凳坐上先

vermouth

覺得現(xiàn)在成熟產(chǎn)品的架構(gòu)都不大會(huì)動(dòng)了，云什么新東西都是一些邊緣產(chǎn)品。

ps：我要傘

niao5929

先頂起來再思考

heguangwu

當(dāng)前如果沒有新的需求架構(gòu)基本已經(jīng)算穩(wěn)定了，只要將他搞穩(wěn)定，提高性能就萬事大吉
回復(fù) 4# vermouth


   

heguangwu

拋磚引玉
回復(fù) 2# cjfeii


   

heguangwu

GlusterFS確實(shí)有好的地方，但不好地方是遍歷整個(gè)目錄時(shí)比較麻煩并且不支持模糊查詢文件名，此外，有一些獨(dú)特的應(yīng)用是需要不停的list目錄，這種方式GlusterFS就不那么好了，而且中心節(jié)點(diǎn)master的這種方式也扛不住
回復(fù) 6# T-Bagwell