本篇文章為大家展示了Salesforce和SAP HANA的元數據訪問加速是怎樣的,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
在Jerry的其他文章曾經提到,Salesforce里運行時對象均是通過靜態存儲的元數據,經過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.
既然元數據在salesforce平臺中扮演了如此重要的角色,那么運行時引擎對元數據的高效訪問就成為一個重中之重的話題,如果達不到這個目標,頻繁的元數據低效訪問將無法保證平臺上提供服務的高擴展性 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平臺設計了很多復雜的元數據緩存機制,確保最近訪問過的元數據駐留在內存里,避免了磁盤IO的開銷和代碼的重編譯,從而確保整個應用的響應時間不會影響元數據訪問受到影響。
ABAP Netweaver也有類似的設計,把很多需要高效訪問的數據特別是應用程序的元數據存儲到應用服務器的shared memory共享內存里。
使用事務碼SHMM查看shared memory內容:
SAP HANA里還能通過系統視圖system view M_METADATA_CACHE_STATISTICS來對元數據的緩存訪問進行分析:
上述內容就是Salesforce和SAP HANA的元數據訪問加速是怎樣的,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。