在資料庫中用得最多的當屬btree索引，除了btree，一般的資料庫可能還支援hash, bitmap索引。
但是這些索引到了物聯網，會顯得太重，對性能的損耗太大。
為什麼呢？
物聯網有大量的資料産生和入庫，入庫基本都是流式的。在使用這些資料時，基本是fifo，或者範圍查詢的批量資料使用風格。
btree索引太重，因為索引需要存儲每條記錄的索引字段的值和尋址，使得索引非常龐大。
另一方面，物聯網的大量範圍查詢和批量處理用法決定了它不需要這麼重的索引。
例子：
如下所示，btree索引的空間占比是非常大的。
除了大以外，btree索引同時也會影響資料的更新，删除，或插入的性能。
有btree索引, 每秒入庫28.45萬行
無索引, 每秒入庫66.88萬行
從上面的介紹和測試資料，可以明顯的看出btree索引存在的問題：
體積大，影響性能。
接下來該讓postgresql黑科技登場了：
範圍索引，術語brin, block range index.
範圍索引的原理，存儲連續相鄰的block的統計資訊（min(val), max(val), has null? all null? left block id, right block id )。
例如一個表占用10000個block，建立brin index 時，指定統計每128個block的統計資訊，那麼這個索引隻需要存儲79份統計資訊。
空間占用非常的小。
解決了空間的問題，還需要解決性能的問題，我們測試一下，在建立了brin索引後，插入的性能有多少？
範圍索引, 每秒入庫62.84萬行
最後還需要對比一下 btree, brin 索引的大小，還有查詢的性能。
索引大小比拼：
表 4163mb
btree索引 2491 mb
brin索引 4608 kb
查詢性能比拼 :
範圍查詢
全表掃描 11 秒
範圍索引 64 毫秒
btree索引 24 毫秒
精确查詢
全表掃描 8 秒
範圍索引 39 毫秒
btree索引 0.03 毫秒
對比圖 :
小結：
.1. 範圍索引重點的使用場景是物聯網類型的，流式入庫，範圍查詢的場景。 不僅僅對插入的影響微乎其微，而且索引大小非常的小，範圍查詢的性能和btree差别微乎其微。
.2. 結合json和gis功能，相信postgresql會在物聯網大放異彩。
ps: oracle 也有與之類似的索引，名為storage index. 但是隻有exadata産品裡有，貴得離譜，屌絲繞道。哈哈。
<a href="https://docs.oracle.com/cd/e50790_01/doc/doc.121/e50471/concepts.htm#sagug20984">https://docs.oracle.com/cd/e50790_01/doc/doc.121/e50471/concepts.htm#sagug20984</a>
dba應該具備抓住各種資料庫的特性，并且将這種特性應用到适合的場景中去的能力。資料庫與dba的角色用千裡馬和伯樂來形容好像也不為過。
小夥伴們一起來玩pg吧，社群正在推oracle dba 7天速成pg的教程，敬請期待。