在加速大型可伸縮應(yīng)用的處理和分析方面，內(nèi)存數(shù)據(jù)網(wǎng)格已經(jīng)顯示出了潛力。它們通常會在后端數(shù)據(jù)庫和前端Web應(yīng)用之間提供一個有用的中間層。現(xiàn)在，它們也開始在所謂的大數(shù)據(jù)應(yīng)用中露臉了。
應(yīng)用內(nèi)存數(shù)據(jù)網(wǎng)格IMDG對很多東西都有好處，但是如果把它用在錯誤的問題上則會適得其反。它們可以很好地應(yīng)用在內(nèi)存數(shù)據(jù)集上。在內(nèi)存中處理PB級的信息并非你想去嘗試的東西。這方面有許多專門的系統(tǒng)能夠把這種規(guī)模的信息分析處理得更好。
盡管如此，應(yīng)用內(nèi)存數(shù)據(jù)網(wǎng)格（IMDG）時軟件架構(gòu)師還是必須要仔細考慮限制。對于定期調(diào)用的一組特定數(shù)據(jù)IMDG工作得很好。但是如果是不同的數(shù)據(jù)偶爾被查詢的話，IMDG可能并不是最佳的途徑。
如果應(yīng)用把數(shù)據(jù)當做對象處理，那么用數(shù)據(jù)網(wǎng)格就很好。可是如果應(yīng)用把數(shù)據(jù)當做SQL數(shù)據(jù)的話，可能最好還是用SQL數(shù)據(jù)庫。如果應(yīng)用與SQL語言對話，用數(shù)據(jù)網(wǎng)格去加速實現(xiàn)的效果往往是糟糕的。
有時候，對記錄的SQL數(shù)據(jù)系統(tǒng)的需求意味著IMDG的地位要比傳統(tǒng)的關(guān)系數(shù)據(jù)庫（RDB）低。硬件配置也會影響IMDG對整體系統(tǒng)架構(gòu)的適應(yīng)能力。最后管理IMDG的責任有時候會成為IT部門不同部分之間的問題。
有兩個特別重要的辦法可以幫助IMDG減少應(yīng)用延時。一是降低網(wǎng)絡(luò)和基于磁盤的通訊，二是以可以更好地在應(yīng)用中工作的對象格式來展示數(shù)據(jù)。
數(shù)據(jù)分區(qū)和數(shù)據(jù)關(guān)聯(lián)是部分非常適合于數(shù)據(jù)網(wǎng)格架構(gòu)的概念。當存在一個可工作好的領(lǐng)域模型時，數(shù)據(jù)網(wǎng)格工作得最好。有較弱的數(shù)據(jù)模型或沒有數(shù)據(jù)模型的應(yīng)用在采用數(shù)據(jù)網(wǎng)格時的問題最大，問題還需要在多個服務(wù)器之間方便地進行分割。
分布式緩存只有在應(yīng)用本身也是分布式的情況下才有意義-也就是說，出于伸縮性和/或可用性的原因需要運行在超過一臺機器上，如果分布式緩存是為了提供對數(shù)據(jù)的低延時訪問，那它就必須距離運行的應(yīng)用代碼很近-比方說，駐留在運行應(yīng)用的同一臺機器上，或者通過復(fù)制來提供可伸縮性。在其他情況下，緩存會把自己的數(shù)據(jù)存儲到多臺機器上。
應(yīng)用的數(shù)據(jù)訪問行為在確定數(shù)據(jù)網(wǎng)格是否最佳方案中可以扮演重要角色。如果應(yīng)用顯示出一致的數(shù)據(jù)訪問模式，像不斷訪問一個數(shù)據(jù)子集，或者同時訪問可輕易識別的條目組，我們就可以說該應(yīng)用有著好的數(shù)據(jù)局部性，緩存將會顯著改善其性能。對于應(yīng)用分布式緩存的應(yīng)用來說，最大的挑戰(zhàn)是提高數(shù)據(jù)局部性。這往往要通過對領(lǐng)域進行認真思考，并找出要緩存的東西是什么，以及如何展現(xiàn)緩存的數(shù)據(jù)-如非標準化來達到
數(shù)據(jù)網(wǎng)格是云基礎(chǔ)設(shè)施的關(guān)鍵組件之一，IMDG有希望能夠根據(jù)需求變化簡化伸縮的流程。比方說，如果你使用的是EC2,增加了100臺服務(wù)器，有一個數(shù)據(jù)網(wǎng)格來在這些服務(wù)器之間伸縮變化，看到的都是相同的實時信息，相互都了解對方，且不是100個不同的app,那么數(shù)據(jù)網(wǎng)格就會變得非常寶貴。如果你沒有能力以一種安全可靠的方式進行管理、可視化以及訪問，那么在云端建系統(tǒng)就會變得更加困難。
缺少標準接口是個值得注意的問題。為了解決這一需求，行業(yè)正在聯(lián)合推動即將出臺的javax.cache規(guī)范（在JSR107框架內(nèi)）。
對于云計算，我們已經(jīng)看到所有主流IaaS供應(yīng)商都引入了緩存作為服務(wù)。因此這已經(jīng)成為了基礎(chǔ)設(shè)施的一個標準部分。而面向云部署的Java EE 7,也將會出于同樣的原因吸納javax.cache,IMDG和云計算之間天然的緊密關(guān)系，相對于磁盤內(nèi)存，云對IMDG使用的固態(tài)內(nèi)存有一點偏好。
磁盤很慢，可是由于虛擬化以及NIC（網(wǎng)絡(luò)適配器）共享、網(wǎng)絡(luò)連接、物理驅(qū)動器的原因，云磁盤比它還要慢得多。但是IMDG并非適合于所有的大型應(yīng)用，在多次讀取相同的數(shù)據(jù)時緩存工作得很好。
各種類型的數(shù)據(jù)都非常適合于內(nèi)存數(shù)據(jù)網(wǎng)格，但是有些類型也許需要特殊的處理。如果有監(jiān)管或?qū)徲嬕螅敲纯赡苄枰惺侄文軌驅(qū)?shù)據(jù)推到像關(guān)系數(shù)據(jù)庫那樣的基于磁盤的數(shù)據(jù)解決方案上。當數(shù)據(jù)網(wǎng)格被用于所謂的數(shù)據(jù)庫起搏器時往往就會看見這種需求。所謂數(shù)據(jù)庫起搏器就是用數(shù)據(jù)網(wǎng)格來加速應(yīng)用對數(shù)據(jù)庫的訪問。不過最終記錄的系統(tǒng)還是數(shù)據(jù)庫。
另一個問題是管理IMDG的責任分配。數(shù)據(jù)在習慣上一般由DB管理員和操作員管理，而緩存往往是應(yīng)用結(jié)構(gòu)的一部分。我們已經(jīng)看到出現(xiàn)了一些情況，在確定由誰來對解決方案負責這個問題有一點糾結(jié)。
內(nèi)存數(shù)據(jù)網(wǎng)格開始在分析金融等領(lǐng)域的實時大數(shù)據(jù)應(yīng)用中扮演角色，這些領(lǐng)域的數(shù)據(jù)集往往有著數(shù)TB之巨大的熱門數(shù)據(jù)。盡管它們也可以用在其他地方，如根據(jù)Web日志重構(gòu)用戶會話，別的解決方案，如Hadoop可能會更合適。此外，IMDG也可以作為可伸縮云應(yīng)用的使能技術(shù)。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文標題：內(nèi)存數(shù)據(jù)網(wǎng)格發(fā)力云端和大數(shù)據(jù)
本文網(wǎng)址：http://m.hanmeixuan.com/html/consultation/1083936080.html
相關(guān)文章
