資料庫的前世今生
稱之為基礎軟體三駕馬車之一的資料庫,在經歷了層次型和網狀型、關係型資料型庫以及更加強大的資料管理功能等三個時期之後,其在未來的發展歷程中還有哪些更多的可能性?
基於此,卡內基梅隆大學電腦科學系資料庫學副教授 Andy Pavlo 曾於 2015 年為 CMU 電腦科學系 50 週年慶典上寫下了自己對於資料庫未來 50 年的構想。
在本文中,他提出了幾點:關係模型對於大多數應用而言仍將佔據主導地位,開發框架和資料庫管理系統將更加緊密地耦合在一起,從而使所有資料庫互動都透明化,SQL 仍然是與 DBMS 互動的實際語言,但人類永遠都不會真正編寫 SQL,將以自然語言查詢相關資料問題,這將導致程式設計方式發生重大變化。無所不在的「物聯網」意味著每個裝置都能收集其環境的資料,對於新硬體,更靈活和可程式設計的處理結構將更為普遍,人類作為資料庫管理員的角色將不復存在,DBMS 最終將完全自治和自我修復,星際裝置的資料庫事務將興起,最終,「我將在 50 年後去世」。
作者 | Andy Pavlo
譯者 | 譚開朗,責編 | 屠敏
出品 | CSDN(ID:CSDNnews)
以下為譯文:
最終,我還是從事了我曾揚言不會從事的職業:成為一名教授,有自己的部落格,但從不更新。我知道,距離我上次發表文章已有一年之久,我也需要給事務處理資料庫系統這一開放議題撰寫第三部分內容。去年在CMU發生了很多事情,我計劃在專案更加完善後再在這裡討論。預告幾點:
我們正在開發一個新的分散式DBMS;
我們正在構建一個用於測試和基準化分析的“準備啟用的”大型OLTP應用程式庫;
我們正在建立一個線上資料庫系統百科全書。
當然,還有很多併發控制和非易失性記憶體工作。毫無疑問,我的課外教授活動已經顧不太上了。
以下是我寫的一篇文章,作為下個月CMU電腦科學系50週年慶典的一部分。我們每個教員的任務是:針對自身所在的領域,展望其在2065年的發展概況。所以,我的任務是概述資料庫系統在50年後的樣子。但是,在我展望未來之前,我首先花一些時間來討論資料庫的過去和現在。
01
資料庫的過去
第一個資料庫管理系統(DBMS)在1968年上線。IBM的IMS用於跟蹤土星5號和阿波羅太空探索專案的供應和零部件庫存。它引入了這樣一種思想,即應用程式的程式碼應該與它所操作的資料分離。由此支援開發人員編寫只關注資料訪問和操作的應用程式,而不關注與執行這些操作和確保資料安全相關的複雜性和開銷。IMS之後,在20世紀70年代早期,IBM的System R和加州大學的INGRES率先開發了第一個關係型DBMS。
第一批系統的資料庫工作負載沒有今天那麼複雜和多樣化。在這些早期的應用程式中,操作員通過終端啟動事務,然後手動向系統輸入新資料。此時,DBMS的預期峰值吞吐量僅為每秒數十到數百個事務,響應時間以秒為單位度量。這些早期DBMS的體系結構也基於當時流行的計算硬體。它們通常部署在只有一個CPU核心和少量主記憶體的計算機上。對於這些系統來說,磁碟是資料庫的主要儲存位置,因為磁碟能夠儲存比記憶體更大的資料,而且成本更低。
02
資料庫的現在
儘管在50年後,我們使用資料庫的方式發生了很大的變化,關係模型和SQL仍然是組織資料庫並與之互動的主要方式。許多網際網路應用程式需要每秒支援數十萬甚至數百萬個事務,每個事務的處理延遲以毫秒為單位。這是因為它們同時與數百萬使用者和其他計算機系統相連。現在,企業和組織能夠從這些應用程式中收集大量的資料,他們希望分析這些資料來推斷新的資訊,以指導他們的決策。基於此,近年來我們看到了針對特定應用場景的專門系統的興起,這些應用場景的效能比基於1970年代架構的通用DBMS要好得多。現在有一些DBMS旨在為聯機事務處理(OLTP)應用程式快速獲取新資訊,還有一些DBMS旨在為複雜的聯機分析處理(OLAP)程式儲存大量資料。
這些較新的DBMS還利用了近年來出現的三種主要硬體趨勢。首先是大記憶體計算機的出現,這使得現在可以部署少量的機器,這些機器有足夠的DRAM來儲存除了最大的OLTP資料庫之外的所有資料。將資料儲存在記憶體中可以確保DBMS能夠以較低的延遲同時處理許多事務。根據我們的經驗,用於現代OLTP應用程式的資料庫的大小通常為幾百GB。與OLAP資料倉儲相比,DBMS可以管理幾個PB大小的資料庫。這是因為OLTP資料庫儲存應用程式的當前狀態(例如,最近90天的訂單),而OLAP資料庫儲存組織的所有歷史資訊(例如,所有下過的訂單)。因此,OLAP DBMS仍然主要儲存在磁碟上,並使用一些優化,如壓縮或柱狀儲存,以克服它們較長的訪問時間。
第二個硬體趨勢是從提高單核CPU時鐘速度到多核CPU的轉變。時脈頻率已保持了幾十年的增長,但現在增長已經停止,因為硬功率限制和複雜性的問題。複雜的、無序的、超標量的處理器正在被簡單的、有序的、單問題核心所取代。在DBMS中利用這種增加的並行性是很困難的,因為協調數百個執行緒的共享資料的訪問非常複雜。現代DBMS使用低開銷併發控制和其他無鎖技術來提高系統的可伸縮性。
第三個趨勢是商品硬體的成本降低。這在雲端計算平臺中尤為明顯。現在可以部署一個大型叢集,其處理和儲存能力只相當於十年前的一小部分。這種變化與1980-1990年代相比,過去十年中沒有共享的DBMS的數量在不斷增加。
儘管取得了這些進展,但仍然存在一些重大問題,由此阻礙了許多人部署資料密集型應用程式。所有這些的一個主要主題是,資料庫仍然是計算系統(例如,部署、配置、管理)的人工密集型元件。使用兩個獨立的DBMS分離OLTP和OLAP工作負載,以避免其中一個工作負載減慢另一個工作負載的速度,但是它需要額外的程式來將資料從系統傳輸到另一個工作負載。除此之外,調優DBMS以獲得特定應用程式的最佳效能是出了名的困難。許多組織求助於僱傭專家來為預期的工作量配置系統。但是,隨著資料庫的規模和複雜性的增長,優化DBMS以滿足這些應用程式的需求已經超出了人類的能力。
03
資料庫的未來
在接下來的50年裡,就像之前一樣,我們將看到資料庫領域的重大變化。除了儲存的資料量和速度明顯增大之外,資料庫在應用程式中的使用方式以及它們所部署的硬體型別也將發生重大變化。很難預測該領域的主要正規化轉變是什麼,預測哪些資料庫公司和產品仍然可用也是不現實的。因此,我發表一下對幾個廣泛主題的看法。
關係模型仍將主導大多數應用程式,但開發人員將不再需要過於擔心其應用程式使用的資料模型。程式設計框架和DBMS之間的耦合將更加緊密,這樣所有的資料庫互動都將是透明的(並且是最佳的)。同樣,SQL(或它的某種方言)將仍然是與DBMS互動的實際語言,但人類真實上永遠不會編寫SQL。相反,他們會用自然語言詢問有關資料的問題。這些變化將導致我們編寫程式的方式發生重大轉變;開發人員以一種最容易被人類理解的方式對其資料進行建模,然後框架(與DBMS一起)將自動為其生成最佳儲存方案。所有程式都將使用強一致的ACID事務執行。也就是說,在當今基於Web的應用程式中使用的最終一致性方法將避免增加管理的複雜性。在網路通訊、併發控制和資源管理方面將會有重大的改進,這將使用ACID事務變得更好並具有可伸縮性。
將來會有越來越多的應用程式更自然地將資料儲存在陣列或矩陣中。這是因為組織需要分析大量的非結構化資訊,尤其是視訊。我們將掌握將所有非結構化資料轉換成半結構化格式的能力,這種格式在DBMS中更容易組織和索引。作為其中的一部分,時效性也將變得重要,因為它關係到資訊如何隨時間的變化。目前的系統無法解釋這一點,因為在一個時間序列中儲存提取的每個視訊幀的資訊的開銷很大。
無處不在的“物聯網”將意味著每臺裝置都能夠收集有關其環境的資料。這將包括從小型嵌入式感測器到大型自主機器人。小型裝置將使用片上DBMS,就像手機現在包含片上視訊解碼器一樣。所有這些系統的資料庫將完全可以通過一些標準API(可能是SQL)進行組合和簡易的聯合。這意味著DBMS將以零配置彼此通訊。你只需將兩個DBMS相互指向對方,它們就會立即傳遞它們的資訊,並確保它們是同步的。某些管理器服務將能夠根據需要跨裝置分發查詢執行。人們將不需要手動配置提取-轉換-載入實用程式或其他工具來保持不同系統上的資料一致。以這種方式使所有不同的DBMS可組合和可互操作將是一項重要的工程工作。因此,將會有一個使用人工智慧或機器學習的工具包來自動地將不同的DBMS變體對映到彼此以進行相同的操作。
對於新的硬體,更靈活和可程式設計的製程將更普遍。DBMS將把程式的關鍵部分(例如鎖管理器)編譯到一個硬體加速器中。我們還將看到易失性和非易失性記憶體之間的二分法的消失。DBMS將假定所有記憶體都是快速和持久的,不需要維護變化無常的快取。這種新儲存器將比今天可用的儲存器大幾個數量級。因此,DBMS將在預先計算的物化檢視中儲存其資料的多個副本,以便快速響應任何可能的查詢。
資料庫管理員的角色將不復存在。這些未來的系統太複雜了,人類無法推理。DBMS最終將完全自治和自修復。同樣,程式設計框架和DBMS之間的緊密耦合將支援系統在組織資料、提供資源和優化執行方面做出比人工生成計劃更好的決策。
我們將看到星際裝置(如太空探測器)資料庫事務的增長。在這種情況下,在這些容器上執行的DBMS彼此之間的距離將比在地球上執行的系統要遠得多,並且會導致明顯較長的延遲(即延遲時間,分鐘或小時)。這意味著在今天基於web的應用程式中使用的弱一致性技術和實踐將被應用到這些星際系統中。
最後的最後,50年後我也已離開人世了吧。
原文:https://dev.to/seattledataguy/the-interview-study-guide-for-software-engineers-764
本文轉自 CSDN (ID:CSDNnews)
【End】
- END -
如果看到這裡,說明你喜歡這篇文章,請轉發、點贊。掃描下方二維碼或者微信搜尋「perfect_iscas」,新增好友後即可獲得10套程式設計師全棧課程+1000套PPT和簡歷模板,向我私聊「進群」二字即可進入高質量交流群。
↓掃描二維碼進群↓
喜歡文章,點個在看
相關文章
- 圖資料庫專案DGraph的前世今生資料庫
- 重新學習MySQL資料庫開篇:資料庫的前世今生MySql資料庫
- 基礎資料平臺的前世今生
- SQLMAP的前世今生Part2 資料庫指紋識別SQL資料庫
- InfiniBand 的前世今生
- Serverless 的前世今生Server
- Dubbo的前世今生
- IPD的前世今生
- MySQL 的前世今生MySql
- Mybatis的前世今生MyBatis
- DBHub的前世今生
- CRM的前世今生
- RabbitMQ的前世今生MQ
- Unicode的前世今生Unicode
- 【UV統計】海量資料統計的前世今生
- 【中國資料庫前世今生】資料儲存管理的起源與現代資料庫發展啟蒙資料庫
- Webpack前世今生Web
- 分庫分表系列:分庫分表的前世今生
- 聊聊 HTAP 的前世今生
- 聊聊ChatGPT的前世今生ChatGPT
- 遊戲的前世今生遊戲
- 元件化的前世今生元件化
- 外掛的前世今生
- HTTP/2.0的前世今生HTTP
- React ref 的前世今生React
- React Portal的前世今生React
- 資料視覺化之美:桑基圖的前世今生視覺化
- 從前世今生聊一聊,大廠為啥親睞時序資料庫資料庫
- Serverless For Frontend 前世今生Server
- LangChain和Hub的前世今生LangChain
- 雲原生的前世今生(一)
- “錕斤拷”的前世今生
- 中國SaaS的前世今生
- lua保護的前世今生
- SAP Cloud for Customer的前世今生Cloud
- HTTP 協議的前世今生HTTP協議
- iOS Device ID 的前世今生iOSdev
- Redux的前世-今生-來世Redux