支持TB級文件和百萬級目錄上傳的大數(shù)據(jù)上傳控件
標(biāo)簽:文件傳輸文件上傳文件下載開發(fā)商: 澤優(yōu)軟件
當(dāng)前版本: V2.0
產(chǎn)品類型:控件
產(chǎn)品功能:網(wǎng)絡(luò)通訊
平臺語言:
開源水平:不提供源碼
本產(chǎn)品的分類與介紹僅供參考,具體以商家網(wǎng)站介紹為準(zhǔn),如有疑問請來電 023-68661681 咨詢。
* 關(guān)于本產(chǎn)品的分類與介紹僅供參考,精準(zhǔn)產(chǎn)品資料以官網(wǎng)介紹為準(zhǔn),如需購買請先行測試。
TB文件支持
up7支持TB級單個文件的上傳及續(xù)傳,并且支持文件分塊存儲和整塊存儲兩種模式。
百萬級目錄支持
up7支持上傳100w+級別的文件夾,無論這個文件夾包含多個文件還是包含多層級文件夾。
安全
up7提供了數(shù)據(jù)加密功能。控件對上傳信息進(jìn)行加密,服務(wù)器端接收數(shù)據(jù)進(jìn)行解密。
采用多線程并發(fā)技術(shù)更加充分利用現(xiàn)有網(wǎng)絡(luò)資源并充分發(fā)揮高速網(wǎng)絡(luò)性能。
無論傳輸多大的資源服務(wù)器始終消耗最低的資源。
通過接口企業(yè)能夠非常方便的增加新的功能或修改已有的功能。
簡單高效是所有產(chǎn)品的黃金法則,而這一法則在up7中又一次得到了完美詮釋。在up7中我們對開發(fā),布署,應(yīng)用3個方面進(jìn)行了全方面的改進(jìn)。無論是開發(fā)人員還是普通用戶在使用過程中都將體驗到前所未有的暢快感。我們相信up7能夠真正的幫助用戶提高工作效率。
現(xiàn)在用戶選擇一個大文件夾(1萬個以上的文件+)后將會立即啟動線程對其進(jìn)行掃描,在掃描過程中用戶可以同時處理其它的工作,在掃描結(jié)束后將會立即開始上傳,up7的文件夾初始化時間僅需1秒。
大數(shù)據(jù)量的操作必然會使數(shù)據(jù)庫承受更多的壓力,up7充分考慮這一點,將所有數(shù)據(jù)庫的操作放在整個流程的末尾,將頻率最高的進(jìn)度操作使用緩存(Redis)代替,現(xiàn)在用戶在上傳超過100,000+的文件夾時系統(tǒng)也能夠輕松負(fù)載。 同時也能夠更加自由的選擇任意數(shù)據(jù)庫環(huán)境(MySQL,Oracle,SQL),甚至是SQLite或ACCESS 這種輕量級的數(shù)據(jù)庫也毫無壓力。
up7正以其卓越的性能在許多行業(yè)中發(fā)揮著巨大的作用,如醫(yī)療,建筑,地理測繪。在這些行業(yè)中不僅數(shù)據(jù)量非常龐大,同時對速度也有著苛刻的要求。但這些要求并不意味著用戶體驗的降低,相反更提升數(shù)倍。 例如我們針對用戶特別喜歡的文件夾功能進(jìn)行了大幅度的優(yōu)化幾乎重寫了整個模塊的代碼,現(xiàn)在這個功能已經(jīng)成為了他們?nèi)粘9ぷ髦惺褂妙l率最高的功能之一。
采用了分塊技術(shù)的up7對分布式實現(xiàn)了原生級別的支持,up7會將一個大型文件劃分成許多小文件塊進(jìn)行傳輸。 通過分塊能夠有效的減少服務(wù)器IO開銷同時大幅度提升并發(fā)能力。up7通過head域提供附加業(yè)務(wù)信息,服務(wù)端能夠非常方便的接收文件塊并進(jìn)行業(yè)務(wù)處理,如將文件塊保存在GridFS或Hadoop等分布式存儲系統(tǒng)中或其它NAS存儲設(shè)備中。
性能和并發(fā)是任何一個系統(tǒng)都必須要面對的問題,在網(wǎng)絡(luò)大數(shù)據(jù)應(yīng)用普及的今天,他們事實上已經(jīng)成為了項目成敗的關(guān)鍵因素。隨著用戶數(shù)量和使用頻率的快速增加,系統(tǒng)和數(shù)據(jù)庫很容易達(dá)到這一瓶頸。 由于項目預(yù)算和時間的有限性,使得開發(fā)人員通常沒有更多的時間和精力來針對這一方面進(jìn)行改進(jìn),也常常陷入兩難的選擇。 性能優(yōu)化是一個系統(tǒng)工程,他涉及到整個系統(tǒng)的多個方面,比如內(nèi)存,數(shù)據(jù)庫,IO等。 我們在up7與down3中對這個問題進(jìn)行了全面的思考與總結(jié),并對他們進(jìn)行了深度的整合。這種底層的緊密配合所帶來的性能提升,往往高于其它層面的數(shù)十倍甚至幾十倍,企業(yè)在相同投入前提下能夠獲得最大的收益。
更新時間:2018-06-28 14:30:58.000 | 錄入時間:2018-06-28 14:25:52.000 | 責(zé)任編輯:陳俊吉