從SOL到NoSQL,資料庫還要向何處演進?
在開發一個應用程式時,不可避免要選擇使用SQL還是NoSQL資料庫來儲存資料。傳統的資料庫,即使用SQL(結構化查詢語言)進行查詢的關係型資料庫,是經過幾十年來技術發展、良好實踐和現實世界壓力測試的產物。它們是為可靠的事務和臨時查詢而設計的,是業務線應用的主力軍。但它們也有一些限制,如嚴格的模式,使它們不太適合於其他型別的應用。
NoSQL資料庫是針對這些限制而產生的。NoSQL系統儲存和管理資料的方式,允許高操作速度,並讓開發人員有巨大靈活性。許多資料庫是由谷歌、亞馬遜、雅虎和Facebook等公司開發的,它們尋求更好的方式來儲存內容或處理大型網站的資料。與SQL資料庫不同,許多NoSQL資料庫可以在數百或數千臺伺服器上進行橫向擴充套件。
不過,NoSQL的優勢並不是沒有代價的。NoSQL系統傾向於速度和可擴充套件性,而不是SQL資料庫所承諾的可靠事務背後的ACID屬性。與圍繞SQL建立的數十年的機構知識相比,在NoSQL系統中用於處理資料的隱喻也是相對較新的。
SQL和NoSQL資料庫提供了不同的權衡。雖然它們在特定專案的背景下可能會有競爭,例如,為不同應用會面臨二選一的情況,但它們在更大範圍內是互補的,每一種都適合於不同的使用情況。是選擇SQL還是NoSQL並不是絕對的,要根據場景需求選合適的。
NoSQL與SQL
SQL和NoSQL之間的根本區別並不那麼複雜。對於如何儲存和檢索資料,兩者都有不同的理念。
對於SQL資料庫,所有資料都有一個固有的結構。像Microsoft SQL Server、MySQL、PostgreSQL或Oracle資料庫這樣的傳統資料庫使用一個模式--對插入資料庫的資料如何組成的正式定義。例如,一個表中的某一列可能被限制為只能是整數。因此,記錄在該列中的資料將有很高的規範化程度。SQL資料庫的嚴格模式也使得對資料進行聚合變得相對容易,例如,使用SQL JOIN命令將兩個表的資料合併。
在NoSQL中,資料可以以無模式或自由的方式儲存。任何資料都可以儲存在任何記錄中。在NoSQL資料庫中,你會發現四種常見的資料儲存模式,這導致了四種常見的NoSQL系統型別。
-
文件資料庫(如MongoDB)。插入的資料以無模式的JSON結構或“文件”的形式儲存,其中的資料可以是任何東西,從整數到字串再到自由格式的文字。沒有必要指定JSON文件將包含哪些欄位(如果有的話)。
-
鍵值儲存(如Redis)。自由格式的值,從簡單的整數或字串到複雜的JSON文件,都可以通過鍵(比如字串)在資料庫中訪問。
-
寬列儲存(如 Cassandra)。資料被儲存在列中,而不是像傳統SQL系統儲存在行。任何數量的列(以及許多不同型別的資料)都可以根據查詢或資料檢視的需要進行分組或聚合。
-
圖資料庫(如Neo4j)。資料被表示為實體及其關係的網路或圖形,其中圖中的每個節點是一個自由形式的資料塊。
無模式的資料儲存在以下情況下是有用的。
-
你想快速訪問資料,你更關心訪問的速度和簡單性,而不是可靠的事務或一致性。
-
你正在儲存大量的資料,你不想把自己鎖定在一個模式中,因為以後改變模式可能是緩慢和痛苦的。
-
你正在從一個或多個來源接收非結構化資料,你想保持資料的原始格式以獲得最大的靈活性。
-
你想把資料儲存在一個分層結構中,但你希望這些分層結構由資料本身來描述,而不是外部模式。NoSQL允許資料隨意地自我引用,該方式對於SQL資料庫來說更為複雜,難以模仿。
查詢NoSQL資料庫
關係型資料庫使用的結構化查詢語言提供了一種統一的方式,在儲存和檢索資料時與伺服器通訊。SQL語法是高度標準化的,所以儘管各個資料庫可能會以不同的方式處理某些操作(例如,視窗函式),但基本原理仍然是相同的。
相比之下,每個NoSQL資料庫往往都有自己的語法來查詢和管理資料。例如,CouchDB使用JSON形式的請求,通過HTTP傳送,以建立或檢索其資料庫中的文件。MongoDB通過二進位制協議,以命令列介面或語言庫的方式傳送JSON物件。
一些NoSQL產品可以使用類似SQL的語法來處理資料,但只是在有限的範圍內。例如,Apache Cassandra,一個廣泛的列儲存,有自己的類似SQL的語言,Cassandra查詢語言(CQL)。CQL的一些語法是直接來自於SQL的手冊,比如SELECT或INSERT關鍵字。但在Cassandra中沒有執行JOIN或子查詢的本地方法,因此相關的關鍵字在CQL中並不存在。
無共享shared-nothing架構
NoSQL系統常見的一個設計選擇是“shared-nothing”架構。在一個無共享的設計中,叢集中的每個伺服器節點都獨立於其他節點執行。系統不需要從其他節點獲得共識來返回資料給客戶端。查詢速度很快,因為它們可以從最近的或最方便的節點返回。
無共享系統的另一個優點是彈性和向外擴充套件。向外擴充套件叢集非常容易,只需旋轉叢集中的新節點並等待它們與其他節點同步即可。如果一個NoSQL節點當機,叢集中的其他伺服器將繼續執行。即使服務請求的節點減少,所有資料仍然可用。
請注意,無共享的設計並不是NoSQL資料庫所獨有的。許多傳統的SQL系統可以以無共享的方式設定,如MySQL,儘管這通常涉及到犧牲整個叢集的一致性以獲得效能。
NoSQL的侷限性
如果NoSQL提供瞭如此多的自由和靈活性,為什麼不完全放棄SQL?答案很簡單,許多應用仍然需要SQL資料庫所提供的各種約束、一致性和保障措施。在這些情況下,NoSQL的一些“優勢”可能會變成劣勢。其他的限制來自於NoSQL系統缺乏某些在SQL領域中本應有的功能。
-
無模式(No schema)
即使你接收的是自由格式的資料,你也幾乎總是需要對資料施加約束,以使其有用。對於NoSQL,施加約束涉及到將責任從資料庫轉移到應用開發者身上。例如,開發者可以通過一個物件關係對映系統(或稱ORM)強加結構。但如果你想讓模式與資料本身共存,NoSQL通常不支援這種做法。
一些NoSQL解決方案為資料提供了可選的資料型別和驗證機制。例如,Apache Cassandra有一系列的本地資料型別,讓人想起傳統SQL中的那些資料型別。
-
最終一致性
NoSQL系統提供了強一致性或即時一致性的選擇,以獲得更好的可用性和效能。傳統的資料庫確保操作是原子的(事務的所有部分都成功,或者沒有一個成功)、一致的(所有使用者都有相同的資料檢視)、隔離的(事務不競爭)和持久的(一旦完成,它們將不受伺服器故障的影響)。
這四個屬性,統稱為ACID,在NoSQL系統中可以用不同的方式處理。你可以選擇最終一致性,而不是要求整個叢集的強一致性,這必然會延遲對請求的響應,允許服務請求,而無需等待最新的寫入複製到叢集的其它節點。插入叢集的資料最終在各處都是可用的,但不能保證任何時候可用。
對於一些NoSQL系統,你可以在一致性和速度之間選擇一個折中方案,不同的產品有不同的方案。例如,微軟的Azure Cosmos DB可以讓你選擇每個請求的一致性級別,所以你可以選擇適合你的。事務語義,在SQL系統中保證事務中的所有步驟(例如執行銷售和減少庫存)要麼完成,要麼回滾,在一些NoSQL系統中也有,例如MongoDB。
-
NoSQL的鎖定
大多數NoSQL系統在概念上是相似的,但實現方式不同。每個系統都有自己的隱喻和機制,用於資料的查詢和管理。
這樣做的一個副作用是應用邏輯和資料庫之間可能存在高度的耦合。如果你選擇一個NoSQL系統並堅持使用它,這種耦合性並沒有什麼壞處,但如果你在未來更換系統,它就會成為一個絆腳石。
如果你從MongoDB遷移到CouchDB(或者相反),你需要做的不僅僅是遷移資料。還必須駕馭資料訪問和程式設計隱喻之間的差異。換句話說,你必須重寫應用程式中訪問資料庫的部分。
-
NoSQL技能
NoSQL的另一個缺點是相對缺乏專業知識。傳統SQL人才的市場相當大,而NoSQL技能的市場卻剛剛起步。
作為參考,Indeed.com報告稱,截至2022年,傳統SQL資料庫(MySQL、微軟SQL Server、Oracle資料庫等)的職位數量仍然高於MongoDB、Couchbase和Cassandra的職位數量。對NoSQL專業知識的需求仍然只是SQL技能市場的一小部分。
合併SQL和NoSQL
未來,隨著時間的推移,SQL和NoSQL系統之間的一些差異會消失。現在已經有許多SQL資料庫接受JSON文件作為原生資料型別,並可以對該資料進行查詢。一些資料庫甚至有對JSON資料施加約束的本地方法,因此其處理方式與傳統的行和列資料一樣嚴格。
另一方面,NoSQL資料庫不僅增加了類似SQL的查詢語言,還增加了傳統SQL資料庫的其他功能,比如MongoDB的ACID屬性。
一個可能的路徑是,未來幾代資料庫以及當前資料庫系統的未來版本將跨越這些正規化,同時提供SQL和NoSQL功能,有助於使資料庫世界不再支離破碎。例如,微軟的Azure Cosmos DB在底層使用了一套基元,可以互換地再現兩種系統的行為。谷歌雲Spanner將SQL的強一致性與NoSQL系統的水平可擴充套件性相結合。
不過,純SQL和純NoSQL系統仍將在未來很多年佔有一席之地。在設計靈活性、水平擴充套件性和高可用性比強讀一致性和其他SQL資料庫常見的保障措施更重要的情況下,可以考慮使用NoSQL。對於許多應用來說,這些保障措施很可能值得用來交換NoSQL所提供的東西。
對於許多應用程式來說,以NoSQL的特有優勢來那些換保障措施是值得。
作者:Serdar Yegulalp
來自 “ https://www.infoworld.com/article/3240644/what-is- ”,原文連結:http://blog.itpub.net/69925873/viewspace-2902952/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分享 | 滴滴分散式NoSQL資料庫Fusion的演進之路分散式SQL資料庫
- NoSQL資料庫概念與NoSQL資料庫家族SQL資料庫
- NoSql資料庫SQL資料庫
- [Redis 系列]redis 學習一,資料庫的演進及 Nosql 的初步認知Redis資料庫SQL
- 資料湖從前世到今身的演進與選型探索
- 四類NoSQL資料庫SQL資料庫
- NoSQL資料庫興起SQL資料庫
- 從Opentracing、OpenCensus 到 OpenTelemetry,看可觀測資料標準演進史
- 雲原生時代,資料庫該何去何從?資料庫
- 如何將資料從Hadoop匯出到關係型和NoSQL資料庫?HadoopSQL資料庫
- 從 ClickHouse 到 Apache Doris,騰訊音樂內容庫資料平臺架構演進實踐Apache架構
- MySQL資料庫架構——高可用演進MySql資料庫架構
- 生產環境故障處理演練-mysql資料庫主從恢復MySql資料庫
- 從GrowingIO產品到平臺的進化看資料分析的演變
- 從MVC到DDD的架構演進MVC架構
- 從32位資料庫還原到64bit資料庫open的時候報錯資料庫
- 智慧客服的演變:從傳統到向量資料庫的新時代資料庫
- 四大類NOSQL資料庫SQL資料庫
- SnappyDB—Android上的NoSQL資料庫APPAndroidSQL資料庫
- redis(1)NoSQL資料庫簡介RedisSQL資料庫
- Caffe作者賈揚清:AI,從大資料演進到高效能運算AI大資料
- OceanBase 首席架構師:關聯式資料庫到三代分散式資料庫,我親歷的資料庫演進史架構資料庫分散式
- 『從火爆到冷清,小龍蝦何去何從?』今日資料行業日報(2019.07.31)行業
- 從上世紀80年代到今天,達夢資料庫技術架構演進與應用全記錄資料庫架構
- 人臉識別技術演進:從幾何演算法到深度學習的深度剖析演算法深度學習
- java 從EXCEL匯入到資料庫JavaExcel資料庫
- 如何將Azure SQL 資料庫還原到本地資料庫例項中SQL資料庫
- 雲原生時代資料庫運維體系演進資料庫運維
- 如何選擇合適的NoSQL資料庫SQL資料庫
- Nosql 資料庫 MemCache、Redis、MongoDB 的區別SQL資料庫RedisMongoDB
- GSA報告:從LTE到5G的演進
- 從誕生到成長!數家名企大資料平臺應用演進之路解析!大資料
- 狂奔一年後的向量資料庫,何去何從?|對話 MyScaleDB資料庫
- Python 資料處理庫 pandas 進階教程Python
- Realm資料庫 從入門到“放棄”資料庫
- NoSQL 資料庫案例實戰 -- MongoDB資料備份、恢復SQL資料庫MongoDB
- 開源走向世界(下):從資料庫技術演進看開源力量丨BDTC 2021資料庫
- 全面總結!阿里巴巴資料庫運維演進之路阿里資料庫運維