在HBase中存儲瓦片地圖是否科學？生產中，瓦片地圖都是怎麼存儲的呢？

大家好，我在做一個GIS的實驗，我打算將瓦片地圖存在HBase中，不知道這樣做是否科學？

目前，我存了28000多張瓦片地圖在HBase中，在HBase Shell 中查詢一張圖片大約需要0.9s，我設計的rowkey形如14000064630003321，14表示縮放級別，00006461位墨卡托x坐標，0003321為墨卡托y坐標。

hbase集群是在虛擬機裡面搭建的，512M內存，一核處理器。我就想問問大家，這樣的查詢速度正常嗎？在生產環境中，瓦片地圖是怎麼存儲的呢？

有幾個點應該可以改進：

1. 要測試性能，最好不用用HBase shell，使用程序來統計時間，因為HBase shell會默認將二進位轉化成string，再列印到屏幕，這都會消耗時間。
2. rowkey中的x,y坐標完全分開，是否能精確查詢？可以考慮使用Geohash
3. 想問 一張圖片有多大？正常的一條HBase記錄的get的時延大約也就是10ms的級別。
4. 實驗中的HBase的配置也是比較低，可以試試簡單建一張表，put一條數據，用HBase shell get出來的時延對比一下，就知道是查詢一張瓦片慢還是本身的HBase查詢慢了。

表格存儲服務(CloudTable Service)_數據存儲_數據託管_雲數據查詢-華為雲 免費公測階段，提供HBase、時序資料庫OpenTSDB、時空大數據套件GeoMesa能力，歡迎試用。

謝邀！看起來不錯，不懂幫頂

最近在做公司的底層數據改造工作，做到地圖服務這一塊。目前也是在開發階段，還沒有進入生產環境中，僅作參考。

查詢一張圖片0.9秒是無法忍受的。自己的解決方案是影像數據存儲在SQLite資料庫中，利用資料庫提高查詢速度。

這樣做的好處是：SQLite便於遷移，不同db文件可以存放不同來源或時相的數據。資料庫中維持兩張表，metadata表與tiles表，metadata表存放影像名稱、來源、成像時間、投影方式、包含區域等信息，tiles四個欄位，存放level, col, row, data。對level, col, row建索引。

通過切分、組合（或提前設計區域）的方式組織資料庫文件，保證db文件的大小合理（具體大小探索中），滿足地圖服務的查詢速度和底層數據遷移時的快速性。最終要實現谷歌地球可以訪問不同時相的地圖的效果。

定時維護一個capacities文件（xml）格式，維持一個到db文件本地路徑的映射關係，xml中存儲所有提供地圖數據的範圍、名稱、時間等。返回給前端供前端選擇載入的圖層。後端根據前端的url中的layer欄位尋找明確的db文件，並查找到確定的瓦片返回。

歡迎大家幫忙想想這個解決方案是否可行，目前正在實驗中。

有一個問題：自己設計的rowkey（類似題主的方式）和對level、col、row建索引的方式哪個更好？個人主觀覺得後者更好，後者減少了計算步驟，利用了資料庫索引。待實驗檢驗。

覺得不錯隨手點個讚唄，給點動力

同意亞碸的說法。

好久不做gis方面的東西了，僅憑印象大概說一下：

我們在實際生產環境中，有三種格式使用，其一就是亞碸所說的sqlite的形式，另一種是普通的文件系統格式，前端伺服器直接將url映射到對應的文件上，在有足夠的靜態文件緩存的情況下，這種最快；再一種是自定義的一種緊湊格式，本質上和資料庫的索引有點類似。