1 Salesforce的簡介
在雲計算方面，Salesforce可以稱爲業界的領袖，它不僅在產品方面比較成熟，而且在思維方面也是引領潮流的，特別是在SaaS（Software as a Service，軟件即服務）和PaaS（Platform as a Service，平臺即服務）這個兩個領域內。
圖1. Salesforce 商標（圖源自Salesforce.com）
首先，簡要地介紹一下Salesforce的歷史：Salesforce.com在1999年由前甲骨文高管 Marc Benioff創立，他創辦Salesforce的核心理念就是"NoSoftware（消滅軟件）"，但是其意義並不是排斥所有的軟件，而是主要排斥運行在企業數據中心的軟件（On-Premise Software），也就是希望讓用戶能直接通過互聯網來使用諸如CRM等軟件服務，並同時讓用戶無需自己搭建和維護軟件所需的硬件和系統等資源。Salesforce的主要產品包括Sales Cloud（CRM）、Service Cloud、Chatter和Force.com等。下面是它的主要發展史：
- 1999年，Salesforce在美國舊金山成立。
- 2001年，推出了第一款SaaS應用CRM，同時也受到衆多廠商和客戶的熱議。
- 2004年，Sunguard成爲Salesforce第1000位用戶。
- 2005年，推出了名爲"AppExchange"的程序商店，以豐富用戶選擇。
- 2006年，推出了首個運行在雲計算平臺的語言Apex，並在語法上類似Java。
- 2007年，推出了它的PaaS平臺Force.com，來讓用戶更方便地在Saleforce平臺上開發在線應用，同時Salesforce憑藉Force.com得到了華爾街日報的科技創新獎（Technology Innovation Award）。
- 2009年，Salesforce成爲首家年收入達到10億美元的雲計算公司，並在年初推出了名爲"Service Cloud"在線客戶服務應用。
- 2010年，Salesforce將推出名爲"Chatter"的企業級在線SNS服務，類似於企業內部的"LinkedIn"，同時其CRM應用已更名爲"Sales Cloud"。
1.1 Salesforce的整體架構
雖然Salesforce這些產品從表面而言有所不同，但是從全局而言，它們卻是一個整體，具體可看下圖：
圖2. Salesforce的整體架構（圖部分源自Salesforce.com）
從這張Salesforce的整體架構圖可以看成，Force.com是 Salesforce 整體架構的核心，因爲它首先整合和控制了底層的物理的基礎設施，接着給上層的Sales Cloud，Service Cloud，Chatter和基於Force.com的定製應用提供PaaS服務，最後，那些Force.com上層的應用以SaaS形式供用戶使用。這樣做的好處主要有兩方面：其一是關於成本的，因爲通過這個統一的架構能極大地整合多種應用，從而降低了在基礎設施方面的投入。其二是在軟件架構方面，因爲使用這個統一的架構，使得所有上層的SaaS服務都依賴Force.com的API，這樣將有效地確保API的穩定性並避免了重複，從而方便了用戶和Saelsforce在這個平臺上開發應用。
雖然Salesforce的"SalesCloud"等SaaS應用也比較經典，但由於Force.com堪稱整個架構的核心，同時也是最值得的學習和借鑑的部分，所以本系列接下來將會把重點對準Force.com。
1.2 Force.com
Force.com是Salesforce在2007推出的PaaS平臺，並且已經有超過47000位企業已經使用了這個平臺。Force.com基於多租戶的架構，其主要通過提供完善的開發環境等功能來幫助企業和第三方供應商交付健壯的，可靠的和可伸縮的在線應用。
圖1. Force.com 商標（圖源自參[3]）
總體而言，Force.com主要有五方面功能：
- 強大的定製功能：在Force.com，不僅UI能夠定製，而且諸如Workflow和表格等也能被定製。
- 提供完善的開發環境：首先，通過Visualforce能方便地使用"Drag & Drop"的方式來設計頁面。其次，Salesforce提供基於Eclipse的IDE來快速地開發應用。最後，Salesforce還提供Sandbox來方便用戶測試。
- 支持複雜的事務和流程：通過Force.com專屬的APEX語言，能方便地設計和開發複雜的事務和流程。
- 優秀的整合功能：用戶除了可以在AppExchange購買其所需的功能和應用，而且還可以通過Force.com的Web Service接口來和其他應用整合，比如SAP等。
- 久經考驗的基礎設施：由於Salesforce除了通過在多個大洲建有數據中心來應對災難的發生，而且在可用性和安全性等方面也有一定積累，所以在Salesforce能長時間地支持衆多服務的正常運行。
2 多租戶的介紹
2.1 概念
雖然對我們而言，多租戶(Multitenancy)可以算是一個非常新穎的概念，但是其實這個概念已經由來已久了。簡單而言，多租戶指得就是一個單獨的軟件實例可以爲多個組織服務。一個支持多租戶的軟件需要在設計上能對它的數據和配置信息進行虛擬分區，從而使得每個使用這個軟件的組織能使用到一個單獨的虛擬實例，並且可以對這個虛擬實例進行定製化。但是要讓一個軟件支持多租戶並非易事，因爲不僅對它的軟件架構進行相應的修改，而且需要對它的數據庫結構進行特殊的設計，同時在安全和隔離性方面也要有所保障。
還有，爲了幫助大家進一步理解多租戶這個概念，特別選取兩個和多租戶比較接近的概念來進行進一步的辨析。
多租戶和多用戶的區別
多用戶的關鍵點在於不同的用戶擁有不同的訪問權限，但是多個用戶共享同一個的實例。而在多租戶中，多個組織使用的實例各不相同。
多租戶和虛擬化的區別
多租戶和虛擬化在概念是比較類似，都是給每個用戶一個虛擬的實例，並且都支持定製化，但是它們作用的層次不同：虛擬化主要是虛擬出一個操作系統的實例，而多租戶則是主要虛擬出一個應用的實例。
2.2 優缺點
多租戶的優點：
- 經濟：因爲通過一個軟件實例被多個組織共享，從而減低了整體資源的消耗，也同時減低應用運行的成本和相應的管理開支。
- 易於更新和開發：因爲所有組織都共享同一套核心代碼，所以能夠讓軟件更新和開發更簡單。
- 管理方便：首先，通過使用了多租戶架構能減少物理資源和軟件資源，這將簡化管理。其次。由於多租戶軟件主要由有經驗的雲供應商運營，所以能依賴那些非常經驗的管理人員來提升效率。
多租戶的缺點：
- 更復雜：由於一個軟件需要做出極大地修改，才能支持多租戶架構，而且這種修改，往往會增加整個軟件在架構方面的複雜性。
- 不夠安全：因爲衆多組織的應用和數據共享同一套軟件和基礎設施，如果出現機器宕機，軟件出現問題或者大規模的數據被暴露等情況，將會造成更嚴重的後果，因爲影響面更大。
2.3 幾種模型
在現有的實現中，主要有三種常見的模型，而且區別主要在於採用不同的數據庫模式（Database Schema）：
- 私有表（圖1-a）：它是最簡單的擴展模式，就是爲每個租戶的自定義數據創建一個新表。優點是簡單。缺點是涉及到高成本的DDL操作，並且它的整合度不高。
- 擴展表（圖1-b）：總體而言，比較類似於私有表，但是一個擴展表會被多個租戶共享，所以無論是共享表還是基本表都會有租戶欄位。好處是比私有表更高的整合度和更少的DDL操作，但是在架構上比私有表更復雜。
- 通用表（圖1-c）： 主要通過一個通用表來存放所有自定義信息，裏面有租戶欄位和許許多多統一的數據欄位（比如500個）。像這種統一的數據欄位會使用非常靈活的格式讓轉儲各種類型的數據，比如VARCHAR。由於在每一行中的數據欄位都會以一個Key一個Value形式存放所有自定義數據，導致通用表的行都會很寬，而且會出現很多空值，所以通用表這種方式也被稱爲"Sparse Column"。好處是極高的整合度並避免了DDL操作，但是在處理數據方面難度加大。
圖1. 多種模式（圖源自參[7]）
差異與取捨
|
模型 |
機制 |
優點 |
缺點 |
|
私有表 |
爲每個租戶的自定義數據創建一個新表 |
簡單 |
需要DDL操作，低整合度 |
|
擴展表 |
一個擴展表會被多個租戶共享 |
高整合度，少DDL操作 |
有點複雜 |
|
通用表 |
通過一個通用表來存放所有自定義信息 |
極高整合度，無DDL操作 |
實現難度高 |
在實戰中，具體選擇那個模型，主要還是看那個模型更適合。
3 Force.com的多租戶架構
由於Force.com所負載的應用不論是在定製方面的靈活性上，還是所承受的負載上，對基於多租戶的架構而言，都是史無前例的，導致之前提到的一些模型或者改動已經無法滿足要求了，所以Salesforce在Force.com引入了通過Metadata（元數據）驅動的多租戶架構來動態生成快速的，可伸縮的和可定製的應用。接下來，將一步步爲大家揭開Force.com多租戶架構的神祕面紗，首先是它的總體架構。
3.1 總體架構
在介紹Force.com的整個架構之前，請看下圖，此圖是根據Salesforce首席架構師CraigWeissman在2009年舊金山QCon大會上的演講總結而成。
圖1. Force.com的架構圖
首先，在最前面是Gateway（網關），網關將接受所有訪問Force.com的請求，無論它是訪問Sales Cloud，還是關於第三方定製程序的。接下來，網關會根據這個請求所屬的租戶把請求轉發給對應的POD，什麼是POD？簡單的來說，POD就是一組集羣服務器，每個POD都運行同一套Force.com系統，而且每個POD支持成千上萬個租戶，Salesforce總共有10多個POD來支撐它所有服務的運營，並把所有租戶平衡地分配給每個POD，而且主要通過建立新的POD來支撐新的租戶。當POD收到請求之後，POD會先通過其內置的Load Balancer（負載均衡器）來將請求轉發給負載略輕的App Server（應用服務器），由於爲了簡化架構和方便伸縮（Scale），所以應用服務器是Stateless（無狀態），而且在一個POD內會有多個應用服務器以應對大規模的請求。最後，當應用服務器在處理請求的時候，如果發現請求所需的數據沒有被Cache住的話，應用服務器會調用這個租戶所屬的Shared DB（共享數據庫）來取得相關數據，雖然共享數據庫是使用成熟的Oracle數據庫產品，但是在數據庫表的設計上面爲多租戶做了很多地優化。
接下來，將介紹Force.com是如何通過Metadata來動態生成和定製應用的。
3.2 Metadata驅動
首先，Force.com的Metadata是基於大家非常熟悉的面向對象的概念，所以也可以把Metadata認爲是對象，也就是說Force.com是由一個個對象組裝而成，而且Force.com中的對象可以是表格，也可以是UI，甚至可以是用戶權益等。一個Force.com的對象和這個對象下面的字段可以對應一個數據庫的表和這個表的列，而且Force.com對象之間的關係（relationship）在功能上類似於數據庫的引用完整性約束（referential integrity constraint），但與數據庫中每個數據庫表對應於獨立的存儲地址不同的是，Force.com使用幾個共享的大數據庫表來作爲堆存儲（heap storage）來放置所有對象，另外這些存儲Metadata的表也被稱爲"UDD（UniversalData Dictionary）"。
接着，是關於應用的，一個在Force.com上運行的應用實例是通過組合許許多多個對象來生成的，也可以說一個應用實例是使用Metadata來描述的，比如，在應用初始的時候，每個客戶都是使用同一個版本和同樣規模的對象，而且用戶通過添加和更新對象來定製應用，比如增加新的UI和字段等，同時系統會對共享的和定製的對象進行嚴格地分離，使得既能非常方便地更新共享代碼，也能保證某個用戶定製過的部分不影響到其他用戶。在實現上，Force.com並沒有實際地爲一個新對象生成一個數據庫表，而且以元數據的形式存儲在幾張大表中，並在運行時候，Force.com會有一套引擎來通過分析數據庫中的Metadata來動態生成一個虛擬應用實例和這個應用所需的模塊（Virtual Application Componets），比如公共UI（CommonApplication Screen），定製UI（Tenant-Specific Screen）和其他對象等。
圖2. 虛擬應用模塊圖（源自參[1]）
還有，雖然Metadata驅動這種和Java很類似的動態生成機制在速度上有天生缺陷，但是Force.com也內置與Sun的Hotspot技術有異曲同工之妙的MetadataCache來加速常用Metadata的讀取。
下面，將分別介紹Force.com的兩大組成部分：應用服務器和共享數據庫。
3.3 應用服務器
應用服務器主要包括五大核心模塊：
- Metadata Cache：用於存放那些最近用到的和比較常用的Metadata來加速應用的生成。
- 大規模數據處理引擎：主要用來加速處理大量的數據讀寫和在線事務。
- 多租戶感知的查詢優化引擎：這個引擎將通過維護多租戶的信息來幫助Oracle自帶的基於成本的查詢優化器更好地適應多租戶環境。
- 運行時應用生成器：這個生成器主要根據用戶的請求來動態生成應用，並且利用上面提到的查詢優化引擎來提升效率。
- 全文檢索引擎：在數據庫對數據進行更新的同時，這個引擎會異步更新這個數據的相關索引。
3.4 共享數據庫
圖1. Force.com的架構（圖源自參[1]）
整個共享數據庫主要有三種類型的數據庫表：
- Metadata表：主要存放用戶定製的對象和對象所包含的字段的結構信息，也被稱爲"UDD"。
- 數據表：主要存儲那些用戶定製的對象和對象所包含的字段的數據。
- Pivot表：用來維護那些用於檢索（indexing），唯一性和關係等denormalized （去規範化）數據以優化系統的效率。
還有，在物理層面，數據庫裏面所有表格，包括底下的索引，都根據每個租戶不同的租戶ID（OrgID）來使用oracle的Hash分區技術進行分區。通過Hash分區這種久經考驗的技術能夠將大規模的數據平均地分割成多個更小的和更容易管理的分塊，從而幫助大數據庫系統能夠在多租戶的環境下提升速度，伸縮性和可用性等。
3.5 大規模數據處理引擎
由於Force.com需要處理的數據量不論是來自網頁端，還是來自Web Service端都是非常巨大的，所以Salesforce在Force.com中引入了特製的大規模數據處理引擎來處理大量的數據讀寫和在線事務。它主要有兩大特點：其一是對大規模數據處理進行了優化，特別是當一個API調用發來很多待處理的數據時，這個引擎能非常快速地處理。其二是這個引擎內置錯誤恢復機制，當處理大規模數據時候，假如其中一個步驟發生錯誤時，這個引擎會捕捉和修復這個錯誤，並且保持這個步驟之前正確的結果以避免整個重做。
3.6 多租戶感知的查詢優化引擎
大多數現在數據庫都自帶基於成本的查詢優化器，這種優化器主要是基於數據庫表和索引數據等相關數值來進行計算和比較。但是由於傳統的基於成本的優化器都是主要爲單租戶的環境設計的，所以他們並不能很好地適應多租戶的環境，因爲在數據庫中是沒有多租戶這個概念。爲了讓優化器能夠在多租戶環境下良好工作，Salesforce在Oracle自帶優化器的基礎上搭建了一個多租戶感知的查詢優化引擎，它也主要有兩個特點：其一是這個引擎爲每個多租戶對象維護了一整套便於優化的數據（租戶層的，組層的和用戶層的）。其二是這個引擎也維護租戶和租戶下面用戶的安全信息，這樣不僅能提升了效率，因爲能避免將那些不屬於這個租戶的數據加入到計算，而且能提升數據的安全性。
3.7 全文檢索引擎
全文檢索功能對Web應用而言，基本可以算是一種基本功能，而對基於Force.com的應用而言，同樣如此，Force.com爲此內置一個全文檢索引擎，其是基於大名鼎鼎的Lucene技術。當一個運行在Force.com平臺上的應用對數據庫中數據進行更新的時候，會有一組稱爲檢索服務器的後臺進程來異步更新數據相關的索引。通過這種異步機制不僅能夠保證檢索工作不影響處理事務的效率，而且同時也能讓用戶使用到最新的搜索結果。爲了優化這個檢索流程，系統會同步將修改過的數據複製到一個內部"等待檢索"的表，之後檢索服務器會訪問這個表來進行檢索，這樣好處是減少了檢索服務器的I/O處理量。而且爲了更好地適應多租戶環境，檢索引擎自動爲每個租戶維護一個獨立的索引。
3.8 數據庫表的設計
下圖爲Force.com的數據庫表結構：
圖1. 數據庫表的結構（圖源自參[4]）
Metadata表
Metadata表的作用是存儲用戶定製的對象和對象所包含的字段的結構信息，不保存具體的數據，主要有兩大類：
- Object Metadata表：這個表主要存儲對象的信息，其中主要字段包括對象的ID（ObjID），擁有這個對象的租戶的ID（OrgID）和這個對象的名字（ObjName）。
- Field Metadata表：這個表主要存儲對象附帶字段的信息，其中主要字段包括字段的ID（FieldID），擁有這個字段的租戶的ID（OrgID），這個字段的名字（FieldName），這個字段的數據類型（datatype）和一個布爾字段（IsIndexed）來定義這個字段是否需要被檢索。
Data表
Data表的作用和Metadata表正好相反，它主要存儲那些用戶定製的對象和對象所包含的字段的數據，主要也包括兩大類：
- Data表：這個表放置着上面那些對象和字段所對應的數據，核心字段有全局唯一的ID（GUID），租戶ID（OrgID），對象的ID（ObjID）和存放對象名字的"Nature Name（自然名稱）"，比如這行和一個會計對象有關，這行的""Nature Name"字段可能是"Account Name"，除了這些核心字段之外，這個表還有名字從Value0到Value500的501個數據列來存儲數據，而且這些列都是varchar的形式來承載不同類型的數據，這種數據列也被稱爲"flex列"。
- Clob表：這個表主要存放那些CLOB（Character Large Object，字符大對象）數據，對象最大支持到32000個字符。
Pivot表
Pivot表，也稱爲"數據透視表"，在Force.com中是以denormalized （去規範化）格式存儲那些用於特殊目的的數據，比如用於檢索（indexing），唯一性和關係等，主要作用是加速這些特殊數據的讀取以提升系統整體的性能。主要有五種Pivot表：
- Index Pivot表：由於Data表裏面數據都是以"flex列"的形式存儲，所以很難在Data表的基礎上對錶中的數據進行檢索，所以Force.com引入Index Pivot表來解決這個問題，系統在運行的時候會將需要索引的數據從Data表同步到Index Pivot表中相對應的字段來方便檢索，比如這個數據的類型是日期型的，那麼它將會被同步到Index Pivot表中的日期字段。
- UniqueFields Pivot表：這個表是用來幫助系統在Data表中字段實現唯一性。
- Relationships Pivot表：Force.com提供了"Relationship"這個數據類型來定義多個對象之間的關係，而Relationships Pivot表則起到方便和加速"Relationship"數據讀取的作用。
- NameDenorm表：是一個簡單的數據表用於存儲對象的ID（ObjID）和這個對象的實例的名字，主要讓一些僅需獲取名字的查詢調用，從而讓一些簡單的查詢無需查詢規模龐大的Data表。
- FallbackIndex表：這個表將記錄所有對象的名字，來免去成本高昂的"UNION"操作，從而加速查詢。
3.9 APEX
APEX的語言是爲Force.com度身定做的一門語法上類似Java的強類型面嚮對象語言，主要可以通過APEX在Force.com上創建Web Service，編輯複雜的商業邏輯和整合多個Force.com的模塊等。APEX主要以兩種方式執行：其一是以單獨腳本的形式，按照用戶的需要執行。其二是以觸發器的形式，當一個特定的數據處理事件發生的之前或者之後，與這個事件綁定的APEX代碼將會被執行。而且所有APEX代碼將會以Metadata的形式存儲在Metadata表內。當一段APEX代碼被調用的時候，APEX的翻譯器（runtime interpreter）將會從Metadata Cache讀取編譯之後的APEX代碼，而且能夠同時被多個租戶共享以提升效率。
那麼爲什麼要在Force.com引入APEX這門新的語言，而不是像Google App Engine那樣支持已經有一定市場佔有率的語言，比如Java和Pyhon。Salesforce的首席架構師在談到這點時，他提出了一個非常重要的原因，那就是安全，首先，Salesforce會APEX語言度身設計一組管理工具，通過這個工具能夠非常方便地監控APEX腳本的執行，並且能知道這個腳本在執行過程所耗費的CPU時間，內存容量和SQL語句的數量等數據來判斷是否需要中斷這個APEX腳本，以避免影響到屬於其他租戶的應用，如果中斷的話，系統會拋出一個runtime exception給上層的調用者。其次，基於APEX語言的代碼能夠對其內嵌的SOQL（Sforce Object Query Language）和SOSL（Sforce ObjectSearch Language）進行驗證來避免實際運行時出現錯誤。還有，在安全方面除了APEX自帶的功能之外，Salesforce還要求每個上傳到Force.com的APEX腳本，都需要自帶能覆蓋其75%代碼的測試用例，這種做法不僅顯著地提升APEX代碼的質量從而確保平臺整體運行的穩定，而且在Force.com自己更新的時候，能使用這些用例來確保新的更新不會影響現有的基於Force.com的應用。
4 總結
4.1 設計理念
根據 Craig Weissman 的演講和幾份官方的白皮書，在Force.com的設計方面Salesforce團隊主要有下面這五大考量：
- 數據驅動：由於 Salesforce 主要面向企業用戶，導致其上面運行的應用，無論是 CRM ，還是報表工具，都是以數據的CRUD（增刪改查）爲核心，所以 Force.com 需要由數據來驅動，而且也需要爲此做一定程度的優化。
- 規模經濟：由於需要在低價格和靈活付費的基礎上提供可定製化應用，所以需要讓儘可能多用戶共享同一套系統，來大幅減低基礎設施和管理等資源的投入，並實現規模經濟的效益。
- 安全爲先：由於在一套物理設備上將承載數以萬計客戶的企業級應用，那麼如果出現嚴重的程序錯誤或者數據方面遺失或者錯亂，將會發生非常嚴重的後果，所以安全問題是一個 Salesforce絕不能輕視的問題。
- 定製方便：雖然各個企業都會存在一部分比較通用的流程，但是每個企業都可能存在一部分私有或者獨特的流程，所以Force.com需要提供方便的定製功能來幫助用戶將更快捷地將企業的業務遷移到其上。
- 功能豐富：雖然用戶能在 Force.com 上進行開發和定製，但是如果 Force.com 能提供更多的功能模塊或者能讓用戶購買和整合第三方的應用將非常有效地幫助用戶開發應用。
雖然這些設計理念說起來很容易，但是實現起來是非常艱難的。可貴地是，Salesforce 團隊在開發 Force.com 的過程中基本實現了這些設計理念。
4.2 總結
關於本系列的總結，也主要包括五個方面：
· Trade-Off 是難免的：爲了滿足設計目標，有時不得不做Trade-Off 。由於 Salesforce 所需要承載的多租戶應用的規模之大，定製化需求之高都是前所未見的，所以Salesforce並沒有採用在第二篇所提到幾種常見模型，而是從長計議，採用了更靈活但技術要求更高的 Metadata 方式。還有爲了避免在數據庫中執行成本非常高並會 Locking 整個數據庫的 DDL（數據庫定義語句）操作，所以在 Force.com 運行的時候是無法創建和修改數據庫表，而這樣將會提升實現的難度。
· 優化很重要，雖然 Force.com 的多租戶架構就像 Java 一樣，採用了很多動態生成的機制。很顯然，如果像早期的Java那樣缺乏優化的話，那麼Force.com 整體的性能將會非常糟糕，從而無法實現其設計要求。但幸運的是，Salesforce 團隊不僅做了優化，而且憑藉着其很多核心成員來自於 Oracle的背景，在數據庫端做了很多高水平的優化，比如添加了很多貌似累贅的 Pivot 表來加快部分常用數據的讀取。
· 人才很重要：經過本系列的介紹，可以看出 Force.com 的整個架構並不全是在現有的框架和庫的基礎上構建的，而是爲了設計目標開發了很多比較底層和比較複雜的模塊，而且這些模塊是隻有那些頂級的程序員才能編寫出來的，所以說如果沒有硅谷那個龐大的優秀程序員池，Salesforce 就很難走到今天。
· 軟件是一個進化的工程：剛開始的時候 Salesforce 架構是普普通通的 B/S 架構，但是隨着用戶不斷地提出定製化的要求，Salesforce 也不得不在架構中引入多租戶的概念，之後，由於用戶需要更靈活的，可伸縮的和功能更強大的平臺，導致 Salesforce 不斷地對其架構進行重構，到最後，終於整出了Force.com 這一優秀的 PaaS 平臺。
· 有用的創新才珍貴：Salesforce 不僅在 Force.com 引入很多創新，而且都非常有效。在這些創新當中，最有用的除了 Metadata 驅動這種多租戶架構實現機制之外，還有一個名爲"回收站（Recycle Bin）"的概念，這個回收站主要存儲30天來那些從數據表裏面刪除的數據，如果用戶在30天內發現數據是誤刪，可以對數據進行恢復，這樣既減低數據誤刪的可能性，而且能回收部分物理資源，比如硬盤空間等。