知識星球導語： 物聯網是新一代資訊科技的重要組成部分，也是“資訊化”時代的重要發展階段。對於物聯網來說，時序資料庫是滿足其需求的基礎設施之一。本文作者分析了物聯網資料庫的一般需求，並且結合PostgreSQL實現了自己的時序資料庫TimescaleDB。本文是作者對TimescaleDB設計和實現的簡要介紹。
PostgreSQL是如何突然成為了物聯網應用程式和服務的理想平臺。
註:這是基於我們2月份印度PGConf主題演講(完整影片)[1]。今年5月，我們將在物聯網世界[2]發表類似的演講。(我們現在正在澤西城的PostgresConf——來打個招呼吧!)[3]
像時尚和音樂潮流一樣，計算跟隨著潮流不斷演進。(或者你更加喜歡用軟體開發的語言來比喻:計算透過大大小小的版本迭代發展和演進。)
從大型機（1950-1970）到個人電腦（80-90年代），再到智慧手機（2000-現在），每一次浪潮都帶給我們更小，卻更強大的機器，在商業和社會中日益豐富和普及。
我們現在正處在另一個關鍵點的風口浪尖上，計算裝置如此之小，如此普遍，以至於它變得幾乎像我們呼吸的空氣一樣普遍。有人稱之為“物聯網”、“聯網裝置”或“普適計算”。
隨著每個潮流的出現，軟體開發者和企業都在努力尋找合適的軟體基礎設施來開發他們的應用程式，很快像Unix，windows，LAMP技術棧，ios/android的常見的平臺出現。
今天基於物聯網的應用開發者正在問自己一個重要的問題：新的服務應該採用什麼什麼樣的合適的基礎設施呢？
現在聲稱某個物聯網服務的平臺獲勝還為時過早，但不管它是什麼，我們相信它的底層結構，它的基礎資料層，將是Postgres。
下麵介紹為什麼這麼說。
物聯網資料的詳細探查
流行的科幻小說通常描繪的是充滿機器的未來。
但事實證明，機器已經包圍了我們，事實上，去年是連線裝置（不包括電腦和智慧手機）在數量上超過人類數量的第一年。
因此，大量的機器（或物聯網）資料已出現在越來越多的地方：
-
工業機器：製造我們大部分的東西。
-
運輸和物流：我們周圍的人和物品是如何轉移的。
-
建築管理和智慧家居：我們如何生活和保護我們的家和企業
-
農業：我們如何養活這個星球
-
能源與公共事業：我們如何為我們的世界提供動力
-
(還有更多)
但是機器資料是什麼？讓我們看一個簡單的例子：
這裡有來自三個資料源的資料：一個建築物，一個農場和一個工廠。資料按時間排序定期到達。當一個新的資料點出現，我們將它加到現有的資料集中。
如你所見，當我們收集機器資料，我們建立一個時間序列資料集[4]。
讓我們用另外一個例子深入瞭解一些：
這裡我們看到資料集是一組隨時間收集的資料。同樣，資料集本質上是時間序列的。
但是也有一些額外的元資料描述這些測量的來源(無論是感測器、裝置還是其他“物體”)。如果我們仔細觀察，看來每次閱讀中記錄的元資料看起來都是相關的。實際上，可以很容易地將資料集規範化，每一行都包含了分隔元資料表的外來鍵。(在我們的示例中，我們可以建立額外的“裝置”、“位置”或甚至“維護”表)。
換句話說，物聯網資料是時間序列和關係資料的組合。關係資料只是描述生成時間序列的東西。
這表明對於物聯網我們可能需要一個類似Postgres的關係資料庫。
為什麼物聯網選用Postgres？
為物聯網選擇Postgres[5]有很多理由：
-
關係模型+JOINs: 正如我們剛才看到的，關係模型非常適合於物聯網。
-
可靠性: 數十年的軟體開發和生產部署導致了一個堅如磐石的資料庫。
-
易用性: 開發人員和業務分析人員已經知道如何使用的查詢語言(SQL)，以及dba已經知道如何操作的資料庫。
-
廣泛的生態系統:最大的相容視覺化工具的生態系統，後端系統，操作實用工具(例如，備份，複製)，等等。
-
靈活的資料型別(包括JSON):一組廣泛的資料型別，包括(但不限於)數字、字串、陣列、JSON/JSONB。
-
地理空間支援:透過PostGIS[6]，增加了對地理物件和位置特定查詢的支援。
-
趨勢:Postgres可能是目前所有開源資料庫中最強大的一個(這就是為什麼資料庫引擎被命名為Postgres，它是2017年的頂級資料庫管理系統[7])。
但是為什麼Postgres目前沒有被用於物聯網?
有些人已經開始使用Postgres。如果您的寫入速度很低，並且只儲存了幾百萬行時間序列資料，Postgres可能會滿足您的需求。
Postgres不是這些應用服務預設的資料庫的一個主要原因是：它不具備良好的擴充套件性。
隨著資料集的增長，插入效能急劇下降。(插入吞吐量作為PostgreSQL 9.6.2的表大小的函式，在Azure標準DS4 v2(8核)機器上執行10個工作執行緒，使用基於ssd的(高階LRS)儲存。)
物聯網工作負載通常具有高插入率，從而導致大型資料集。正如上圖所示，隨著資料集的增長，在Postgres上插入效能急劇下降，這就不太合適了。
這個下降反應了記憶體超過一定的大小，資料和索引不再適合存放在記憶體裡，需要Postgres進行磁碟交換。(這裡不再更多解釋[8]。)
(事實證明Postgres 10也沒有解決這個問題[9]。)
那麼，如何在保留所有好處的同時，為物聯網資料提供一個可擴充套件的Postgres呢?
我們作為物聯網平臺的前身
對於我們來說，為物聯網的工作負載擴充套件Postgres不僅僅是一個學術問題，而且是我們公司在以前所面臨的一個實際問題。
早期版本的TimescaleDB。
我們公司最初是從iobeam，一個物聯網資料分析平臺開始的。我們取得了一定的成功，為我們的客戶收集了大量的機器時間序列和關係資料。我們需要把資料儲存在某個地方。
然而，我們發現當時業界資料庫只提供兩種選擇:
-
關係資料庫(例如PostgreSQL, MySQL)是可靠的、易於使用和效能的，但是伸縮性很差。
-
非關係型(也稱為“NoSQL”)資料庫(例如Cassandra, InfluexDB)，它的伸縮性更好，但不可靠，效能更差，更難以使用，也不支援關係資料。
但是鑒於我們的物聯網工作負載由時間序列和關係資料組成，我們唯一的選擇是同時使用兩種資料庫。這導致了其他問題：它將我們的資料集分割成孤島，導致應用層需要做複雜的連線，並要求我們維護和操作兩個不同的系統。
我們真正想要的是彙集兩種資料庫的最好部分:一些像Postgres一樣工作的東西，但卻能達到時序資料庫的可擴充套件性。鑒於我們的工程團隊是由普林斯頓大學的電腦科學教授[10]領導的，我們決定自研。
然後，在聽取了許多面臨同樣問題的開發人員的意見後，我們從物聯網平臺轉向開源的時間序列資料庫公司，並於2017年4月[11]推出了該產品，並且在2018年1月[12]融資了1600萬美元來擴大業務。
針對物聯網擴充套件Postgres
對於物聯網的工作負載，我們是如何擴充套件Postgres的：
-
我們確定了主要的瓶頸:資料集的記憶體/磁碟交換時間。
-
然後我們認識到時間序列的工作負載與傳統的資料庫(或OLTP)工作負載有非常不同的特性:
正如我們所看到的，傳統的資料庫工作負載傾向於對隨機位置進行更新，而更新通常需要複雜的事務。
這裡的典型的銀行賬戶轉賬為例子:如果Alice傳送Bob 10美元,那麼資料庫需要自動為借方和貸方兩個無關的其他賬戶記錄。
但是，另一方面，時間序列的工作負載往往是插入頻繁的，主要是順序的，具有簡單的事務。我們還是以上文的銀行轉賬為例子:插入一行，表示從Alice到Bob的$10轉賬，時間戳則是現在。
洞察# 1:合適大小的分塊
我們可以根據時間來劃分資料，這樣每個分割槽或資料塊都是合適大小的，這樣的話可以使得所有的資料和索引都能在記憶體中執行。如果大小劃分的恰到好處的話，記憶體磁碟間的資料交換將被最小化(或者即使是最近的或“熱”的塊也會被消失)。
但是，當資料嚴重分割槽時，會導致其他挑戰：管理這些分割槽，跨分割槽邊界查詢（通常需要複雜的JOIN），插入正確的分割槽，根據需要建立新的分割槽等。這可能是一個令人頭痛的問題。
洞察#2：Hypertable
Hypertable，跨所有分割槽的單個虛擬表，它執行起來就像一個普通的Postgres表，並隱藏了使用者的所有複雜性。
從Hypertable中查詢資料，它將會很好地識別包含資料的正確分割槽;將資料寫入Hypertable，它會將元組路由到適當的分割槽(併在必要時建立新的分割槽);建立索引/約束/觸發器，管理您的樣式，所有這些都在Hypertable表級別，所有更改都將傳播到對應的塊。
現在，Hypertable的介面應該是什麼樣的呢?一開始我們嘗試建立自己的查詢語言。但是隨後我們對這種方法的不切實際性感到震驚：我們必須為每個視覺化工具，後端元件等建立全新的驅動，更不用說必須教育整個開發人員群體。
洞察# 3:支援SQL
但後來我們意識到有一條更簡單的方法:支援SQL。每個人都知道SQL，有很多關於如何使用SQL查詢的文獻，還有大量的介紹SQL的資料和工具。對於目前不適合用來進行時間序列分析的SQL(和PostgresSQL)，可以透過udf和查詢-計劃/查詢-執行級別的最佳化來輕鬆地改進。(這有一些例子[13]。)
然後我們更進一步，透過把我們的工作打包成Postgres擴充套件。因此，現在任何與Postgres(例如視覺化工具、管理工具、備份/恢復實用工具、資料基礎元件等)相關的工具，都可以使用我們的新時間序列資料庫。
在高層次上，這是我們構建的表徵模型:
當然，問題的關鍵在於細節:塊管理、可識別的查詢、快速的元資料路由，執行Hypertable-as-a-vanilla-table保證還需要在C和PL/pgSQL級別上進行大量工作以獲得正確的結果(檢視更多[14])。
我們的結果:20x更高的插入，2000x更快的刪除，1.2x- 14000x更快的查詢
可以從結果中看到這種架構的好處:
TimescaleDB可以支援每秒100k +行插入，或者每秒1M + metrics/秒。
我們的方法可以獲得比普通Postgres高達10,000倍的查詢速度和2000倍的快速刪除
此外，由於這個體系結構，我們能夠將一個Hypertable擴充套件到數十TB，同時在一個節點上實現每秒成千上萬個插入。(更多關於我們的基準 vs Postgres和vs Postgres 10。[15])
這個設計也讓我們保留了之前列出的Postgres的所有好處:
-
關係模型+Joins：Hypertable和關係表共存
-
可靠性、易用性、生態系統:我們的設計不會影響底層儲存層，並且保持同樣的SQL語法，所以它的操作就像和使用Postgres感覺一樣。
-
靈活的資料型別(包括JSON)、地理空間支援:類似地，這種方法與所有Postgres原生資料型別和擴充套件(如PostGIS)保持相容。
-
趨勢:作為一個擴充套件，設計與Postgres相相容，並將繼續受益於Postgres的持續改進(也允許我們回饋社群)。
意外的物聯網平臺?
現在我們可以為物聯網擴充套件Postgres，我們還可以在Postgres之上選擇使用各種應用程式和工具:例如，Kafka、RabbitMQ、MQTT、Apache Spark、Grafana、Tableau、Rails、Django等等。
換句話說,即使Postgres是一個數十年的開源專案, 它已經不小心成為物聯網的理想平臺和成為計算的下一波潮流。
如果瞭解我們的歷程是有幫助的，歡迎你用同樣的方法擴充套件自己Postgres。但是如果你更想節省時間，你也可以使用TimescaleDB[16](開源，Apache 2)。這是您的選擇。我們在這可以提供幫助[17]。
參考連結：
[1] https://www.youtube.com/watch?amp=&v;=sFHZJ61DmZk
[2] https://tmt.knect365.com/iot-world/speakers/ajay-kulkarni#developers-conference-security-data-ai_the-inadvertent-iot-platform-postgresql
[3] https://twitter.com/TimescaleDB/status/986605501424259073
[4] https://blog.timescale.com/what-the-heck-is-time-series-data-and-why-do-i-need-a-time-series-database-dcf3b1b18563
[5] https://blog.timescale.com/choose-postgresql-for-iot-19688efc60ca
[6] http://postgis.net
[7] https://db-engines.com/en/blog_post/76
[8] https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c
[9] https://blog.timescale.com/time-series-data-postgresql-10-vs-timescaledb-816ee808bac5
[10] http://www.timescale.com/about
[11] https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2
[12] https://blog.timescale.com/raised-16m-from-benchmark-nea-to-understand-machines-time-series-data-iot-9eff8213c15c
[13] http://docs.timescale.com/v0.9/api#analytics
[14] https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c
[15] https://blog.timescale.com/timescaledb-vs-6a696248104e
[16] https://github.com/timescale/timescaledb
[17] http://slack-login.timescale.com
活動預告：
6 月 1 ~ 2 日，GIAC 全球網際網路架構大會將於深圳舉行。GIAC 是高可用架構技術社群推出的面向架構師、技術負責人及高階技術從業人員的技術架構大會。今年的 GIAC 已經有騰訊、阿裡巴巴、百度、今日頭條、科大迅飛、新浪微博、小米、美圖、Oracle、鏈家、唯品會、京東、餓了麼、美圖點評、羅輯思維、ofo、LinkedIn, Pivotal 等公司專家出席。
本期 GIAC 大會上，IOT部分精彩的議題如下：
參加 GIAC，盤點2018最新技術。點選“閱讀原文”瞭解大會更多詳情。
