Salesforce和SAP HANA的元數(shù)據(jù)訪問(wèn)加速是怎樣的

本篇文章為大家展示了Salesforce和SAP HANA的元數(shù)據(jù)訪問(wèn)加速是怎樣的，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

Salesforce

在Jerry的其他文章曾經(jīng)提到，Salesforce里運(yùn)行時(shí)對(duì)象均是通過(guò)靜態(tài)存儲(chǔ)的元數(shù)據(jù)，經(jīng)過(guò)Runtime engine加工而成的。

Because metadata is a key ingredient of Force.com applications, the system’s runtime engine must optimize access to metadata; otherwise, frequent metadata access would prevent the service from scaling.

既然元數(shù)據(jù)在salesforce平臺(tái)中扮演了如此重要的角色，那么運(yùn)行時(shí)引擎對(duì)元數(shù)據(jù)的高效訪問(wèn)就成為一個(gè)重中之重的話題，如果達(dá)不到這個(gè)目標(biāo)，頻繁的元數(shù)據(jù)低效訪問(wèn)將無(wú)法保證平臺(tái)上提供服務(wù)的高擴(kuò)展性 high scalability。

With this potential bottleneck in mind, Force.com uses massive and sophisticated metadata caches to maintain the most recently used metadata in memory, avoid performance-sapping disk I/O and code recompilations, and improve application response times.

Salesforce平臺(tái)設(shè)計(jì)了很多復(fù)雜的元數(shù)據(jù)緩存機(jī)制，確保最近訪問(wèn)過(guò)的元數(shù)據(jù)駐留在內(nèi)存里，避免了磁盤IO的開(kāi)銷和代碼的重編譯，從而確保整個(gè)應(yīng)用的響應(yīng)時(shí)間不會(huì)影響元數(shù)據(jù)訪問(wèn)受到影響。

SAP

ABAP Netweaver也有類似的設(shè)計(jì)，把很多需要高效訪問(wèn)的數(shù)據(jù)特別是應(yīng)用程序的元數(shù)據(jù)存儲(chǔ)到應(yīng)用服務(wù)器的shared memory共享內(nèi)存里。

使用事務(wù)碼SHMM查看shared memory內(nèi)容：

SAP HANA里還能通過(guò)系統(tǒng)視圖system view M_METADATA_CACHE_STATISTICS來(lái)對(duì)元數(shù)據(jù)的緩存訪問(wèn)進(jìn)行分析：

上述內(nèi)容就是Salesforce和SAP HANA的元數(shù)據(jù)訪問(wèn)加速是怎樣的，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。