postgresql , 資料庫特性 , 資料庫應用場景分析 , 資料庫選型
資料庫對于一家企業來說，相比其他基礎元件占據比較核心的位置。
有很多企業由于最初資料庫選型問題，導緻一錯再錯，甚至還有為此付出沉痛代價的。
資料庫的選型一定要慎重，但是這麼多資料庫，該如何選擇呢？
我前段時間寫過一篇關于資料庫選型的文章，可以參考如下
<a href="https://github.com/digoal/blog/blob/master/201702/20170208_03.md">《資料庫選型思考》</a>
另外，postgresql這個資料庫這些年的發展非常的迅猛，雖然國内還跟不上國外的節奏，但是相信國人逐漸會融合進去。
是以我專門針對postgresql提煉了它的一些應用場景（普通的應用場景就不舉例了），希望對你的選型可以起到一定的參考作用。
在一些前端的人機互動頁面中，經常會有很多選擇框，讓使用者進行選擇，這些選擇框可能對應的是資料庫表中的不同字段。
這種畫面經常出現在erp，電商，網站，手機app等場景中。
對于開發人員來說是一件很頭疼的事情，因為不知道該對哪些字段建立索引，或者幹脆對所有字段都建立索引，給資料庫帶來較大的性能和維護的問題。
postgresql中有兩個技術(gin, bloom索引)，可以完美的解決這類業務場景的問題。
<a href="https://github.com/digoal/blog/blob/master/201702/20170205_01.md">《寶劍贈英雄 - 任意組合字段等效查詢, 探探postgresql多列展開式b樹》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160523_01.md">《postgresql 9.6 黑科技 bloom 算法索引，一個索引支撐任意列組合查詢》</a>
有些場景，經常要對值進行範圍的比對。比如
物聯網，對傳感器上傳的值，進行範圍比對。
智能dns，需要對來源ip進行判斷，并找出其落在哪個ip位址段内。
金融行業，經常要設定一些名額範圍，時刻判斷指數是否落在某個區間，當一些指數落在某個範圍區間時，觸發下一步的操作（比如買入或賣出）。
傳統的兩個字段+複合b樹的索引，效率低下，通常8核的機器隻能達到3000多的qps。
postgresql通過(range類型和gist,sp-gist索引)，可以将效率提升20多備，8核的機器可以達到8萬的qps。
<a href="https://github.com/digoal/blog/blob/master/201701/20170126_02.md">《聊聊between and的坑 和 神奇的解法》</a>
<a href="https://github.com/digoal/blog/blob/master/201206/20120607_01.md">《postgresql 黑科技 range 類型及 gist index 20x+ speedup than mysql index combine query》</a>
<a href="https://github.com/digoal/blog/blob/master/201205/20120517_01.md">《postgresql 黑科技 range 類型及 gist index 助力物聯網(iot)》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161231_01.md">《從難纏的模糊查詢聊開 - postgresql獨門絕招之一 gin , gist , sp-gist , rum 索引原理與技術背景》</a>
人們為了更好的描述一個東西，有一種将大化小的思路，比如時鐘被分為了12個區域，每個區域表示一個小時，然後每個小的區域又被劃分為更小的區域表示分鐘。
在gis系統中，也有類似的思想，比如将地圖劃分成網格。通過編碼來簡化地理位置的判斷（比如相交，包含，距離計算等），但是請注意使用網格帶來的問題，比如精度的問題，網格的大小決定了精度，又比如相對坐标的問題，可能無法描述清楚邊界的歸屬。
postgresql可以提供給你更好的選擇，矢量化的運算。
1. 在postgis中雖然也支援網格對象的描述方式，但是并不是使用這種方法來進行幾何運算（比如相交，包含，距離計算等），是以不存在類似的精度問題，個人建議沒有強需求的話，不必做這樣的網格轉換。
2. 如果是多種精度地圖的切換（比如多個圖層，每個圖層代表一種地圖精度），建議使用輻射的方式逐漸展開更精細的圖層，以點為中心，逐漸輻射。（很多專業的地圖軟體是這樣做的）
<a href="https://github.com/digoal/blog/blob/master/201701/20170124_01.md">《蜂巢的藝術與技術價值 - postgresql postgis's hex-grid》</a>
電波表是一個非常典型的廣播應用，類似的還有多點傳播（注意不是主播哦），類似的應用也很多，比如廣播電視，電台等。
在資料庫中，其實也有類似的應用，比如利用postgresql資料庫的異步消息機制，往資料庫的消息通道發送資料，應用程式可以監聽對應的消息通道，擷取異步消息資料。
通過異步消息在資料庫中實作了一對多的廣播效果。
在物聯網中，也可以有類似的應用，例如結合postgresql的流式計算，當傳感器上報的資料達到觸發事件的條件時，往異步消息通道發送一則消息，應用程式實時的接收異步消息，發現異常。
這樣做的好處很多，即節省了空間（結合流式處理，完全可以輕量化部署），又能提高傳播的效率（一對多的傳播），程式設計也可以簡單化。
在金融行業，也可以有類似的實作，比如對資料的實時流式監測，資料流經一系列的規則，觸發異步消息。
<a href="https://github.com/digoal/blog/blob/master/201701/20170116_01.md">《從電波表到資料庫小程式之 - 資料庫異步廣播(notify/listen)》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170113_03.md">《從微信小程式 到 資料庫"小程式" , 鬼知道我經曆了什麼》</a>
一個例子
這個例子使用postgresql的異步消息通知機制（notify/listen），以及資料庫的觸發器，postgis地理庫插件，結合nodejs, socket.io實作了一個實時的用戶端gps坐标更新的小業務。
1. 在資料庫中新增gps坐标，資料庫端編寫的"小程式"會自動發送異步消息給用戶端，用戶端馬上就展示了目前新增的坐标
2. 修改gps坐标，資料庫端編寫的"小程式"會自動發送異步消息給用戶端，用戶端重新整理了目前坐标
3. 删除gps坐标，資料庫端編寫的"小程式"會自動發送異步消息給用戶端，用戶端重新整理了目前坐标
詳見
<a href="https://github.com/digoal/blog/blob/master/201701/20170113_02.md">《[轉載] postgres + socket.io + nodejs 實時地圖應用實踐》</a>
在物聯網、金融行業中，有大量的資料産生，同時需要實時的對資料進行處理。
pipelinedb是基于postgresql的一個流式計算資料庫，純c代碼，效率極高(32c機器,單機日處理流水達到了250.56億條)。同時它具備了postgresql強大的功能基礎，正在掀起一場流計算資料庫制霸的腥風血雨。
在物聯網(iot)有非常廣泛的應用場景，越來越多的使用者開始從其他的流計算平台遷移到pipelinedb。
pipelinedb的用法非常簡單，首先定義stream(流)，然後基于stream定義對應的transform(事件觸發子產品)，以及continuous views(實時統計子產品)
資料往流裡面插入，transform和continuous views就在後面實時的對流裡的資料進行處理，對開發人員來說很友好，很高效。
值得慶祝的還有，所有的接口都是sql操作，非常的友善，大大降低了開發難度。
<a href="https://github.com/digoal/blog/blob/master/201612/20161220_01.md">《流計算風雲再起 - postgresql攜pipelinedb力挺iot》</a>
除此之外，postgresql的undo table，batch排程, 異步消息結合，也能達到與pipeline一樣的效果。
<a href="https://github.com/digoal/blog/blob/master/201701/20170105_09.md">《postgresql 流式資料處理(聚合、過濾、轉換...)系列 - 9》</a>
<a href="https://github.com/digoal/blog/blob/master/201510/20151015_01.md">《基于postgresql的流式pipelinedb, 1000萬/s實時統計不是夢》</a>
<a href="https://github.com/digoal/blog/blob/master/201512/20151215_01.md">《"物聯網"流式處理應用 - 用postgresql實時處理(萬億每天)》</a>
ar紅包是gis與圖像、社交、廣告等業務碰撞産生的一個全新業務場景。
需要做廣告投放的公司，可以對着廣告牌，或者店鋪中的某個商品拍照，然後藏ar紅包。
要找紅包的人，需要找到這家店，并且也對準藏紅包的物體拍攝，比較藏紅包和找紅包的兩張圖檔，就可以實作搶紅包的流程。
可以想象的空間很多。
使用的核心技術是gis（地理位置）與圖像近似度比較。
postgresql對于這兩項技術都可以很好的支援。
<a href="https://github.com/digoal/blog/blob/master/201701/20170113_01.md">《(ar虛拟現實)紅包 技術思考 - gis與圖像識别的完美結合》</a>
在搜尋引擎、資料公司、網際網路中都會有網絡爬蟲的産品，或者有人機互動的産品。
有人的地方就有江湖，盜文、盜圖的現象屢見不鮮，而更慘的是，盜圖和盜文還會加一些水印。
也就是說，你在判斷盜圖、盜文的時候，不能光看完全一緻，可能要看的是相似度。
這給内容去重帶來了很大的麻煩，不過還好，postgresql資料庫整合了相似度去重的算法和索引接口，可以友善的處理相似資料。
比如相似的數組、相似的文本、相似的分詞、相似的圖像的搜尋和去重等等。
又比如鑒黃。
<a href="https://github.com/digoal/blog/blob/master/201701/20170112_02.md">《電商内容去重\内容篩選應用(如何高效識别轉載\盜圖\侵權?) - 文本相似、圖檔集相似、數組相似的優化和索引技術》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161126_01.md">《postgresql 在視訊、圖檔去重，圖像搜尋業務中的應用》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161222_02.md">《從相似度算法談起 - effective similarity search in postgresql》</a>
在一些應用程式中，可能需要對表的所有字段進行檢索，有些字段可能需要精準查詢，有些字段可能需要模糊查詢或全文檢索。
比如一些前端頁面下拉框的勾選和選擇。
這種需求對于應用開發人員來說，會很蛋疼，因為寫sql很麻煩，例子：
之前寫過一篇文章來解決這個問題
<a href="https://github.com/digoal/blog/blob/master/201604/20160419_01.md">《postgresql 行級 全文檢索》</a>
使用的是全文檢索，而當使用者的需求為模糊查詢時？ 如何來解決呢？
postgresql中可以很好的解決這個問題，适用于任意字元（包括英文、中文、等等）。
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_04.md">《postgresql 全表 全字段 模糊查詢的毫秒級高效實作 - 搜尋引擎顫抖了》</a>
随着it行業在更多的傳統行業滲透，我們正逐漸的在進入dt時代，讓資料發揮價值是企業的真正需求，否則就是一堆廢的并且還持續消耗企業人力，财力的資料。
傳統企業可能并不像網際網路企業一樣，有大量的開發人員、有大量的技術儲備，通常還是以購買it軟體，或者以外包的形式在存在。
資料的核心 - 資料庫，很多傳統的行業還在使用傳統的資料庫。
随着it向更多行業的滲透，資料類型越來越豐富（諸如人像、x光片、聲波、指紋、dna、化學分子、圖譜資料、gis、三維、多元 等等。。。），資料越來越多，怎麼處理好這些資料，怎麼讓資料發揮價值，已經變成了對it行業，對資料庫的挑戰。
對于網際網路行業來說，可能對傳統行業的業務并不熟悉，或者說網際網路那一套技術雖然在網際網路中能很好的運轉，但是到了傳統行業可不一定，比如說用于科研、軍工的gis，和網際網路常見的需求就完全不一樣。
除了對資料庫功能方面的挑戰，還有一方面的挑戰來自性能方面，随着資料的爆炸，分析型的需求越來越難以滿足，主要展現在資料的處理速度方面，而常見的hadoop生态中的處理方式需要消耗大量的開發人員，同時并不能很好的支援品種繁多的資料類型，即使gis可能也無法很好的支援，更别說諸如人像、x光片、聲波、指紋、dna、化學分子、圖譜資料、gis、三維、多元 等等。
那麼我們有什麼好的方法來應對這些使用者的痛處呢？
且看apsaradb産品線的postgresql與hybriddb如何來一招左右互搏，左手線上事務處理，右手資料分析挖掘，解決企業痛處。
對傳統企業來說，oltp系統大多數使用的是oracle等商業資料庫，使用postgresql可以與oracle的功能、性能、sql文法等做到高度相容。
而對于分析場景，使用mpp産品hybriddb(基于gpdb)，則可以很好的解決pb級以上的ap需求。
<a href="https://github.com/digoal/blog/blob/master/201701/20170101_02.md">《元旦技術大禮包 - apsaradb的左右互搏術 - 解決企業痛處 tp+ap混合需求 - 無須再唱《愛你痛到不知痛》》</a>
對于中小型企業，資料量在10tb量級的，分析型的事務甚至也可以交給postgresql來處理。
因為它具備了多核并行處理的能力、列存儲、jit、算子複用、甚至向量化執行等技術，相比傳統的資料庫，在oltp方面有10倍以上的性能提升。(同時還可以使用llvm技術，gpu卡\fpga卡來 硬體加速分析)
<a href="https://github.com/digoal/blog/blob/master/201612/20161216_01.md">《分析加速引擎黑科技 - llvm、列存、多核并行、算子複用 大聯姻 - 一起來開啟postgresql的百寶箱》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161001_01.md">《postgresql 9.6 引領開源資料庫攻克多核并行計算難題》</a>
電商推薦系統 部分需求介紹
比如一家店鋪，如何找到它的目标消費群體？
要回答這個問題，首先我們需要收集一些資料，比如：
1. 這家店鋪以及其他的同類店鋪的浏覽、購買群體。
我們在逛電商時，會産生一些行為的記錄，比如在什麼時間，逛了哪些店鋪，看了哪些商品，最後在哪家店鋪購買了什麼商品。
然後，對于單個商店來說，有哪些使用者逛過他們的商店，購買過哪些商品，可以抽取出一部分人群。
2. 得到這些使用者群體後，篩選出有同類消費欲望、或者具備相同屬性的群體。
對這部分人群的屬性進行分析，可以獲得一個更大範圍的群體，進而可以對這部分群體進行營銷。
以上是對電商推薦系統的兩個簡單的推理。
postgresql, hybriddb解決了推薦系統的三個核心問題
精準，屬于資料挖掘系統的事情，使用postgresql, greenplum 的 madlib機器學習庫可以實作。
實時，實時的更新标簽，在資料庫中進行流式處理，相比外部流處理的方案，節約資源，減少開發成本，提高開發效率，提高時效性。
高效，使用postgresql以及數組的gin索引功能，實作在萬億user_tags的情況下的毫秒級别的圈人功能。
<a href="https://github.com/digoal/blog/blob/master/201612/20161225_01.md">《恭迎萬億級營銷(圈人)潇灑的邁入毫秒時代 - 萬億user_tags級實時推薦系統資料庫設計》</a>
危化品的種類繁多。包括如常見的易爆、易燃、放射、腐蝕、劇毒、等等。
由于危化品的危害極大，是以監管顯得尤為重要，
1. 生産環節
将各個原來人工監控的環節數字化，使用 傳感器、流計算、規則（可以設定為動态的規則） 代替人的監管和經驗。
2. 銷售環節
利用社會關系分析，在銷售環節挖掘不法分子，挖掘騙貸、騙保的虛假交易。利用地理位置跟蹤，掌控整個交易的貨物運輸過程。
3. 倉儲環節
倉儲環節依舊使用傳感器、流計算、應急機制對倉管的産品進行實時的監管，而對于危化品本身，我們已經不能使用普通的資料類型來存儲，很幸運的是在postgresql的生态圈中，有專門支援化學行業的rdkit支援，支援存儲化合物類型，以及基于化合物類型的資料處理
（包括化學反應，分解等等）。
4. 運輸環節
小結一下，在危化品的運輸環節，使用傳感器對貨車、集裝箱内的危化品的名額進行實時的監控，使用流式資料庫pipelinedb流式的處理傳感器實時上報的資料；使用postgresql+postgis+pgrouting 對于貨車的形式路徑進行管理，繞開禁行路段、擁堵路段。
當出現事故時，使用postgresql的gis索引，快速的找出附近的應急救助資源（如交警、消防中隊、醫院、120）。
同時對危化品的貨物存儲，使用化學物類型存儲，可以對這些類型進行更多的限制和模拟的合成，例如可以發現化學反應，防止出現類似天津爆炸事件。
5. 消耗環節
增加剩餘量的監控，在閉環中起到很好的作用，達到供需平衡，避免供不應求，或者供過于求的事情發生。
6. 動态指揮中心
在給生産、倉庫、物流配送、消耗環節添加了終端、傳感器後，就建立了一個全面的危化品監管資料平台。 建構實時的監管全圖。
7. 緝毒、發現不法分子等
通過社會關系學分析，結合rdkit插件，在資料庫中存儲了人的資訊，存儲了人與化學物的關系（比如購買過），然後，根據社會關系學分析，将一堆的化合物（原材料）結合起來，看看會不會發生反應，生成毒品或危化品。
進而發現不法分子。
<a href="https://github.com/digoal/blog/blob/master/201612/20161228_01.md">《從天津濱海新區大爆炸、危化品監管聊聊 it人背負的社會責任感》</a>
人類是群居動物，随着人口的增長，聯絡方式越來越無界化，人與人，人與事件，人與時間之間形成了一張巨大的關系網絡。
有許多場景就是基于這張巨大的關系網絡的，比如。
1. 獵頭挖人
作為it人士或者獵頭、hr，對linkedin一定不陌生，領英網實際上就是一個維護人際關系的網站。
通過搜尋你的一度人脈，可以找到與你直接相關的人，搜尋2度人脈，可以搜尋到與你間接相關的人。
當然你還可以繼續搜尋n度人脈，不過那些和你可能就不那麼相關了。
如果你知道和美女範冰冰隔了幾度人脈，是不是有點心動了呢？
其實在古代，就有這種社會關系學，還有這種專門的職業，買官賣官什麼的，其實都是人脈關系網。看過紅樓夢的話，你會發現那家子人怎麼那麼多親戚呢？
2. 公安破案
公安刑偵學也是一類人脈相關的應用，隻是現在的關系和行為越來越複雜，這種關系也越來越複雜，原來的人能接觸的範圍基本上就靠2條腿，頂多加匹馬。
現在，手機，電腦，atm機，逾時，攝像頭，汽車等等，都通過公路網、網際網路連接配接在一起。
一個人的行為，産生的關系會更加的複雜，單靠人肉的關系分析，刑偵難度變得越來越複雜。
3. 金融風控
比如銀行在稽核貸款資格時，通常需要稽核申請人是否有償還能力，是否有虛假消息，行為習慣，資産，朋友圈等等。 同樣涉及到複雜的人物關系，人的行為關系分析等等。
圖檔來自網際網路
此類圍繞人為中心，事件為關系牽連的業務催生了圖資料庫的誕生。
目前比較流行的圖資料庫比如neo4j，等。
<a href="https://en.wikipedia.org/wiki/graph_database">https://en.wikipedia.org/wiki/graph_database</a>
postgresql是一個功能全面的資料庫，其中就有一些圖資料庫産品的背景是使用postgresql的，例如opencog， cayley等。
除了這些圖資料庫産品，postgresql本身在關系查詢，關系管理方面也非常的成熟，十億量級的關系網資料，3層關系運算僅需毫秒。
還可以用于運算人與人之間的最短關系，窮舉關系等。
主要用到的技術plpgsql服務端程式設計、異步消息、數組、遊标等。
<a href="https://github.com/digoal/blog/blob/master/201612/20161213_01.md">《金融風控、公安刑偵、社會關系、人脈分析等需求分析與資料庫實作 - postgresql圖資料庫場景應用》</a>
有一個這樣的場景，一張小表a，裡面存儲了一些id，大約幾百個到萬個。
（比如說巡邏車輛id，環衛車輛的id，公共汽車，微公交的id）。
另外有一張日志表b，每條記錄中的id是來自前面那張小表的，但不是每個id都出現在這張日志表中，比如說一天可能隻有幾十個id會出現在這個日志表的當天的資料中。
（比如車輛的行車軌迹資料，每秒上報軌迹，資料量就非常龐大，但是每天出勤的車輛有限）。
那麼我怎麼快速的找出今天沒有出現的id呢。
（哪些巡邏車輛沒有出現在這個片區，是不是偷懶了？哪些環衛車輛沒有出行，哪些公交或微公交沒有出行）？
select id from a where id not in (select id from b where time between ? and ?);
select a.id from a left join b on (a.id=b.aid) where b.* is null;
這個query會很慢，通常需要幾百秒到幾十秒，有什麼優化方法呢。
通過postgresql的遞歸查詢，可以高效的解決這個問題(在幾億記錄中篩選出與幾萬記錄的邏輯差集)。
優化後隻需要10毫秒左右。
<a href="https://github.com/digoal/blog/blob/master/201612/20161201_01.md">《用postgresql找回618秒逝去的青春 - 遞歸收斂優化》</a>
同樣的方法，還可以用于資料清洗與合并的場景，比如在物聯網的環境中，每個傳感器，每個小時會上報若幹條資料（有新增的，有更新的，有删除的名額等），對于同一個key，背景的應用程式隻關心最後一條記錄。
使用postgresql的遞歸收斂，每秒可以清洗或合并千萬量級的資料。
除了物聯網，同樣适用于資料庫之間的資料邏輯同步。
<a href="https://github.com/digoal/blog/blob/master/201611/20161128_01.md">《時序資料合并場景加速分析和實作 - 複合索引，視窗分組查詢加速，變态遞歸加速》</a>
在iot的場景中，有流式分析的需求，也有存儲曆史資料的需求，同時還有資料挖掘的需求，搜尋引擎可能也需要同一份資料，還有一些業務可能也要用到同一份資料。
但是如果把資料統統放到一個地方，這麼多的業務，它們有的要求實時處理，有的要求批量處理，有的可能需要實時的更新資料，有的可能要對大資料進行分析。
顯然一個産品可能無法滿足這麼多的需求。
就好比資料庫就分了關系資料庫，nosql，oltp場景，olap場景一樣。 也是因為一個産品無法滿足所有的業務需求。
在企業中通常是借助資料備援來解決各類場景的需求。
那麼如何才能夠更好的分享資料，保證資料的一緻性，提高分享的實時性呢？
10萬級别左右的機器，postgresql 的資料吞吐量可以達到100萬條/s以上，同時資料庫本身具備了嚴格的可靠性和一緻性保證。
postgresql為分享資料提供了插槽的概念，每個插槽對應一個目标端，支援斷點續傳，支援多個目标端。用于流式的分享資料是非常好的選擇。
<a href="https://github.com/digoal/blog/blob/master/201612/20161205_02.md">《實時資料交換平台 - bottledwater-pg with confluent》</a>
看刑偵劇經常有看到人物拼圖，然後到圖庫搜尋的，以前可能靠的是人肉，使用pg，可以靠資料庫的圖形近似度搜尋功能。
<a href="https://yq.aliyun.com/articles/58246">《弱水三千,隻取一瓢,當圖像搜尋遇見postgresql (haar wavelet)》</a>
而對于文本搜尋，大家一定會想到分詞，比如搜尋引擎、淘寶的商品内容搜尋、文章的關鍵字搜尋等等。
postgresql内置了分詞引擎，可以很好的滿足這類搜尋的需求。
<a href="https://github.com/digoal/blog/blob/master/201611/20161115_01.md">《聊一聊雙十一背後的技術 - 分詞和搜尋》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161019_01.md">《postgresql 全文檢索加速 快到沒有朋友 - rum索引接口(潘多拉魔盒)》</a>
<a href="https://github.com/digoal/blog/blob/master/201607/20160725_05.md">《postgresql 如何高效解決 按任意字段分詞檢索的問題 - case 1》</a>
但是千萬不要以為分詞可以搞定一切需求，比如這樣的需求就搞不定。
hello world打成了hello word或者hello w0rld，你要讓資料庫比對出來，怎麼搞？
又或者你的業務需要寫正則進行比對，怎麼搞？比如一些域名的查詢，<code>www.firefoxcn.org</code> 可能你隻想輸入其中的一個部分來搜尋，如果firefox可以比對。
甚至更變态的 fi[a-z]{1}e.*?.?? ，這樣的查詢。
資料量小，并發小時，這種查詢是可以忍受全表掃描和cpu處理過濾的。
但是想想一下，你是一個日請求過億的業務，或者資料量億級别的，全表掃描和cpu的開銷會讓你瘋掉的。
postgresql完美的解決了這類變态的需求。
1. 使用postgresql regexp庫，将正則轉換為nfa樣式（圖形化詞組）。
2. 将nfa樣式再進行轉換，轉換為擴充的圖形樣式(trigrams)，包括拆分後的查詢詞組與not詞組。
3. 簡化，過濾不必要的trigrams。
4. 打包為trgmpackedgraph結構，支援gin,gist索引的檢索。
<a href="https://github.com/digoal/blog/blob/master/201611/20161118_01.md">《聊一聊雙十一背後的技術 - 毫秒分詞算啥, 試試正則和相似度》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160506_02.md">《中文模糊查詢性能優化 by postgresql trgm》</a>
<a href="https://github.com/digoal/blog/blob/master/201603/20160302_01.md">《postgresql 百億資料 秒級響應 正則及模糊查詢》</a>
<a href="https://github.com/digoal/blog/blob/master/201603/20160307_01.md">《postgresql 1000億資料量 正則比對 速度與激情》</a>
還有一種場景，比如口音糾正、口音相似度搜尋。
在日常的生活中，我們可能會經常需要一些像相近、相仿、距離接近、性格接近等等類似這樣的需求，對資料進行篩選。
在postgresql中，這些場景都支援索引排序和檢索。
比如收集了人群的各種喜好的資料，通過對關聯資料的聚類分析，或者按喜好的重疊度進行排序，找出目标人群。
這裡就涉及到文本的近似度分析，postgresql的文本分析功能可以很好的支援此類場景。
<a href="https://github.com/digoal/blog/blob/master/201608/20160817_01.md">《postgresql 文本資料分析實踐之 - 相似度分析》</a>
秒殺在商品交易中是一個永恒的話題，從雙十一，到一票難求，比的僅僅是手快嗎？
其實對于交易平台來說，面對的不僅僅是人肉，還有很多腳本，外挂自動化的搶購系統，壓力可想而知。
秒殺的優化手段很多，就拿資料庫來說，有用排隊機制的，有用異步消息的，有用交易合并的。
今天我要給大家介紹一種更極端的秒殺應對方法，裸秒。
目前可能隻有postgresql可以做到裸秒，也即是說，來吧，一起上。
postgresql提供了一種ad lock，可以讓使用者盡情的釋放激情，以一台32核64線程的機器為例，每秒可以擷取、探測約130萬次的ad lock。
試想一下，對單條記錄的秒殺操作，達到了單機100萬/s的處理能力後，秒殺算什麼？100台機器就能處理1億/s的秒殺請求。
<a href="https://github.com/digoal/blog/blob/master/201611/20161117_01.md">《聊一聊雙十一背後的技術 - 不一樣的秒殺技術, 裸秒》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161018_01.md">《postgresql 使用advisory lock或skip locked消除行鎖沖突, 提高幾十倍并發更新效率》</a>
使用者畫像在市場營銷的應用重建中非常常見，已經不是什麼新鮮的東西，比較流行的解決方案是給使用者貼标簽，根據标簽的組合，圈出需要的使用者。
通常畫像系統會用到寬表，以及分布式的系統。
寬表的作用是存儲标簽，例如每列代表一個标簽，但是通常資料庫到2000個列基本就是極限了，上萬tag的話，隻能使用多表join來實作，效率較差。
另一方面，使用寬表(甚至列存儲)，标簽的篩選性能也比較差（無法達到實時級别）。
以postgresql資料庫為基礎，給大家講解一下更加另類的設計思路，以bit來存儲使用者，每行一個tag的方式。
10萬億級tag/users，毫秒級圈人。
<a href="https://github.com/digoal/blog/blob/master/201610/20161021_01.md">《基于 阿裡雲 rds postgresql 打造實時使用者畫像推薦系統》</a>
每年雙十一的交易額都創新高，今年也不例外，雙十一幾乎成了各種it系統的大考，物流也不例外。
每次雙十一快遞幾乎都被爆倉，但是随着技術的發展，今年，聽說雙十一剛過，小夥伴們的包裹都快收到了。
今天，來給大家分享一下物流與背後的資料庫技術，當然我講的還是postgresql, greenplum, postgis一類，大夥了解我的。
物流行業是被電子商務催生的産業之一。
快件的配送和攬件的排程算法是物流行業一個非常重要的課題，直接關系到配送或攬件的時效，以及物流公司的運作成本。
好的算法，可以提高時效，降低成本，甚至可以更好的調動社會資源，就像滴滴打車一樣，也許能全民參與哦。
以後也許上班路途還能順路提供快遞服務呢。
以物流行業為例，postgresql與greenplum為物流行業應用提供了包括機器學習、路徑規劃、地理位置資訊存儲和處理等基礎服務。
<a href="https://github.com/digoal/blog/blob/master/201611/20161114_01.md">《聊一聊雙十一背後的技術 - 物流、動态路徑規劃》</a>
傳統的金融行業高度依賴共享存儲來解決資料庫的高可用，資料0丢失以及異地容災的場景。
共享存儲的解決方案價格昂貴，對廠商的依賴較大。
postgresql基于同步流複制的 任意副本 解決方案，在解決0丢失，高可用以及容災的問題的同時，還可以提供隻讀的功能。相比傳統的存儲解決方案，優勢更加明顯。
<a href="https://github.com/digoal/blog/blob/master/201512/20151224_01.md">《postgresql 金融行業高可用和容災解決方案》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161006_02.md">《postgresql 9.6 同步多副本 與 remote_apply事務同步級别》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170101_01.md">《元旦技術大禮包 - 2017金秋将要釋出的postgresql 10.0已裝備了哪些核武器？》</a>
在物聯網、金融、日志類型場景中，資料持續不斷的産生，對于堆存儲來說，有線性相關的特點。
例如，時間字段往往和實體存儲的順序具有線性相關性。
例如，有一些自增字段，也和堆存儲的實體順序線性相關。
對與實體存儲線性相關的字段（時間，自增字段），postgresql提供了一種brin塊級範圍索引，索引中存儲了對應資料塊中的字段統計資訊（例如最大值，最小值，平均值，記錄數、sum，空值個數等）
這種索引很小，因為索引的粒度是連續的塊，而不是每條記錄。
通常比btree索引小幾百倍。
如果字段的線性相關性很好，進行範圍查詢或者精确檢索時，效率非常高。
對于統計查詢，也可以使用brin索引，提高分析統計的效率。
<a href="https://github.com/digoal/blog/blob/master/201604/20160414_01.md">《postgresql 物聯網黑科技 - 瘦身幾百倍的索引(brin index)》</a>
<a href="https://github.com/digoal/blog/blob/master/201504/20150419_01.md">《postgresql 9.5 new feature - brin (block range index) index》</a>
在營運商網關、物聯網的工業資料采集和處理，it系統的feed等業務場景中，資料産生的量非常龐大，這些資料要在保證可靠性的情況下，快速的入庫。
對于postgresql來說，使用中端x86伺服器(通常在10萬以内，32核，ssd+sata結合)上的資料插入速度（目标表包含一個brin索引），實際測試可以達到每天上百tb的寫入。
進而以較高的成本效益，滿足此類業務場景的需求。
<a href="https://github.com/digoal/blog/blob/master/201603/20160320_01.md">《postgresql 如何潇灑的處理每天上百tb的資料增量》</a>
在物聯網、金融、feed等場景中，往往有大批量的名額資料産生并進入資料庫，通常包含 時間、值 兩個字段。
這些資料由于量非常龐大，而且就像音頻一樣，實際上是可以對其進行有損的壓縮存儲的。
最為流行的是旋轉門的壓縮算法，在postgresql中可以使用udf，友善的實作這個功能。
進而實作流式\時序資料的有損壓縮。
<a href="https://github.com/digoal/blog/blob/master/201608/20160813_01.md">《旋轉門資料壓縮算法在postgresql中的實作 - 流式壓縮在物聯網、監控、傳感器等場景的應用》</a>
在很多場景中，使用者希望可以控制每個連接配接（會話）的資源使用情況，例如cpu\iops\memory等。
postgresql是程序結構，可以通過cgroup很好的實作這個需求，不需要對資料庫核心進行改造。
另一方面，基于postgresql的産品gpdb，則是在資料庫的核心層面實施的控制。
<a href="https://github.com/digoal/blog/blob/master/201607/20160727_01.md">《postgresql 會話級資源隔離探索》</a>
postgresql憑借良好的擴充性，不僅僅是一個資料庫，同時也是具備非常強大的資料處理能力的資料平台。
很多垂直行業的使用者拿它來做各種和業務貼合非常緊密的事情。
例如postgresql在生命科學領域的應用案例 - 基因工程。
通常的思維可能是這樣的，把資料存在資料庫，需要運算的時候，再把資料取出進行運算（例如配對），需要花費非常多的網絡傳輸時間。
postgresql提供了基因工程相關的資料類型，操作類型，索引。滿足基因工程業務的需求。
使用者可以直接在資料庫中對基因資料進行處理。同時還可以利用mpp來解決更大資料量的問題（例如壓縮後百tb級别）。
<a href="https://github.com/digoal/blog/blob/master/201606/20160621_1.md">《為了部落 - 如何通過postgresql基因配對，産生優良下一代》</a>
postgresql、以及hybriddb(基于gpdb)，等postgresql相關的資料庫，都支援madlib機器學習庫，這個庫支援機器學習領域常見的算法（例如聚類、線性回歸、貝葉斯、文本處理等等）
其中在資料領域用得較多的資料預測，可以使用madlib的多元回歸庫，進行資料的預測。
結合plr語言 或者r + pivotalr 、 python + pythonr插件，可以自動将r\python語言的指令轉換為madlib庫函數，對資料進行分析。
非常适合使用r或者python對資料進行分析的資料科學家使用。
其特點是高效（資料與運算一體，可以使用llvm\向量計算等技術優化，同時不需要傳播資料，節約了傳播的開銷）、易用（支援常見的sql、r, python等程式設計）。
<a href="https://github.com/digoal/blog/blob/master/201503/20150304_01.md">《postgresql 線性回歸 - 股價預測 1》</a>
<a href="https://github.com/digoal/blog/blob/master/201503/20150305_01.md">《在postgresql中用線性回歸分析linear regression做預測 - 例子2, 預測未來數日某股收盤價》</a>
在傳統企業、電商、營運商等涉及使用者互動、或者多個系統互動的業務場景中，通常一個事務涉及到很複雜的業務邏輯，需要保證資料的一緻性，同時還需要與資料庫多次互動。
比如 銀行開戶 ， 涉及的業務系統多，邏輯複雜。
在傳統企業中，通常使用商業資料庫的過程函數，實作此類複雜的邏輯。
postgresql的資料庫過程函數支援的語言非常豐富，比如plpgsql（可與oracle pl/sql功能比肩)，另外還支援語言的擴充，例如支援python,perl,java,c,r等等作為資料庫的過程函數語言。
對于開發人員來說，幾乎可以在postgresql資料庫中處理任何業務邏輯。
<a href="https://github.com/digoal/blog/blob/master/201605/20160505_01.md">《論雲資料庫程式設計能力的重要性》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170110_01.md">《postgresql 資料庫擴充語言程式設計 之 plpgsql - 1》</a>
在金融行業中，用得非常多的是嵌入式sql開發，可能為了處理複雜的邏輯，同時還需要非常高的效率、以及友善的代碼管理。
是以此類場景就會用到嵌入式sql開發，取代部分資料庫過程語言的代碼。
postgresql 的ecpg，與oracle的pro*c功能對齊，是個非常好的選擇。
<a href="https://www.postgresql.org/docs/9.6/static/ecpg.html">https://www.postgresql.org/docs/9.6/static/ecpg.html</a>
postgresql 從 2011年的9.1版本引入fdw開始，發展到現在已經支援幾乎所有的外部資料源讀寫操作，例如mysql,oracle,pgsql,redis,mongo,hive,jdbc,odbc,file,sqlserver,es,s3,......。
<a href="https://wiki.postgresql.org/wiki/fdw">https://wiki.postgresql.org/wiki/fdw</a>
開放的接口，允許使用者自己添加外部資料源的支援。
9.6針對postgres_fdw（即postgresql外部資料源）再次增強，開始支援對sort, where, join的下推，支援remote cancel query, 使用者使用fdw可以對應用透明的實作資料庫的sharding，單元化需求。
核心層支援sharding，這種分片技術相比中間件分片技術的好處：
1. 支援跨庫join
2. 支援綁定變量
3. 支援master(coordinator)節點水準擴充
4. 支援segment(datanode)節點水準擴充
5. 支援函數和存儲過程
6. 支援sort, where, join的下推，支援remote cancel query，10.x支援聚合算子的下推。
ps: 目前還不支援分布式事務（需要使用者幹預2pc） ，10.x的版本會增加核心層面的分布式事務控制。
<a href="https://github.com/digoal/blog/blob/master/201610/20161004_01.md">《postgresql 9.6 單元化,sharding (based on postgres_fdw) - 核心層支援前傳》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161005_01.md">《postgresql 9.6 sharding + 單元化 (based on postgres_fdw) 最佳實踐 - 通用水準分庫場景設計與實踐》</a>
除了postgres_fdw，postgresql還有很多fdw，也就是說，你可以在postgresql資料庫中，通路幾乎任何外部資料。就像通路本地的表效果一樣。
在lbs、社交、物流、出行、導航等場景中，最為常見的一個需求是基于位置的搜尋，比如搜尋附近的人，并按距離由近到遠排序。
在postgresql中，有專門的gist, sp-gist索引支援，可以做到非常高效的檢索，100億地理位置資料，查詢某個點附近的點，普通硬體，單個資料庫響應時間在1毫秒以内。
postgresql在位置資訊近鄰（knn）查詢方面的性能參考。
<a href="https://github.com/digoal/blog/blob/master/201601/20160119_01.md">《postgresql 百億地理位置資料 近鄰查詢性能》</a>
毫無疑問，oracle在企業市場的份額依舊是老大哥的地位，市面上也有很多資料庫對這塊市場虎視眈眈。
擁有43年開源曆史的postgresql資料庫，是目前與oracle相容最為完美的資料庫。業界也有許多非常成功的案例。
比如 豐田汽車、平安銀行、郵儲銀行 等。
相容性細節請參考
<a href="http://vschart.com/compare/oracle-database/vs/postgresql">http://vschart.com/compare/oracle-database/vs/postgresql</a>
<a href="https://wiki.postgresql.org/wiki/oracle_to_postgres_conversion">https://wiki.postgresql.org/wiki/oracle_to_postgres_conversion</a>
<a href="https://www.postgresql.org/about/featurematrix/">https://www.postgresql.org/about/featurematrix/</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170217_02.md">《oracle 遷移至 postgresql 文檔、工具大集合》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170302_01.md">《postgresql oracle 相容性之 - ratio_to_report 分析函數》</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170228_01.md">《postgresql oracle 相容性之 - sql outline插件sr_plan (儲存、篡改、固定 執行計劃)》</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170217_01.md">《postgresql oracle 相容性之 - 函數、類型、多國語言》</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170207_01.md">《postgresql oracle 相容性之 - 核心自帶的相容函數》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161219_01.md">《oracle log file parallel write 等待事件分析 - postgresql的wal異曲同工》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161104_01.md">《postgresql oracle 相容性之 - plpgsql 自治事務(autonomous_transaction)更新檔》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161018_04.md">《postgresql oracle 相容性之 - pl/sql forall, bulk collect》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160921_02.md">《postgresql oracle 相容性之 - 字元編碼轉換 convert》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160921_01.md">《postgresql oracle 相容性之 - compose , unistr , decompose》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160920_06.md">《postgresql oracle 相容性之 - bit_to_num , bitand , 比特運算 , 比特與整型互相轉換》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160920_05.md">《postgresql oracle 相容性之 - asciistr》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160920_03.md">《postgresql oracle 相容性之 - tz_offset》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160920_02.md">《postgresql oracle 相容性之 - new_time , sys_extract_utc》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160920_01.md">《postgresql oracle 相容性之 - remainder》</a>
<a href="https://github.com/digoal/blog/blob/master/201607/20160725_04.md">《postgresql oracle 相容性之 - 鎖定執行計劃(outline system)》</a>
<a href="https://github.com/digoal/blog/blob/master/201607/20160714_01.md">《postgresql oracle 相容性之 - pl/sql record, table類型定義》</a>
<a href="https://github.com/digoal/blog/blob/master/201606/20160617_02.md">《為什麼用 postgresql 綁定變量 沒有 oracle pin s 等待問題》</a>
<a href="https://github.com/digoal/blog/blob/master/201606/20160614_03.md">《postgresql oracle 相容性之 - connect by》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160527_01.md">《postgresql oracle 相容性之 - 如何篡改插入值(例如null纂改為其他值)》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160507_01.md">《postgresql oracle 相容性之 - add_months》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160503_01.md">《postgresql oracle 相容性之 - psql prompt like oracle sql*plus》</a>
<a href="https://github.com/digoal/blog/blob/master/201603/20160318_01.md">《postgresql oracle 相容性之 - pl/sql pipelined》</a>
<a href="https://github.com/digoal/blog/blob/master/201603/20160315_01.md">《postgresql oracle 相容性之 - sys_guid() uuid》</a>
<a href="https://github.com/digoal/blog/blob/master/201602/20160204_01.md">《postgresql oracle 相容性之 - wm_sys.wm_concat》</a>
<a href="https://github.com/digoal/blog/blob/master/201602/20160203_03.md">《enterprisedb & postgresql rls & oracle vpd》</a>
<a href="https://github.com/digoal/blog/blob/master/201602/20160203_02.md">《postgresql oracle 相容性之 - 函數 自治事務 的寫法和實作》</a>
<a href="https://github.com/digoal/blog/blob/master/201512/20151221_02.md">《postgresql oracle 相容性之 - with 遞歸 ( connect by )》</a>
<a href="https://github.com/digoal/blog/blob/master/201512/20151221_01.md">《postgresql oracle 相容性之 - orafce介紹》</a>
<a href="https://github.com/digoal/blog/blob/master/201507/20150703_01.md">《postgresql oracle 相容性之 - orafce (包、函數、dual)》</a>
<a href="https://github.com/digoal/blog/blob/master/201504/20150429_01.md">《postgresql oracle 相容性之 - 事件觸發器實作類似oracle的資源回收筒功能》</a>
<a href="https://github.com/digoal/blog/blob/master/201206/20120606_01.md">《postgresql 函數封裝 - wrap function code like oracle package》</a>
<a href="https://github.com/digoal/blog/blob/master/201505/20150526_02.md">《postgresql oracle 相容性之 - support grouping sets, cube and rollup.》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170125_01.md">《資料庫界的華山論劍 tpc.org》</a>
<a href="https://github.com/digoal/blog/blob/master/201601/20160109_01.md">《benchmarksql 測試postgresql 9.5.0 tpc-c 性能》</a>
<a href="https://github.com/digoal/blog/blob/master/201512/20151223_02.md">《benchmarksql 測試oracle 12c tpc-c 性能》</a>
postgresql 的開源許可非常友好，開發者遍布世界各地，各個行業，這也是postgresql資料庫使用者行業覆寫面非常廣的原因之一。
<a href="https://wiki.postgresql.org/wiki/development_information">https://wiki.postgresql.org/wiki/development_information</a>
<a href="https://en.wikipedia.org/wiki/postgresql">https://en.wikipedia.org/wiki/postgresql</a>
postgresql 社群的核心研發實力非常強大，在功能方面一直引領開源資料庫。
開發節奏非常好，每年釋出一個大版本，每個大版本都可以看到許多前沿的大特性。
<a href="https://commitfest.postgresql.org/">https://commitfest.postgresql.org/</a>
postgresql 使用者組也非常活躍，幾乎全年無休世界各地都能看到postgresql使用者組的活動。
<a href="https://www.postgresql.org/about/events/">https://www.postgresql.org/about/events/</a>
postgresql 的外圍生态也非常的活躍，這也得益于友好的開源許可。比如 :
衍生産品
gpdb, greenplum, hawq, aws redshift, 許多國産資料庫, postgres-xc, postgres-xl, asterdata、matrixdb、paraclle、illustra, informix, netezza、edb、pipelinedb、postgres-xz
外圍送出的特性
llvm、向量化執行引擎、列存儲、記憶體引擎、圖資料處理、指紋資料處理、化學資料處理、生物資料處理 等。
外圍送出的插件
塊級增量備份、raft協定與pg的多副本整合、邏輯複制、近似度搜尋插件、等待事件采樣、網格化插件、分布式插件 等。
不完全名單
生物制藥 {affymetrix(基因晶片), 美國化學協會, gene(結構生物學應用案例), …}
電子商務 { cd baby, etsy(與淘寶類似), whitepages, flightstats, endpoint corporation …}
學校 {加州大學伯克利分校, 哈佛大學網際網路與社會中心, .lrn, 莫斯科國立大學, 悉尼大學, 武漢大學, 人民大學, 上海交大, 華東師範 …}
金融 {journyx, llc, trusecommerce(類似支付寶), 日本證券交易交所, 郵儲銀行, 同花順, 平安科技…}
遊戲 {mobygames, 斯凱網絡 …}
政府 {美國國家氣象局, 印度國家實體實驗室, 聯合國兒童基金, 美國疾病控制和預防中心, 美國國務院, 俄羅斯杜馬, 國家電網, 某鐵路運輸…}
醫療 {calorieking, 開源電子病曆項目, shannon醫學中心, …}
制造業 {exoteric networks, 豐田, 捷豹路虎}
媒體 {imdb.com, 美國華盛頓郵報國會投票資料庫, macworld, 綠色和平組織, …}
開源項目 {bricolage, debian, freshports, flpr, lamp, postgis, sourceforge, openacs, gforge …}
零售 {adp, ctc, safeway, tsutaya, rockport, …}
科技 {gitlab, sony, myspace, yahoo, afilias, apple, 富士通, omniti, red hat, sirius it, sun, 國際空間站, instagram, disqus, aws redshift, 阿裡巴巴, 去哪兒, 騰訊, 華為, 中興, 雲遊, 智聯招聘, 高德, 餓了麼 …}
通信 {cisco, juniper, ntt(日本電信), 德國電信, optus, skype, tlestra(澳洲電訊), 某營運商…}
物流 {第一物流}
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_05.md">《postgresql java tutorial》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_06.md">《postgresql python tutorial》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_07.md">《postgresql ruby tutorial》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_08.md">《postgresql php tutorial》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170106_09.md">《postgresql c tutorial》</a>
<a href="http://go-database-sql.org/index.html">《postgresql go tutorial 1》</a>
<a href="https://godoc.org/github.com/lib/pq">《postgresql go tutorial 2》</a>
适應廣泛的行業與業務場景
gis, 物聯網, 網際網路, 企業, erp, 多媒體, ......
tp + ap
單庫 20 tb 毫無壓力
要求主備嚴謹一緻的場景不二之選
<a href="https://github.com/digoal/blog/blob/master/201609/20160929_02.md">《postgresql 前世今生》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160926_01.md">《postgresql 資料庫開發管理規範》</a>
<a href="https://github.com/digoal/blog/blob/master/201701/20170120_01.md">《postgresql 特性小故事》</a>
postgresql 比較鮮明的特性表述
如果把玩轉資料庫比作打怪更新，打小怪或者普通怪物适合賺經驗更新，打bose則有更多的幾率爆出更多的裝備或者寶貝，等級低的時候打小怪也能賺經驗，等級高的時候就必須打等級高的怪物，否則打小怪可能永遠都升不了級。
postgresql就是遊戲裡等級高的怪物，甚至是bose級别的怪物。
如果你看鬥破蒼穹的話，則可以把postgresql當成你的煉藥師，它可以陪伴你從低段位快速的提升到高段位。
圍繞在postgresql身邊的生态非常之龐大，當你的能力越來越強，視野越來越廣闊，對業務，對行業越來越了解的話，你可以玩得越來越轉。
當你玩轉它的時候，就不是資料庫玩你了，你可以讓pg陪你一起玩。
<a href="https://github.com/digoal/blog/blob/master/201606/20160626_01.md">《找對業務g點, 體驗酸爽 - postgresql核心擴充指南》</a>