mbtiles作成の時間計測
今回は、OpenMapTilesのquickstart.shの処理時間を計測します。
時間計測方法
計測の目的は、OpenMapTilesの処理概要の把握とボトルネックの確認です。
計測の条件を整理します。
- OSMデータは四国（shikoku.osm.pbf、約63MB）を使用
- quickstart.shの–emptyオプションを指定しpreloadコンテナを使用しない
- quickstart.shにて発行されるコマンドの前後にdateコマンドの発行を追加し時間を計測
- 作成するタイルのズームレベルは0〜7まで（.envデフォルトのまま）
- マシンはさくらVPS。メモリ1GB、CPU2コア、SSD100GB
計測結果
処理は2時間44分で終了しました。計測結果を以下の表にまとめます。
[table id=24 /]
処理の最初にコンソールに表示される内容を”処理内容”として記載しています。処理時間の97%は、#19のbuild/sql配下のsqlの実行であることがわかります。
今回は、ズームレベル0〜7までの小縮尺地図のみ作成したせいかもしれませんが、#13のMBTilesの作成時間はわずか15秒です（完成したMBTilesのサイズは528KB）。
では、処理時間のほとんどを費やした#19のbuild/sql配下のsqlの実行時間を確認してみます。
[table id=25 /]
合計時間が1時間以上合いませんが、#16、#17などが重複しているのだと思います。
#16〜18のpoi（点の地物データ）関連の処理時間が大半であることがわかります。
考察
完成したMBTilesをTileServerGLを使って配信し、レイヤ数を確認すると、以下のように16種類あることがわかります。
そして、build/sqlディレクトリ配下のsqlファイル数は14、layersディレクトリ配下のレイヤと思われるディレクトリ数は16あります。
おそらく、build/sqlディレクトリ配下のsqlスクリプトは、NaturalEarthやOSMなどの元データからのデータ取り込み用、layersディレクトリ配下はMBTiles出力用のsqlスクリプトであると思われます。
openmaptiles
|– build
| |– mapping.yaml
| |– openmaptiles.tm2source
| | |– data.yml
| |– sql
| |– parallel
| | |– aerodrome_label.sql
| | |– aeroway.sql
| | |– boundary.sql
| | |– building.sql
| | |– housenumber.sql
| | |– landcover.sql
| | |– landuse.sql
| | |– mountain_peak.sql
| | |– park.sql
| | |– place.sql
| | |– poi.sql
| | |– transportation__transportation_name.sql
| | |– water__waterway.sql
| | |– water_name.sql
| |– run_first.sql
| |– run_last.sql
|– layers
| |– aerodrome_label
| | |– aerodrome_label.yaml
| | |– layer.sql
| | |– mapping.yaml
| | |– update_aerodrome_label_point.sql
| |– aeroway
| | |– aeroway.yaml
| | |– layer.sql
| | |– mapping.yaml
| |– boundary
| | |– boundary.sql
| | |– boundary.yaml
| | |– mapping.yaml
| |– building
| | |– building.sql
| | |– building.yaml
| | |– mapping.yaml
| | |– update_building.sql
| |– housenumber
| | |– housenumber.yaml
| | |– housenumber_centroid.sql
| | |– layer.sql
| | |– mapping.yaml
| |– landcover
| | |– landcover.sql
| | |– landcover.yaml
| | |– mapping.yaml
| |– landuse
| | |– landuse.sql
| | |– landuse.yaml
| | |– mapping.yaml
| |– mountain_peak
| | |– README.md
| | |– layer.sql
| | |– mapping.yaml
| | |– mountain_peak.yaml
| | |– update_peak_point.sql
| |– park
| | |– layer.sql
| | |– mapping.yaml
| | |– park.yaml
| | |– update_park_polygon.sql
| |– place
| | |– capital.sql
| | |– city.sql
| | |– island_rank.sql
| | |– layer.sql
| | |– mapping.yaml
| | |– place.yaml
| | |– types.sql
| | |– update_city_point.sql
| | |– update_continent_point.sql
| | |– update_country_point.sql
| | |– update_island_point.sql
| | |– update_island_polygon.sql
| | |– update_state_point.sql
| |– poi
| | |– class.sql
| | |– layer.sql
| | |– mapping.yaml
| | |– poi.yaml
| | |– poi_stop_agg.sql
| | |– public_transport_stop_type.sql
| | |– update_poi_point.sql
| | `– update_poi_polygon.sql
| |– transportation
| | |– class.sql
| | |– layer.sql
| | |– mapping.yaml
| | |– transportation.yaml
| | |– update_transportation_merge.sql
| |– transportation_name
| | |– layer.sql
| | |– network_type.sql
| | |– transportation_name.yaml
| | |– update_route_member.sql
| | |– update_transportation_name.sql
| |– water
| | |– mapping.yaml
| | |– update_water.sql
| | |– water.sql
| | |– water.yaml
| |– water_name
| | |– mapping.yaml
| | |– update_marine_point.sql
| | |– update_water_lakeline.sql
| | |– update_water_point.sql
| | |– water_name.yaml
| |– waterway
| |– mapping.yaml
| |– update_important_waterway.sql
| |– update_waterway_linestring.sql
| |– waterway.sql
| |– waterway.yaml
まとめ
今回は、MBTiles作成のボトルネックを確認するための処理時間計測を行いました。
当初は、MBTilesを作成するために多くの時間を費やしていると想像していましたが、今回の計測でPOIがらみのデータ加工に時間を費やしていることがわかりました。
SQLスクリプトを眺めると、主にストアードファンクションを使って複雑な処理を行っているように見えます。
一般的にRDBMSは、UPDATE文を発行するとディスクIOが多発して性能を落とすので、性能があまり良くないのはPOIデータに対するUPDATE文の発行なのだろうと思っています。今のところ。
次回以降は、buildディレクトリ配下のSQLスクリプトの内容を確認していこうと思います。
