在物聯網應用場景中，有大量的傳感器，會産生非常大量的消息以極高的并發進入資料庫。
這些資料如果直接進入面向olap場景設計的資料倉庫，資料實時入庫會成為瓶頸，并且olap系統很難接受非常高并發的請求。
面對這樣的應用場景，這些既要又要還要怎麼滿足呢？
.1. 既要實時入庫，
.2. 又要實時分析，
.3. 還要曆史留檔，應對随時變化的分析需求。
實時入庫比較容易滿足，我前些天寫過一篇 "postgresql 如何潇灑的處理每天上百tb的資料增量"
<a href="https://yq.aliyun.com/articles/8528">https://yq.aliyun.com/articles/8528</a>
實時分析也比較好滿足，我前些天寫過一篇 "postgresql "物聯網"應用 - 1 實時流式資料處理案例(萬億每天)"
<a href="https://yq.aliyun.com/articles/166">https://yq.aliyun.com/articles/166</a>
曆史留檔，應對随時變化的分析需求。這一點的需求其實也非常簡單，其實就是在滿足了前面兩點後，把資料load到olap系統。
但是不要小看這個非常簡單的操作，做到實時性，一緻性是非常關鍵的。
一般的做法存在的gap問題(一緻性問題)
gap問題可解，例如通過快照或者單線程來解，太low了。
以前寫過關于解gap問題的一系列文章：
gap問題出現的原因,用一張圖來表示：
簡單來說，就是讀取資料的事務快照把一些未送出，但是序列或時間靠前的記錄屏蔽了。下次再讀取時就會産生gap，實時性越高，産生gap的機率越高。有gap，oltp和olap系統的資料就會不一緻。
傳統的解決這個問題的辦法：
.1. 延遲同步，例如同步一個小時前的資料，來減少gap。
.2. 串行插入，資料串行插入，不存在gap。
.3. 在記錄中添加一個xid字段，記錄資料插入的事務号；讀取資料時通過事務快照，記錄未送出的事務xid；下次再次讀取資料時，根據快照中表示未結束事務的xid，以及行上的xid找到這些gap記錄。
不用多說，前面幾種方法，都有一定的弊端。
要解決實時性問題，又要高逼格。
postgresql的閱後即焚完美的解決了以上問題，可以完美的實作并發性，一緻性，實時性。
并發指并發的插入和并發的讀取；
一緻性指資料進去n條，出去一定是n條；
實時性，指資料可以實時|流式的取走，不需要設間隔；
閱後即焚的文法很簡單，例子：
閱後即焚：
下面進行并發測試，
驗證一緻性，實時性，并發性：
并發插入2小時：
并發閱後即焚2小時：
驗證插入和閱後即焚的記錄數一緻。
性能名額(64張表并發測試寫入和閱後即焚的性能名額)：
插入: 230萬行/s
閱後即焚: 384萬行/s
這種技術在其他應用場景的使用：
.1. 延遲确認，在短信确認的應用中非常常見，如訂閱一個營運商的業務，一般會收到二次确認的短信。
服務端會向資料庫插入一條記錄，然後等待使用者回報，回報後更新之前插入的那條記錄的狀态。
.2. 相關的用法(oracle也支援這種用法) :
擴充閱讀：
"postgresql 如何潇灑的處理每天上百tb的資料增量"
"postgresql "物聯網"應用 - 1 實時流式資料處理案例(萬億每天)"
postgresql的其他特性也非常的适合物聯網：
json支援, gis支援, 視窗查詢, 樹形查詢, 輕資料分析, 範圍類型, 範圍索引 等等。