[toc]

數(shù)據(jù)庫作業(yè)

存儲技術(shù)

在數(shù)據(jù)庫中仿荆，在數(shù)據(jù)存儲方面贰您，一般分為定長，和變長拢操，兩種方式锦亦。采用定長存儲的時候，每條記錄分配的長度是固定令境。不論記錄的內(nèi)容杠园，是否使用完分配的地址，都采用固定的空間舔庶。采用變長存儲抛蚁，每條記錄分配的地址長度不是固定，很多時候惕橙，分配的都是記錄實際存儲位置的瞧甩，一個地址，在查找的過程中弥鹦，根據(jù)地址找到實際的數(shù)據(jù)位置肚逸。
針對變長，和定長，的優(yōu)缺點朦促，我自己歸納如下：

定長：

優(yōu)點：

1. 策略簡單犬钢，程序?qū)崿F(xiàn)方便，不需要過多的維護指針的地址內(nèi)容思灰。如果是相鄰存儲。所有地址混滔，都有可能通過直接計算得出地址洒疚。（實際上，在實現(xiàn)作業(yè)三的時候坯屿，采用的就是定長地址）油湖。
2. 方便批量順序讀取，大數(shù)量讀取的時候领跛，效率高乏德。
3. 數(shù)據(jù)集中，不易產(chǎn)生碎片

缺點：

1. 空間浪費吠昭，如果當(dāng)字段大部分記錄長度短喊括。其中有某一個記錄的長度很大，按定長存儲策略矢棚，就會造成空間很大的浪費：

   例如：我在實現(xiàn)作業(yè)三的過程中郑什，曾經(jīng)創(chuàng)建過這樣一個shcema的數(shù)據(jù)表['int', 'text(6)', 'text(50)', 'int']。在第三個text字段蒲肋，我采用分配50個字節(jié)記錄蘑拯。生成1w條數(shù)據(jù)的時候，大約占用內(nèi)存700多kb（而不是680k兜粘，因為用了申窘，分塊存儲，1K數(shù)據(jù)一塊孔轴，為了對齊剃法，中間有些空間，為空）距糖。但是玄窝，采用['int', 'text(6)', 'text(500)', 'int']這樣的schema，第三個text字段采用500個字節(jié)悍引，同樣是1w的數(shù)據(jù)量恩脂，大約占用內(nèi)存19.1M。如下圖：

   數(shù)據(jù)占用內(nèi)存的截圖

2. 對于極大的字段內(nèi)存空間節(jié)約會更理想趣斤。例如有些數(shù)據(jù)庫字段存放電影俩块。有些記錄，是2G的電影內(nèi)容，有些是電影的標(biāo)題玉凯，如果采用變長字段势腮，將會極大的減少數(shù)據(jù)庫的大小

變長：

優(yōu)點：

1. 節(jié)省空間，特別是在記錄漫仆，長度不一的時候捎拯，刪除修改方便。(只需要修改盲厌，或標(biāo)記該地址為空閑)

缺點：

1. 程序?qū)崿F(xiàn)復(fù)雜署照，維護記錄地址，需要小心
2. 對于跨塊記錄存儲的記錄吗浩，要小心建芙。
3. 數(shù)據(jù)不集中，讀取數(shù)據(jù)局部性不高懂扼，影響i/o效率

變長記錄禁荸，在部分商業(yè)數(shù)據(jù)庫中的應(yīng)用

sqlite 應(yīng)用變長記錄

sqlite定位為嵌入式數(shù)據(jù)庫，因此在數(shù)據(jù)庫空間大小上阀湿，要求更嚴(yán)格赶熟，因此采用變長記錄更為合理，更符合產(chǎn)品定位

在sqlite的官網(wǎng)文檔中炕倘，提供钧大，vacuum，命令罩旋，用于在刪除大量記錄之后啊央，手動釋放sqlite空閑空間使得數(shù)據(jù)庫文件壓縮到最小

由于sqlite采用的是變長存儲。在大量插入數(shù)據(jù)的時候涨醋，數(shù)據(jù)庫空間瓜饥，會自發(fā)增長，當(dāng)在原有數(shù)據(jù)庫中大量刪除數(shù)據(jù)時浴骂，就會有大量的存儲空間乓土，被標(biāo)為空閑，如果后面再插入數(shù)據(jù)溯警，優(yōu)先在這些空閑塊中插入數(shù)據(jù)趣苏。
這就存在一個問題，sqlite數(shù)據(jù)庫梯轻，會只增加食磕，不縮小。vacuum命令喳挑，就提供一種手動是否空閑空間的工具彬伦，使得空間壓縮到最小滔悉。

插入大量數(shù)據(jù)sqlite大小

刪除數(shù)據(jù)后sqlite大小

運行vacuum命令之后单绑，數(shù)據(jù)大小

MongoDB MMAPV1引擎應(yīng)用定長記錄

這一部分回官，沒有做實驗儒旬，資料來源于閱讀MogoDB官方文檔

MogoDB覆山，定位為 Nosql 數(shù)據(jù)庫。屬于文檔型數(shù)據(jù)庫狠持，在OLAP区转，和OLTP上都有應(yīng)用唯袄。其中MMAPV1 (Mobile Messaging Access Protocol) 存儲引擎是原聲引擎，官網(wǎng)文檔蜗帜，定義如下

`MMAPv1 is MongoDB’s original storage engine based on memory mapped files. It excels at workloads with high volume inserts, reads, and in-place updates.`

之所以，提供高新能的插入资厉，讀取厅缺，和原地修改，與MMAPV1引擎的數(shù)據(jù)存儲策略有關(guān)宴偿。在MMAPV1引擎中湘捎，所有數(shù)據(jù)，相鄰存儲窄刘，初始空間分配大小為2倍(2 size of Allocation)分配空間的時候盡量是2的倍數(shù)空間大小窥妇。小于2M的數(shù)據(jù)，按數(shù)據(jù)量的2倍分配娩践。大于2M數(shù)據(jù)活翩，按2M的倍數(shù)分配。(如14.1M數(shù)據(jù)翻伺，會分配16M的空間)這樣帶來的好處是材泄，充分利用空間，做到跟操作系統(tǒng)地址對齊吨岭，讀取效率更高拉宗。同時，2 size of Allocation策略辣辫，也能使得數(shù)據(jù)在修改的時候旦事，盡可能的保證, high volume inserts, reads, and in-place updates.
在mogoDB中，如果是采用MogoDB作為OLAP數(shù)據(jù)倉庫急灭，么么針對姐浮，一些不常修改的數(shù)據(jù)，可以采用full fit策略化戳，這樣能使得數(shù)據(jù)實際大小和占用空間大小单料，盡可能的接近埋凯，這種策略能最大程度上使用磁盤。

不論是定長存儲扫尖，還是變長存儲白对。都要針對特定的數(shù)據(jù)庫產(chǎn)品，采用特定的策略

索引技術(shù)

在絕大部分?jǐn)?shù)據(jù)管理系統(tǒng)中换怖，都會應(yīng)用到索引技術(shù)甩恼，來加快，數(shù)據(jù)查找的效率沉颂，其中索引条摸，分類有稠密索引，和稀疏索引铸屉。種類钉蒲，有，B樹索引彻坛，哈希索引顷啼，R-樹索引，kd-樹索引等昌屉。在mysql中钙蒙，默認(rèn)的建立索引的方式為B樹索引，所以我主要了解间驮，只有B樹索引：
實際的產(chǎn)品數(shù)據(jù)庫中躬厌，數(shù)據(jù)量大的時候大多采用多級索引，即竞帽，在索引上扛施，再建索引，上層索引一定是稀疏索引

索引技術(shù)在mysql中幫助提高查詢效率

info_schema表屹篓，為mysql優(yōu)化提供了很多有用的信息

show create table titles 查看表結(jié)構(gòu)煮嫌，和索引細(xì)節(jié)

這次實驗，采用的是mysql中官方發(fā)布的employees數(shù)據(jù)庫抱虐，employee表結(jié)構(gòu)如下圖

employee表結(jié)構(gòu)

表數(shù)據(jù)量

命令行查看表索引信息谣沸，explain子句信息

通過輸出信息刷钢，了解到表之后，一個3個字段的多列索引乳附。輸出的rows字段内地，為442308伴澄，表明在where條件上的select查詢語句，用到的策略是全表掃描阱缓，

myssql 添加索引非凌，及不添加索引，前后效率效果比對

如果在表上加上索引荆针，rows預(yù)計需要掃描的行數(shù)量敞嗡，就縮減為69行。能大大加快表的查詢

用過索引航背，查詢預(yù)計行數(shù)大大減小

創(chuàng)建數(shù)據(jù)庫索引喉悴，注意事項

數(shù)據(jù)庫索引，確實能在生產(chǎn)環(huán)境中給數(shù)據(jù)查詢帶來很大的效率提升玖媚。大部分時候帶來的提升箕肃，可能會有幾倍，或者幾十倍的效率提升空間今魔。但是并不是所有時候都適合創(chuàng)建索引

比如突雪。如果數(shù)據(jù)庫的量比較大，往往在新建索引的時候可能會花費幾十分鐘涡贱，甚至是幾個小時，而在創(chuàng)建索引的過程中惹想，數(shù)據(jù)庫是阻塞的问词。這個時候所有的請求都會等待，這在實際的生產(chǎn)環(huán)境中嘀粱，很可能是不被容許的激挪。
除此之外，如果會在一張表上锋叨，創(chuàng)建多個索引的話垄分，如果在一個sql語句中創(chuàng)建多個索引，會比每個sql語句創(chuàng)建一個sql語句效率來的更高娃磺。時間有時候能縮短為幾分之一 薄湿。
在表中插入索引，的確能給數(shù)據(jù)庫的查詢帶來很大的提升偷卧，但是同時在數(shù)據(jù)進(jìn)行插入的時候豺瘤，對索引的維護，也需要一些代價听诸，因此在實際生產(chǎn)的環(huán)境中坐求，平衡讀取和寫入數(shù)據(jù)的時間，合理利用索引技術(shù)也是必須要注意的技能

EXPLAIN語法各列字段的意義：

• key: 優(yōu)化器晌梨，使用的索引
• rows: 估計結(jié)果行數(shù)
• possible_keys: 可能用到的索引桥嗤，可以通過show indexes 來查看表格
• ref:用來比較的列须妻，或者常量
• type:const表示只有一行結(jié)果。ref泛领，表示具有匹配的索引荒吏，都會被用到
• select_type: simple表示簡單查詢 derived 表示查詢的表，不是一個物理表师逸，比如司倚，在子查詢中再查詢。
• table: 用到的表格
• key_len: 索引篓像，結(jié)構(gòu)長度
• filtered:返回結(jié)果的行占需要讀到的行

sql優(yōu)化的工作流

1. 截取sql語句
2. 識別出分類有問題的sql語句
3. 確認(rèn)sql語句的操作
4. 分析sql語句和輔助信息
5. 優(yōu)化sql語句
6. 驗證優(yōu)化的結(jié)果

從mysql中截取sql語句的方法动知，有全面查詢?nèi)罩荆樵內(nèi)罩驹北纾M(jìn)程列表這幾個方法全面查詢?nèi)罩竞辛福吐樵內(nèi)罩荆饕ㄟ^設(shè)置mysql數(shù)據(jù)庫的設(shè)置選項奠滑，其中全面查詢?nèi)罩镜ぶ澹梢栽谇捌跀?shù)據(jù)庫不太大的情況下使用，但是在生產(chǎn)環(huán)境下使用會嚴(yán)重影響到數(shù)據(jù)庫的性能宋税。慢查詢?nèi)罩就ㄟ^記錄數(shù)據(jù)庫中查詢時間超過某個閥值的時候摊崭，記錄下查詢信息，其中日志信息包括很多數(shù)據(jù)杰赛，通過日志可以了解到呢簸，語句執(zhí)行頻率，來源用戶以及主機乏屯。等個得到的執(zhí)行時間根时，處理過的行，以及結(jié)果集的大小辰晕。的最小蛤迎，最大，平均以及中間值的統(tǒng)計信息含友。同事也有一些開源的工具替裆，能對日志文件進(jìn)行分析。

當(dāng)從日志文件中分析出需要優(yōu)化的sql語句止嘔胡窘问，就可用通過上面EXPLAIN 語法查看具體sql的執(zhí)行計劃扎唾，和表格上現(xiàn)在所擁有的一些索引信息，已經(jīng)字段長度等等南缓，通過查看具體的EQP胸遇，創(chuàng)建合適的索引進(jìn)行查詢優(yōu)化。

在優(yōu)化了查詢語句之后汉形，需要在實際的數(shù)據(jù)中驗證優(yōu)化效果纸镊。最后應(yīng)用到生產(chǎn)環(huán)境中去倍阐。

mysql 中的join算法

mysql 默認(rèn)的采用的是簡單嵌套查詢，基于的實際假設(shè)是：數(shù)據(jù)庫表大小逗威，都能完全放入機器內(nèi)存當(dāng)中峰搪。
我設(shè)計了一個實驗，讓myslq凯旭，對一個129M 和1.7G的數(shù)據(jù)進(jìn)行鏈接（不超過內(nèi)存概耻，機器內(nèi)存16G大小）罐呼，建立約束條件鞠柄。查看myssql實際的io數(shù)量。實際的數(shù)據(jù)大小嫉柴，和數(shù)據(jù)內(nèi)容如下：兩個數(shù)據(jù)集大小

兩個數(shù)據(jù)的數(shù)據(jù)大小

數(shù)據(jù)集一字段內(nèi)容

數(shù)據(jù)格式

數(shù)據(jù)集二字段內(nèi)容

數(shù)據(jù)格式2

給兩個數(shù)據(jù)集創(chuàng)建外鍵約束厌杜，在創(chuàng)建約束過程中，會使用連接算法

進(jìn)行連接操作

用iostat這個工具计螺，監(jiān)控磁盤io數(shù)據(jù)輸出夯尽。輸出的結(jié)果如下下圖所示：

磁盤io數(shù)據(jù)輸出

工具輸出的數(shù)據(jù)，是以累計值登馒，數(shù)據(jù)匙握，所以兩者差額，約為7.2G陈轿，7.2G/1.5的數(shù)據(jù)圈纺，大約為5得出的io統(tǒng)計量為5倍io
從上面的結(jié)果來看，在建立外鍵約束济欢，之后，查詢的效率就高很多能在0.0072秒只能返回查詢結(jié)果

NewSQL系統(tǒng)的一些技術(shù)

內(nèi)存查找結(jié)構(gòu)小渊，skip-list

skiplist介紹

Skip List 是一種隨機化的數(shù)據(jù)結(jié)構(gòu)法褥，基于并聯(lián)的鏈表，其效率可比擬于二叉查找樹（對于大多數(shù)操作需要 O(log n) 平均時間）酬屉“氲龋基本上，跳躍列表是對有序的鏈表增加上附加的前進(jìn)鏈接呐萨，增加是以隨機化的方式進(jìn)行的杀饵，所以在列表中的查找可以快速的跳過部分列表 (因此得名)。所有操作都以對數(shù)隨機化的時間進(jìn)行谬擦。Skip List 可以很好解決有序鏈表查找特定值的困難切距。

一個跳表，應(yīng)該具有以下特征：

1. 一個跳表應(yīng)該有幾個層（level）組成惨远；
2. 跳表的第一層包含所有的元素谜悟；
3. 每一層都是一個有序的鏈表话肖；
4. 如果元素 x 出現(xiàn)在第 i 層，則所有比 i 小的層都包含 x葡幸；
5. 第 i 層的元素通過一個 down 指針指向下一層擁有相同值的元素最筒；
6. 在每一層中，-1 和 1 兩個元素都出現(xiàn) (分別表示 INT_MIN 和 INT_MAX)蔚叨；
7. Top 指針指向最高層的第一個元素床蜘。

就像這張表的結(jié)構(gòu)

skip-list

Skip List 構(gòu)造步驟：

1. 給定一個有序的鏈表。
2. 選擇連表中最大和最小的元素蔑水，然后從其他元素中按照一定算法（隨機）隨即選出一些元素邢锯，將這些元素組成有序鏈表。這個新的鏈表稱為一層肤粱，原鏈表稱為其下一層弹囚。
3. 為剛選出的每個元素添加一個指針域，這個指針指向下一層中值同自己相等的元素领曼。Top 指針指向該層首元素
4. 重復(fù) 2鸥鹉、3 步，直到不再能選擇出除最大最小元素以外的元素

skip-list 和二叉樹中的比較

如果單純比較性能庶骄，跳躍表和二叉樹可以說相差不大毁渗，但是加上并發(fā)的環(huán)境就不一樣了，
如果要更新數(shù)據(jù)单刁，跳躍表需要更新的部分就比較少灸异，鎖的東西也就比較少，所以不同線程爭鎖的代價就相對少了羔飞，
而二叉樹有個平衡的過程肺樟，牽涉到大量的節(jié)點，爭鎖的代價也就相對較高了逻淌。性能也就不如前者了么伯。
在并發(fā)環(huán)境下skiplist有另外一個優(yōu)勢，二叉樹在插入和刪除的時候可能需要做一些rebalance的操作卡儒，這樣的操作可能會涉及到整個樹的其他部分田柔，
而skiplist的操作顯然更加局部性一些，鎖需要盯住的節(jié)點更少骨望，因此在這樣的情況下性能好一些硬爆。

高并發(fā)，采用的 replica set技術(shù)

采用 quoram 機制+守護進(jìn)程（即保證冗余又能保證數(shù)據(jù)庫最終一致性擎鸠，來源于鴿巢原理）缀磕，保證寫入的時候，不完全更新所有數(shù)據(jù)，但又在返回的時候保證返回給用戶的數(shù)據(jù)是有效的

mogodb中使用replica set 技術(shù)虐骑，在分布式的情況下准验，把主機分為primary 和seccondprimary對外提供接口服務(wù)，當(dāng)一個寫入請求發(fā)送到primary中廷没，primary節(jié)點糊饱，對請求進(jìn)行解析，之后再分發(fā)給相應(yīng)的second節(jié)點颠黎，各個節(jié)點通過定時發(fā)送heart beat進(jìn)行同步另锋。

其中quoram 機制，是保證高并發(fā)狭归，和數(shù)據(jù)一致性的一個重要的機制夭坪。假如：當(dāng)一份數(shù)據(jù)在分布式集群中，有存有三份过椎，當(dāng)寫入數(shù)據(jù)的時候室梅，不需要三份數(shù)據(jù)都要修改，只需要修改兩份數(shù)據(jù)疚宇。當(dāng)下一個讀請求來的時候亡鼠，只需要讀取兩份數(shù)據(jù)，在這兩份數(shù)據(jù)中敷待，一定存在至少一份數(shù)據(jù)是修改之后的數(shù)據(jù)间涵。當(dāng)這個原理推廣到數(shù)據(jù)有N份冗余的時候，只需要在數(shù)據(jù)中榜揖，寫入K個數(shù)據(jù)勾哩，當(dāng)讀的時候，讀取N—K+1份數(shù)據(jù)的時候举哟，那么必定至少有一份數(shù)據(jù)是更新后的數(shù)據(jù)思劳。quoram機制，既能保證不完全更新妨猩，又能保證返回給用戶的數(shù)據(jù)是有效的潜叛。

對MogoDB的自問自答

為什么在已經(jīng)有mysql這種數(shù)據(jù)庫的情況下，還會出現(xiàn)MogoDB這樣的數(shù)據(jù)庫册赛？

1. MogoDB支持高并發(fā)------>mvvc钠导，quoram等震嫉。而mysql在單節(jié)點上比較適合森瘪，當(dāng)并發(fā)連接數(shù)量大了之后，性能就跟不上
2. 不需要大表連接 ------->mysql 大表連接性能差票堵。在MogoDB中數(shù)據(jù)是noschema的并以文檔的形式存儲扼睬。這樣就能盡可能的減少表連接操作提高相應(yīng)速度
3. 可擴展--------->MogoDB既能橫向擴展又能縱向擴展上，當(dāng)10臺機器，解決不了的時候窗宇，可以橫向擴展措伐。加到100臺，1000臺军俊，也許整體執(zhí)行效率不高侥加，但是能合作解決以往傳統(tǒng)數(shù)據(jù)解決不了的大數(shù)據(jù)量問題
4. 對于OLAP，aggregation操作粪躬，進(jìn)行優(yōu)化担败，提供了自己的語言來支持更高效率的map reduce操作。并且對json镰官，sql都有比較好的支持
5. 同時提供full text search 和地理位置索引有很好的支持提前，這些在傳統(tǒng)的面向?qū)ο蟮臄?shù)據(jù)庫中通常很弱

針對硬件發(fā)展優(yōu)化的技術(shù)

memsql，meesql數(shù)據(jù)庫的口號是sreaming transations analytics all in one system.針對流數(shù)據(jù)進(jìn)行一站式開發(fā)
memsql是一種內(nèi)存數(shù)據(jù)庫泳唠。傳統(tǒng)數(shù)據(jù)庫狈网，disk做主存，rammemory笨腥，做cache拓哺。memsql把memory作為主存。disk作為backup扇雕，或者journal使用拓售，因為針對流數(shù)據(jù)，優(yōu)化镶奉，所有數(shù)據(jù)只做順序讀寫础淤。充分利用存儲金字塔。充分利用硬件哨苛，加快計算效率鸽凶。在內(nèi)存中，memsql采用行存儲建峭，并采用想skip-lists和hashtable這樣的針對內(nèi)存計算優(yōu)化的數(shù)據(jù)結(jié)構(gòu)加快計算玻侥。在disk中采用列存儲結(jié)構(gòu)。更高效的存儲數(shù)據(jù)
而且memsql的驅(qū)動亿蒸，與mysql完全兼容凑兰，針對程序員是透明的這一點在降低開發(fā)門檻很有效果。雖然memsql是一種內(nèi)存數(shù)據(jù)庫边锁，但memsql在斷電的時候姑食，并不會丟失所有的數(shù)據(jù)，因為memory是主存茅坛，disk做backup和journal音半。在斷電的時候任然能通過journal找回數(shù)據(jù)。是一種針對通用硬件，同事支持企業(yè)級應(yīng)用的高性能內(nèi)存數(shù)據(jù)庫曹鸠。支持完全的SQL
同事memsql可以設(shè)置持久化煌茬，并能很好的與spark等高性能計算平臺進(jìn)行集成成為實時計算的一種較好的選擇

但memsql也有不適合的應(yīng)用場景

1. memsql 不適合存儲對象
2. 不適合低端硬件。官網(wǎng)建議最低的硬件 4core 8GB
3. 不適合作為共享DB(單節(jié)點安裝)
4. 不適合作全文檢索

memsql 自問自答

為什么有了mysql MogoDB 之后彻桃，還有memsql這款產(chǎn)品

1. 針對的應(yīng)用場景不同坛善，memsql針對流計算，更傾向與實時高性能計算邻眷，mysql浑吟，MogoDB更傾向與事務(wù)或者實時性要求不高的計算任務(wù)
2. 針對高性能計算采取了多種優(yōu)化，如內(nèi)存行存儲耗溜。disk列存儲组力。應(yīng)用skip-list，hashtable等加快計算
3. 能與spark進(jìn)行集成
4. 完全的SQL抖拴，能通過code genarationg加快燎字，sql的運行

memsql與傳統(tǒng)數(shù)據(jù)庫相比，有什么優(yōu)勢

1. 可擴展阿宅，集成候衍。能與spark深度集成
2. 基于流，無buffer pool （傳統(tǒng)表數(shù)據(jù)庫洒放，在處理大數(shù)據(jù)量時候蛉鹿，假設(shè)不能完全放入內(nèi)存中，內(nèi)存設(shè)置buffer pool由DB和table共享往湿，會產(chǎn)生競爭妖异。導(dǎo)致爭奪）
3. 采用lock-free技術(shù)最大化實現(xiàn)并發(fā)，用skip lists领追，或者h(yuǎn)ash table優(yōu)化內(nèi)存數(shù)據(jù)
4. code-genaration他膳。lock-free技術(shù)的使用，使得解析動態(tài)sql的時候成為限制因素绒窑。所以對sql語句進(jìn)行預(yù)編譯棕孙。加快數(shù)據(jù)庫運行。

數(shù)據(jù)庫技術(shù)發(fā)展感悟

在今年上半年些膨，看過的一篇文章《what comes around goes around》過去經(jīng)歷的蟀俊，將來也會再一次到來。數(shù)據(jù)庫订雾，從最開始的樹型結(jié)構(gòu)肢预，網(wǎng)狀結(jié)構(gòu)，星型結(jié)構(gòu)葬燎，再到現(xiàn)在廣泛使用的表結(jié)構(gòu)∥笊酰現(xiàn)在在大數(shù)據(jù)時代，于是谱净，又出現(xiàn)了一些窑邦，例如MogoDB，這些文檔型數(shù)據(jù)庫壕探。無疑感覺是一種輪回冈钦。

在數(shù)據(jù)庫技術(shù)發(fā)展的歷史過程中，我認(rèn)為經(jīng)歷了這樣的一些過程

1. 數(shù)據(jù)量大---》機器性能相對弱----》優(yōu)先考慮性能
2. 程序員管理李请，苦不堪言----》性能低下
3. 機器性能提升瞧筛，數(shù)據(jù)壓力減小------》優(yōu)先考慮程序員
4. 關(guān)系型數(shù)據(jù)庫----》管理技術(shù)趨于統(tǒng)一-------》一統(tǒng)天下
5. 回到第一步

回顧數(shù)據(jù)庫技術(shù)發(fā)展歷史，數(shù)據(jù)從最初版本的用文件系統(tǒng)管理导盅。然后出現(xiàn)了數(shù)據(jù)量大较幌，使用文件系統(tǒng)管理效率太低，而且機器的性能這個時候又不夠白翻，這個時候考慮的是如何在有限的硬件條件下乍炉，如何把不能解決的問題嘗試去解決。優(yōu)先能不能處理的問題滤馍。就在這一時期岛琼，出現(xiàn)了樹狀結(jié)構(gòu)，網(wǎng)狀結(jié)構(gòu)巢株，星型結(jié)構(gòu)槐瑞。效率高了，以前不能解決的現(xiàn)在能夠解決了阁苞。這是第一個階段

第二個階段困檩。雖然數(shù)據(jù)是能解決了。但是隨著數(shù)據(jù)管理技術(shù)的結(jié)構(gòu)設(shè)計讓程序員管理手動查詢這個時候那槽，對之前存在的遺留代碼的管理操作窗看。讓后來的從業(yè)者苦不堪言。而且倦炒，最重要的是不同程度技術(shù)的程序員显沈，寫出的程序效率相差很大。這個時候逢唤，就會呼吁把數(shù)據(jù)管理拉讯，交給系統(tǒng)解放一部分程序員。

第三個階段鳖藕，隨著機器性能的提升魔慷，計算機的廣泛應(yīng)用，越來越多的IT技術(shù)從業(yè)者著恩。強烈要求妥協(xié)一部分性能院尔。讓廣大普通程序員也能寫出性能效率良好的管理工具蜻展，這個時候，出現(xiàn)了基于關(guān)系運算的數(shù)據(jù)處理技術(shù)邀摆，出現(xiàn)了給廣大程序員提供一個統(tǒng)一的接口纵顾，而不用考慮數(shù)據(jù)庫內(nèi)部的運行過程。

第四各階段栋盹，在這個時候施逾。機器性能的提升，新理論的出現(xiàn)例获。利用機器性能提升的特點汉额。關(guān)系型數(shù)據(jù)庫似乎出現(xiàn)了一統(tǒng)天下的局面。之后榨汤，就是關(guān)系型數(shù)據(jù)庫的廣泛應(yīng)用

第五個階段蠕搜。隨著數(shù)據(jù)庫越來越廣泛的應(yīng)用。數(shù)據(jù)積累的速度收壕，也成指數(shù)性增長讥脐。于是又出現(xiàn)了類似第一階段出現(xiàn)的問題，數(shù)據(jù)量大啼器，機器性能相對弱

數(shù)據(jù)庫技術(shù)旬渠，有10年理論，10年發(fā)展端壳，10年應(yīng)用的說法告丢。我們現(xiàn)在所處的位置，似乎又回到了最初的數(shù)據(jù)量大损谦，機器弱岖免，優(yōu)先考慮性能的這個階段。觀察照捡，有些大數(shù)據(jù)管理系統(tǒng)如MogoDB颅湘，優(yōu)先考慮性能，如栗精，它會給用戶暴露特定的針對MogoDB特有的編程規(guī)范闯参，來加速系統(tǒng)的運行。這就類似于程序員手動管理悲立。

這是一種鹿寨，用人力，換取效率的過程薪夕。帶來的提升就是脚草，以往不能解決的問題，現(xiàn)在能夠解決了原献。但是不久就會出現(xiàn)馏慨，維護不變埂淮，市場需求量大。廣大程序員需要一種写隶，效率不那么極致倔撞，但是能解決大部分問題的管理技術(shù)。未來樟澜，數(shù)據(jù)庫管理技術(shù)，會逐漸從零散到統(tǒng)一叮盘。從少量使用秩贰，到大量使用，最后又出現(xiàn)性能不夠處理的情況柔吼。

每一個輪回都是一次管理技術(shù)的提升毒费。每一次硬件的效率提升，都會帶來新一次的變革愈魏。有的變革是理論驅(qū)動觅玻。有的變革，是硬件技術(shù)上的提升

參考地址：
http://www.dongcoder.com/detail-300824.html