你(nǐ)應該使用(yòng)哪個雲數據庫？

雲計(jì)算(suàn)的基本原則是采用(yòng)一次性和(hé)可更換的多台機器，這(zhè)對(duì)采用(yòng)雲計(jì)算(suàn)技術以及在雲中實施的數據庫系統的功能(néng)有直接影響。 傳統數據庫大(dà)緻可以分爲并行優先(例如MongoDB或Teradata)或單存儲系統優先(例如PostgreSQL或MySQL)。這(zhè)兩個類别都有其核心設計(jì)固有的局限性。這(zhè)些(xiē)限制的程度部分是成熟度的函數。但(dàn)是，對(duì)于某些(xiē)核心架構決策來(lái)說，可能(néng)無法有效支持特定功能(néng)。 例如，Greenplum有序列，但(dàn)Redshift沒有，盡管這(zhè)兩者都是PostgreSQL的衍生物。而BigQuery沒有序列，但(dàn)Teradata有序列，盡管在傳統意義上(shàng)它們并不是真正的序列。 雲數據庫屬于相同的類别，而新系統明(míng)顯傾向于并行優先。雲計(jì)算(suàn)系統的基本屬性是機器的可擴展性和(hé)可替換性的并行性。 在單系統優先類别中，雲計(jì)算(suàn)實例化往往側重于傳統單機産品的管理(lǐ)成本、升級和(hé)可靠性(RPO/RTO)，例如Heroku PostgreSQL、Amazon Aurora(PostgreSQL/MySQL)、Google cloud SQL(PostgreSQL/MySQL)和(hé)Azure SQL(SQL Server)。 在并行優先類别中，實際上(shàng)有兩個子類别：SQL/關系類别(BigQuery、Snowflake、Redshift、Spark、AzureSynapse)和(hé)DHT/NoSQL(BigTable、Dynamo、Cassandra、Redis)類别。這(zhè)種區(qū)别與是否存在類似SQL的語言關系不大(dà)，而與系統中數據的物理(lǐ)布局是否經過調整以便通過散列快(kuài)速查找鍵進行單行訪問，或者使用(yòng)排序合并和(hé)篩選操作(zuò)進行批量訪問有關。 并行優先關系數據庫通常依賴于一個或多個原生雲存儲系統。這(zhè)些(xiē)存儲系統總是并行優先構建，并公開(kāi)一個非常有限的get-object/put-object API，它通常允許對(duì)數據進行分區(qū)，但(dàn)不允許高(gāo)性能(néng)随機訪問。這(zhè)限制了(le)數據庫實現(xiàn)高(gāo)級持久數據結構(例如索引)，在許多情況下(xià)，還限制了(le)可變數據的能(néng)力。 因此，使用(yòng)原生存儲的雲計(jì)算(suàn)實現(xiàn)往往依賴于微分區(qū)的順序讀寫而不是索引。根據對(duì)象名稱，存儲級對(duì)象往往隻有一條物理(lǐ)訪問路徑。索引必須在底層存儲的外(wài)部實現(xiàn)，即使這(zhè)樣做了(le)，底層雲存儲API也(yě)可能(néng)使在存儲級别對(duì)象中實際使用(yòng)地址或字節偏移量變得困難。 雲計(jì)算(suàn)的優點 (1) 雲平台是爲用(yòng)戶管理(lǐ)的基礎設施。 在雲中，部署、可靠性和(hé)管理(lǐ)是用(yòng)戶關注的問題。從(cóng)電源、軟件安裝和(hé)硬件到(dào)操作(zuò)系統管理(lǐ)和(hé)安全(從(cóng)加固到(dào)入侵檢測)的堆棧的所有層都由雲計(jì)算(suàn)供應商管理(lǐ)。 雲計(jì)算(suàn)供應商免費試用(yòng)産品的便利性可以幫助用(yòng)戶啓動并運行初始實驗，然後在需要時(shí)擴展到(dào)大(dà)規模，這(zhè)在傳統的内部部署系統中是困難的。 另一個好(hǎo)處是雲計(jì)算(suàn)供應商提供了(le)許多标準化流程來(lái)與第三方SaaS産品集成。其結果是雲計(jì)算(suàn)供應商讓基礎設施成爲别人的問題，因此用(yòng)戶可以專注于其核心業務。 (2) 效率。 雲計(jì)算(suàn)可以最大(dà)化資源利用(yòng)率。與非雲系統相比，雲計(jì)算(suàn)系統向數據庫應用(yòng)程序公開(kāi)資源利用(yòng)控制要常見得多。雲計(jì)算(suàn)技術可以平滑負載，将其移動到(dào)低(dī)需求的時(shí)間段，并且可以優先考慮交互式和(hé)關鍵業務作(zuò)業。 當然，雲計(jì)算(suàn)供應商可以利用(yòng)大(dà)規模采購的效率、負載共享和(hé)極高(gāo)的利用(yòng)率。僅這(zhè)些(xiē)規模參數就可以成爲遷移到(dào)雲平台的理(lǐ)由。更不用(yòng)說使用(yòng)供應商的專業知(zhī)識進行強化和(hé)入侵檢測的好(hǎo)處了(le)。 與規模密切相關的是雲計(jì)算(suàn)供應商能(néng)夠以低(dī)廉的價格提供被動存儲，這(zhè)使得無論是出于實驗或分析原因，還是出于備份或審計(jì)，更容易保留更長的曆史數據窗口，并且更加經濟高(gāo)效地實施時(shí)間旅行等功能(néng)，可以從(cóng)曆史角度檢查數據。 當然，繁重的數據處理(lǐ)負載可以通過使用(yòng)雲計(jì)算(suàn)供應商的規模臨時(shí)向外(wài)擴展來(lái)解決，當然用(yòng)戶會(huì)爲此付出代價。 (3) 經濟性。 除了(le)規模和(hé)效率的經濟性之外(wài)，雲計(jì)算(suàn)供應商的會(huì)計(jì)機制傾向于将存儲和(hé)處理(lǐ)的成本數據暴露到(dào)單個查詢級别。這(zhè)允許用(yòng)戶對(duì)任何給定分析的成本收益做出合理(lǐ)的商業決策，并相應地做出優化決策。事(shì)實上(shàng)，有時(shí)用(yòng)戶可能(néng)會(huì)決定通過擴展雲計(jì)算(suàn)規模來(lái)擴大(dà)和(hé)簡化分析的結構，而不是花(huā)費時(shí)間和(hé)精力來(lái)塑造一個“穩健的分析”，這(zhè)可能(néng)更便宜、更準确。 雲計(jì)算(suàn)的弱點 (1) 雲平台是爲用(yòng)戶管理(lǐ)的基礎設施。 雲計(jì)算(suàn)具有一組與大(dà)型機截然不同的故障域。雲平台上(shàng)的分布式計(jì)算(suàn)是共享的基礎設施(計(jì)算(suàn)、存儲、網絡)，這(zhè)可能(néng)會(huì)受到(dào)更多的幹擾，其中任何一個故障都可能(néng)導緻交互性失敗或暫時(shí)性工(gōng)作(zuò)失敗。在極少數情況下(xià)，即使是雲計(jì)算(suàn)供應商的自(zì)動化管理(lǐ)也(yě)會(huì)通過更改系統的屬性或行爲對(duì)客戶體驗産生負面影響。 (2) 效率。 與傳統的内部部署系統相比，大(dà)多數雲計(jì)算(suàn)數據庫仍然不成熟。雲數據庫缺乏更成熟産品的特性。有些(xiē)功能(néng)可能(néng)永遠不會(huì)被引入，因爲完全分布式、易發生故障的平台的概念使它們不切實際。 許多基于雲的并行關系系統對(duì)于特定的數據庫變異(INSERT、UPDATE、DELETE)操作(zuò)的效率顯著降低(dī)，這(zhè)在某些(xiē)用(yòng)例中可能(néng)會(huì)導緻問題。 當然，雲計(jì)算(suàn)與内部部署系統或托管在其他(tā)雲平台中的系統之間的額外(wài)延遲往往會(huì)迫使雲計(jì)算(suàn)基礎設施整合。用(yòng)戶往往被迫首先選擇地理(lǐ)位置和(hé)雲計(jì)算(suàn)供應商，然後實際上(shàng)僅限于其雲計(jì)算(suàn)供應商提供的服務。 (3) 經濟性。 雲計(jì)算(suàn)的成本遵循與内部部署截然不同的曲線：擴展容量非常容易。控制成本變得更加困難。另一方面，如果成本有上(shàng)限的話(huà)，則在達到(dào)成本上(shàng)限後提交的交互式作(zuò)業可能(néng)會(huì)被拒絕。這(zhè)增加了(le)一層複雜(zá)性，傳統數據庫管理(lǐ)員需要學習這(zhè)些(xiē)知(zhī)識才能(néng)創建成功的部署。 當然，被雲計(jì)算(suàn)供應商鎖定對(duì)于企業來(lái)說很(hěn)普遍。雲平台之間的遷移并不比内部部署系統之間的遷移容易。 用(yòng)戶有如此多的産品可供選擇，但(dàn)并沒有一種産品具有所有功能(néng)。最重要的第一步是确定所有必需工(gōng)作(zuò)流的基本屬性或行爲，并确保所選的雲計(jì)算(suàn)供應商有能(néng)力提供這(zhè)些(xiē)服務，而每個行爲可能(néng)來(lái)自(zì)不同但(dàn)至少弱集成的産品。因此不要期望像Oracle公司或Teradata公司提供的産品提供“一切”服務。 作(zuò)者：陶然? 來(lái)源：IT168網站(zhàn)