0.1秒的目標(biāo)

在為即將到來(lái)的SQL Studio Web應(yīng)用程序開(kāi)發(fā)后端服務(wù)期間，我們希望在用戶(hù)鍵入代碼時(shí)向用戶(hù)提供快速的自動(dòng)完成幫助。我們將“快速”目標(biāo)設(shè)定為100毫秒左右。

自動(dòng)完成功能需要了解任何數(shù)據(jù)庫(kù)的元數(shù)據(jù)（有關(guān)數(shù)據(jù)的數(shù)據(jù)）。

無(wú)狀態(tài)容器

后端使用以C＃編寫(xiě)并托管在當(dāng)前在Amazon Web Services上運(yùn)行的Docker容器中的.Net Core代碼。容器實(shí)例可以來(lái)去去，并且每個(gè)容器可以為許多用戶(hù)提供服務(wù)。將內(nèi)容保存在容器的內(nèi)存中不是很可擴(kuò)展。負(fù)載均衡器可以路由每個(gè)用戶(hù)請(qǐng)求以命中不同的容器。

提取元數(shù)據(jù)是對(duì)數(shù)據(jù)庫(kù)的一系列昂貴操作，因此我們需要解決為任何類(lèi)型的數(shù)據(jù)庫(kù)緩存元數(shù)據(jù)的問(wèn)題。決定使用Redis緩存服務(wù)器，在該服務(wù)器中我們將使用數(shù)據(jù)庫(kù)的二進(jìn)制表示形式。

省力的方法

有效保存和重新加載緩存的元數(shù)據(jù)的問(wèn)題歸結(jié)為包含所述元數(shù)據(jù)的對(duì)象列表的序列化和反序列化。

在第一個(gè)實(shí)現(xiàn)中，我們只需要工作即可，因此我們使用了基本方法-使用BinaryFormatter將對(duì)象保存到字節(jié)數(shù)組。它使用方法Serialize和Deserialize很好且簡(jiǎn)單。給它一個(gè)對(duì)象，它將使用反射和魔術(shù)吐出描述該對(duì)象的字節(jié)數(shù)組。太好了-非常適合包含10個(gè)表，視圖和其他對(duì)象的示例數(shù)據(jù)庫(kù)。

但是真實(shí)的數(shù)據(jù)庫(kù)遠(yuǎn)不及10個(gè)表或過(guò)程。更像是數(shù)以千計(jì)的對(duì)象。最重要的是過(guò)程的反序列化部分，對(duì)于一個(gè)如此大的數(shù)據(jù)庫(kù)，該過(guò)程花費(fèi)了大約400毫秒。結(jié)合其他必需的步驟，例如用戶(hù)鍵入的腳本文檔的解析和靜態(tài)分析，這是完全不可接受的。

走向“更接近金屬”

C＃有許多處理序列化的庫(kù)，它們提供各種類(lèi)型的附加值和功能。但是我們決定使用自己的BinaryReader和BinaryWriter類(lèi)。這些類(lèi)提供基本.Net類(lèi)型的序列化，而這就是我們所需要的。降低它會(huì)更困難，因?yàn)槲覀儽仨氃冢▋?nèi)存）流中逐步移動(dòng)要保存的數(shù)據(jù)的大小。

這樣，我們就無(wú)需對(duì)序列化消息進(jìn)行版本控制或任何形式的格式描述-但這還是不必要的。每個(gè)需要序列化的類(lèi)都必須具有自己的實(shí)現(xiàn)，即從字節(jié)數(shù)組中讀取時(shí)如何創(chuàng)建該類(lèi)或如何將其自身轉(zhuǎn)換為此類(lèi)字節(jié)數(shù)組。

使用該技術(shù)的總效果是，對(duì)于上述實(shí)際數(shù)據(jù)庫(kù)而言，反序列化大約需要20毫秒-僅是原始基本方法的5％?，F(xiàn)在，我們有更多的空間可以在設(shè)定的性能目標(biāo)內(nèi)為自動(dòng)完成功能執(zhí)行其他更有趣的操作。