空間統計的幾點想法

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1. 背景

         在上一篇博客中提到了用ES來作搜索和統計，多個同行留言提醒用PG效率也能夠很不錯。本身查了些資料和文章，尤爲是博友「遙想公瑾當年」一些列關於PG的文章，受益不淺。綜合公司目前的實際狀況，總結幾點想法。

       因爲公司項目太廣（每一年大於500個項目現場在實施、維護），對於數據庫和地理服務器根據甲方現場環境很難統一要求，按地理服務器主要分爲：ArcGIS、SuperMap、Geoserver；按數據庫主要分爲：Oracle、Mysql、Postgresql。介於此，咱們以前將空間分析等邏輯經過適配三大地理服務器（OGC標準）來完成各項目的兼容，缺乏直接對數據庫層面的操做。經過開發一些維護工具來進行統計類業務的預處理。

　　考慮到實時（或僞實時）空間統計的需求愈來愈多，將目標轉向數據庫層面是一個必然的趨勢。尤爲是如今數據庫對於空間索引、各種座標系的普遍支持，其穩定性、規避傳輸層問題、效率等都有明顯優點。

2. 採用PG進行統計

       a.首先要解決PG能通用於全部項目，能夠提出項目實施規範，基於docker快速搭建PG環境。在甲方採購用Oracle等數據庫時，依然基於規範要求必須部署PG以存儲空間數據（業務數據可依然存放於Oracle）。

       b.基於區劃信息統計通常分爲網格、社區、街道、區、市等等。按照GIST索引的特性（類R樹索引），其要素的四角範圍對索引性能影響特別大。對於大範圍查詢，將大範圍切分爲小範圍能夠很是明顯的優化查詢效率。這裏，咱們直接採用網格做爲查詢單元，經過網格查詢結果構造社區、街道、區的查詢結果，則會效率更好。

       c.空間數據來源於多種SHP數據，爲了便於數據檢索、查詢、和效率的優化，設計空間信息目錄表（資源關鍵信息整合表），基於該表進行統一的空間查詢。

以2300個網格和260000個部件點要素進行效率驗證，獲取各網格中各種部件的數目，一共耗時5.6S：

 

3. 統計與數據更新如何同步的方案討論

       空間數據並非一成不變的。因爲統計數據來源於空間數據彙總表，而全部更新並非針對彙總表的更新，而是針對具體空間表（如井蓋表）等的更新。如何能將更新數據實時同步至彙總表，統計表如何同步更新，是一個值得討論的問題。

       真實項目中，數據統計的準確性並無要求徹底實時，這塊能夠做僞實時理解。因此問題能夠簡化爲，天天（或幾小時）空間統計表數據更新至最新統計結果。

       對應，這裏給出四種方案：

3.1定時從新生成彙總表，從新統計

       這是思惟上最簡單的一種方案，即用定時任務每次從新生成彙總表（將空間數據採集彙總），而後再從新生成統計表。此方案雖然簡單，可是代價太大，尤爲是全部數據的從新採集是一個比統計自己耗時太多的工做。

3.2利用觸發器

       給每個空間數據表創建一個觸發器，當數據表變動時，同步觸發對彙總表的操做。對於空間統計表定時更新。

       此方案也比較簡單，可是考慮到對全部空間表創建觸發器，當更新頻繁時對數據庫性能有必定影響，還需慎重。

3.3利用中間件cannal進行數據庫操做監聽

       經過部署cannal監聽數據庫的操做，對符合定義的操做進行日誌記錄，定時更新至彙總表中。統計表定時更新。

       該方案的優勢是不須要對全部表建立觸發器，更爲簡潔優美，而且經過定時更新的方案，也能避免高頻度操做時同步更新對數據庫形成的壓力。可是因爲須要部署cannal，增長了項目的部署難度。

3.4系統操做日誌記錄

       在系統層面對數據庫的操做進行單獨日誌記錄。定時解析該日誌文件，並更新彙總表。統計表定時更新。

       該方案無需特殊配置，只需經過代碼完成日誌寫入和解析便可，部署簡單，開發難度也不高。

       其中日誌記錄能夠借用Log4j來快速完成，其支持對指定代碼類生成獨立日誌。能夠對數據庫操做類進行獨立設置，便可：

 

 

　　　　　　　　　　　　　　　　　　　　-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                           若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^