數(shù)字化轉(zhuǎn)型正在導(dǎo)致很多企業(yè)面臨前所未有的海量數(shù)據(jù)。許多人認(rèn)為，面對不斷增長的數(shù)據(jù)量和更復(fù)雜的分析要求，從Microsoft Azure或AWS云平臺(tái)運(yùn)行SQL Server數(shù)據(jù)庫是確保IT性能的最佳方法。但是，對于某些人而言，最初的希望是通過切換到云平臺(tái)能夠以更高的成本效益進(jìn)行工作。一個(gè)重要的原因可能是尚未針對新的云計(jì)算環(huán)境預(yù)先優(yōu)化數(shù)據(jù)資產(chǎn)。因此，只有在充分準(zhǔn)備之后才能完成遷移。
遷移到云端就像搬入新家：當(dāng)在家中查看所有物品時(shí)，很可能出現(xiàn)自己都不知道擁有的東西。不可避免地出現(xiàn)的問題是：家中的每一件物品都與新房子相關(guān)嗎?或者是時(shí)候徹底清理一下雜物了?
這種方法也可以應(yīng)用于將SQL Server數(shù)據(jù)庫遷移到云平臺(tái)中。由于云計(jì)算環(huán)境的規(guī)則與內(nèi)部部署環(huán)境不同，因此在順利進(jìn)行遷移之前，應(yīng)先對數(shù)據(jù)庫進(jìn)行適當(dāng)?shù)那謇砉ぷ?。為此，?shù)據(jù)庫管理員(DBA)首先必須獲得所有數(shù)據(jù)庫如何與連接的應(yīng)用程序進(jìn)行交互的概述。這使他們可以清除數(shù)據(jù)集中不必要的混亂數(shù)據(jù)，并在必要時(shí)修改代碼。因此在遷移之前，應(yīng)先進(jìn)行包含評估和審查階段的兩步過程。
評估階段：遷移的數(shù)據(jù)選擇
云遷移失敗的最常見原因之一是成本過高。在許多情況下，這可以歸因于以下事實(shí)：尚未充分考慮新的云計(jì)算收費(fèi)模式。未使用的數(shù)據(jù)量(在內(nèi)部部署運(yùn)營中可忽略不計(jì))會(huì)給云平臺(tái)中的預(yù)算帶來極大壓力，因?yàn)樵朴?jì)算服務(wù)的價(jià)格由CPU、存儲(chǔ)和IOPs決定。與其相反，提前完成全面評估有助于確保盡可能高效地使用新環(huán)境。為此，需要確定所有庫存數(shù)據(jù)記錄，并將它們依次分配到三個(gè)類別：清理、存檔、遷移。
清理
大量不再有用的垃圾數(shù)據(jù)或數(shù)據(jù)集適合在云遷移之前進(jìn)行清理。這種類別的數(shù)據(jù)包括過去創(chuàng)建的數(shù)據(jù)，但數(shù)據(jù)質(zhì)量可能很差，只是出于法律原因才需要進(jìn)行存儲(chǔ)。如果超過法律要求的時(shí)限，則可以將其刪除。如果是個(gè)人數(shù)據(jù)，則還應(yīng)根據(jù)GDPR法規(guī)和其他數(shù)據(jù)保護(hù)法規(guī)來考慮數(shù)據(jù)庫存。
存檔
在調(diào)查過程中，數(shù)據(jù)庫可能還會(huì)遇到相反的情況：某些數(shù)據(jù)集雖然過時(shí)了，但其質(zhì)量適合當(dāng)前和未來的趨勢分析。在此建議繼續(xù)以只讀模式使用數(shù)據(jù)。例如，如果計(jì)劃遷移到Microsoft Azure，則可以使用SQL Stretch數(shù)據(jù)庫將數(shù)據(jù)簡單地移動(dòng)到成本相對較低的存儲(chǔ)級(jí)別。在那里，數(shù)據(jù)仍然以只讀模式可用，并且可以根據(jù)需要進(jìn)行檢索，以用于商業(yè)智能操作，用于人工智能或機(jī)器學(xué)習(xí)功能的應(yīng)用以及用于創(chuàng)建預(yù)測分析。
遷移
確定了需要清除和存檔的數(shù)據(jù)后，便自動(dòng)形成了適合遷移的數(shù)據(jù)量。盡管這些數(shù)據(jù)來自內(nèi)部部署生產(chǎn)系統(tǒng)，但這并不意味著可以將其直接傳輸?shù)交谠朴?jì)算的生產(chǎn)系統(tǒng)。為了防止用戶可能抱怨他們的報(bào)告自從遷移以來不再有意義，下一步是對這些數(shù)據(jù)進(jìn)行徹底的質(zhì)量檢查。
檢查階段：數(shù)據(jù)庫質(zhì)量檢查
由于在遷移過程中不應(yīng)對應(yīng)用程序和數(shù)據(jù)庫進(jìn)行任何更改，因此必須消除任何妨礙可靠性能的功能。必須進(jìn)行額外的質(zhì)量檢查，以確保應(yīng)用程序和數(shù)據(jù)庫級(jí)別之間的平滑交互。因此，應(yīng)該確保以下幾點(diǎn)：
•諸如表格、視圖、觸發(fā)器、存儲(chǔ)過程和用戶??定義的函數(shù)(UDF)之類的對象的一致命名標(biāo)準(zhǔn)。
•如果所包含的值均不超過32個(gè)字符，則不要使用超大的列，例如CHAR(500)。
•GUID(全局唯一標(biāo)識(shí)符)不用作聚集索引。這僅適用于未擴(kuò)展的小型表格。還必須檢查是否將GUID用作集群主鍵，因?yàn)檫@會(huì)導(dǎo)致許多性能問題。
•沒有定義為最大大小的數(shù)據(jù)類型，例如NVARCHAR(MAX)。
•沒有隱式轉(zhuǎn)換，因?yàn)樗鼈儠?huì)導(dǎo)致嚴(yán)重的代碼問題。特別是，當(dāng)使用對象關(guān)系映射(ORM)工具時(shí)，更容易發(fā)生轉(zhuǎn)換問題，因?yàn)閷ο箨P(guān)系映射(ORM)通常默認(rèn)情況下使用GUID作為集群索引。
此外，應(yīng)再次檢查查詢超時(shí)的編碼。如果某些查詢在內(nèi)部部署環(huán)境中已經(jīng)發(fā)生服務(wù)器超時(shí)，則這些超時(shí)將在云中增加。為避免這種情況，應(yīng)修改代碼，以便與查詢超時(shí)相比，它在云平臺(tái)中更具彈性，并且相應(yīng)地優(yōu)化了關(guān)聯(lián)的查詢。
另一個(gè)必要但在某些情況下可能很痛苦的任務(wù)是對流行功能的評估和測試，例如創(chuàng)建臨時(shí)表。盡管通常使用這些功能來改進(jìn)編碼的邏輯，但是只有少數(shù)幾個(gè)功能會(huì)對性能產(chǎn)生積極的影響。為了避免在云平臺(tái)中出現(xiàn)任何意外情況，最好安排對最常用的數(shù)據(jù)庫功能進(jìn)行測試。
可靠的文檔有助于切換到云平臺(tái)
總體而言，進(jìn)入云平臺(tái)只需要根據(jù)數(shù)據(jù)目錄創(chuàng)建全面的文檔即可。為了避免在遷移后發(fā)現(xiàn)應(yīng)用程序和用戶已經(jīng)遷移進(jìn)來，必須進(jìn)行下一個(gè)步驟：記錄哪些應(yīng)用程序訪問目錄中記錄的數(shù)據(jù)。
對于數(shù)據(jù)庫來說，這似乎有些不愉快，就像搬家時(shí)必須處理長期遺忘的物品一樣。為了簡化文檔編制過程，需要使用適當(dāng)?shù)墓芾砉ぞ?，這些工具可以自動(dòng)創(chuàng)建數(shù)據(jù)源的詳細(xì)概述。通過這種方式，可以創(chuàng)建合適的條件以實(shí)現(xiàn)平穩(wěn)遷移并有效使用云計(jì)算服務(wù)。
版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。
京公網(wǎng)安備 11010502049343號(hào)