PostGISが適切にフォーマットされた住所をジオコーディングするのにどれくらいの速度が必要ですか？

PostGISが適切にフォーマットされた住所をジオコーディングするのにどれくらいの速度が必要ですか？

PostgreSQL 9.3.7とPostGIS 2.1.7をインストールし、国のデータとすべての州のデータをロードしましたが、ジオコーディングが予想よりはるかに遅いことがわかりました。期待値を高く設定しすぎていませんか？1秒あたり平均3つの個別のジオコードを取得しています。約500万回行う必要がありますが、これを3週間待ちたくありません。

これは巨大なR行列を処理するための仮想マシンであり、このデータベースを横にインストールしたため、構成が少し間抜けに見えるかもしれません。VMの構成の大きな変更が役立つ場合は、構成を変更できます。

ハードウェア仕様

メモリー：65GBプロセッサー：6 lscpuはこれを私に与えます：

# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                6
On-line CPU(s) list:   0-5
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             6
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Stepping:              0
CPU MHz:               2400.000
BogoMIPS:              4800.00
Hypervisor vendor:     VMware
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0-5

OSはcentosであり、uname -rvこれを提供します：

# uname -rv
2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015

Postgresqlの設定

> select version()
"PostgreSQL 9.3.7 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit"
> select PostGIS_Full_version()
POSTGIS="2.1.7 r13414" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" LIBJSON="UNKNOWN" TOPOLOGY RASTER"

これらの種類のクエリに対する以前の提案に基づいてshared_buffers、postgresql.confファイルを使用可能なRAMの約1/4 に増やし、有効キャッシュサイズをRAMの1/2に増やしました。

shared_buffers = 16096MB     
effective_cache_size = 31765MB

私は持っていますinstalled_missing_indexes()（いくつかのテーブルへの重複挿入を解決した後）エラーはありませんでした。

ジオコーディングSQLの例＃1（バッチ）〜平均時間は2.8 /秒

私はhttp://postgis.net/docs/Geocode.htmlの例に従っています。ジオコードする住所を含むテーブルを作成し、SQLを実行していますUPDATE：

UPDATE addresses_to_geocode
              SET  (rating, longitude, latitude,geo) 
              = ( COALESCE((g.geom).rating,-1),
              ST_X((g.geom).geomout)::numeric(8,5), 
              ST_Y((g.geom).geomout)::numeric(8,5),
              geo )
              FROM (SELECT "PatientId" as PatientId
              FROM addresses_to_geocode 
              WHERE "rating" IS NULL ORDER BY PatientId LIMIT 1000) As a
              LEFT JOIN (SELECT "PatientId" as PatientId, (geocode("Address",1)) As geom
              FROM addresses_to_geocode As ag
              WHERE ag.rating IS NULL ORDER BY PatientId LIMIT 1000) As g ON a.PatientId = g.PatientId
              WHERE a.PatientId = addresses_to_geocode."PatientId";

上記の1000のバッチサイズを使用しており、337.70秒で戻ります。小さいバッチの場合は少し遅くなります。

ジオコーディングSQLの例＃2（行ごと）〜平均時間は1.2 /秒

次のようなステートメントを使用してジオコードを1つずつ実行して住所を掘り下げると（以下の例では4.14秒かかりました）、

SELECT g.rating, ST_X(g.geomout) As lon, ST_Y(g.geomout) As lat, 
    (addy).address As stno, (addy).streetname As street, 
    (addy).streettypeabbrev As styp, (addy).location As city, 
    (addy).stateabbrev As st,(addy).zip 
FROM geocode('6433 DROMOLAND Cir NW, MASSILLON, OH 44646',1) As g;

少し遅くなります（レコードあたり2.5倍）が、クエリ時間の分布を見ると、これが最も遅くなっている少数の長いクエリであることがわかります（500万のうち最初の2600のみがルックアップ時間を持っています）。つまり、上位10％は平均で約100ミリ秒、下位10％は平均3.69秒で、平均は754ミリ秒、中央値は340ミリ秒です。

# Just some interaction with the data in R
> range(lookupTimes[1:2600])
[1]  0.00 11.54
> median(lookupTimes[1:2600])
[1] 0.34
> mean(lookupTimes[1:2600])
[1] 0.7541808
> mean(sort(lookupTimes[1:2600])[1:260])
[1] 0.09984615
> mean(sort(lookupTimes[1:2600],decreasing=TRUE)[1:260])
[1] 3.691269
> hist(lookupTimes[1:2600]

他の考え

パフォーマンスの桁違いの向上が得られない場合、遅いジオコード時間の予測について少なくとも経験に基づいた推測を行うことができると考えましたが、遅いアドレスがこれほど長くかかっているように見える理由は明らかではありません。geocode()関数が取得する前に適切にフォーマットされていることを確認するために、元のアドレスをカスタム正規化ステップで実行しています。

sql=paste0("select pprint_addy(normalize_address('",myAddress,"'))")

where myAddressは、[Address], [City], [ST] [Zip]非postgresqlデータベースのユーザーアドレステーブルからコンパイルされた文字列です。

pagc_normalize_address拡張機能をインストールしようとしました（失敗しました）が、これが私が探している種類の改善をもたらすかどうかは明らかではありません。 提案に従って監視情報を追加するように編集

性能

1つのCPUがペグされます：[編集、クエリごとに1つのプロセッサのみなので、5つの未使用CPUがあります]

top - 14:10:26 up 1 day,  3:11,  4 users,  load average: 1.02, 1.01, 0.93
Tasks: 219 total,   2 running, 217 sleeping,   0 stopped,   0 zombie
Cpu(s): 15.4%us,  1.5%sy,  0.0%ni, 83.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65056588k total, 64613476k used,   443112k free,    97096k buffers
Swap: 262139900k total,    77164k used, 262062736k free, 62745284k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3130 postgres  20   0 16.3g 8.8g 8.7g R 99.7 14.2 170:14.06 postmaster
11139 aolsson   20   0 15140 1316  932 R  0.3  0.0   0:07.78 top
11675 aolsson   20   0  135m 1836 1504 S  0.3  0.0   0:00.01 wget
    1 root      20   0 19364 1064  884 S  0.0  0.0   0:01.84 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.06 kthreadd

1つのprocが100％に固定されている間のデータパーティション上のディスクアクティビティのサンプル：[編集：このクエリで使用されているプロセッサは1つのみ]

# dstat -tdD dm-3 1
----system---- --dsk/dm-3-
  date/time   | read  writ
12-06 14:06:36|1818k 3632k
12-06 14:06:37|   0     0
12-06 14:06:38|   0     0
12-06 14:06:39|   0     0
12-06 14:06:40|   0    40k
12-06 14:06:41|   0     0
12-06 14:06:42|   0     0
12-06 14:06:43|   0  8192B
12-06 14:06:44|   0  8192B
12-06 14:06:45| 120k   60k
12-06 14:06:46|   0     0
12-06 14:06:47|   0     0
12-06 14:06:48|   0     0
12-06 14:06:49|   0     0
12-06 14:06:50|   0    28k
12-06 14:06:51|   0    96k
12-06 14:06:52|   0     0
12-06 14:06:53|   0     0
12-06 14:06:54|   0     0 ^C

そのSQLを分析する

これはEXPLAIN ANALYZEそのクエリからのものです：

"Update on addresses_to_geocode  (cost=1.30..8390.04 rows=1000 width=272) (actual time=363608.219..363608.219 rows=0 loops=1)"
"  ->  Merge Left Join  (cost=1.30..8390.04 rows=1000 width=272) (actual time=110.934..324648.385 rows=1000 loops=1)"
"        Merge Cond: (a.patientid = g.patientid)"
"        ->  Nested Loop  (cost=0.86..8336.82 rows=1000 width=184) (actual time=10.676..34.241 rows=1000 loops=1)"
"              ->  Subquery Scan on a  (cost=0.43..54.32 rows=1000 width=32) (actual time=10.664..18.779 rows=1000 loops=1)"
"                    ->  Limit  (cost=0.43..44.32 rows=1000 width=4) (actual time=10.658..17.478 rows=1000 loops=1)"
"                          ->  Index Scan using "addresses_to_geocode_PatientId_idx" on addresses_to_geocode addresses_to_geocode_1  (cost=0.43..195279.22 rows=4449758 width=4) (actual time=10.657..17.021 rows=1000 loops=1)"
"                                Filter: (rating IS NULL)"
"                                Rows Removed by Filter: 24110"
"              ->  Index Scan using "addresses_to_geocode_PatientId_idx" on addresses_to_geocode  (cost=0.43..8.27 rows=1 width=152) (actual time=0.010..0.013 rows=1 loops=1000)"
"                    Index Cond: ("PatientId" = a.patientid)"
"        ->  Materialize  (cost=0.43..18.22 rows=1000 width=96) (actual time=100.233..324594.558 rows=943 loops=1)"
"              ->  Subquery Scan on g  (cost=0.43..15.72 rows=1000 width=96) (actual time=100.230..324593.435 rows=943 loops=1)"
"                    ->  Limit  (cost=0.43..5.72 rows=1000 width=42) (actual time=100.225..324591.603 rows=943 loops=1)"
"                          ->  Index Scan using "addresses_to_geocode_PatientId_idx" on addresses_to_geocode ag  (cost=0.43..23534259.93 rows=4449758000 width=42) (actual time=100.225..324591.146 rows=943 loops=1)"
"                                Filter: (rating IS NULL)"
"                                Rows Removed by Filter: 24110"
"Total runtime: 363608.316 ms"

http://explain.depesz.com/s/vogSで詳細な内訳を参照してください

私はこれを実験するのに多くの時間を費やしましたが、角度が異なるため、別々に投稿する方が良いと思います。

これは本当に複雑なトピックです。ジオコーディングサーバーのセットアップと使用したスクリプトに関する私のブログ投稿の詳細を参照してください。ここに簡単な要約を示します。

状態データが2つしかないサーバーは、50個すべての状態データをロードしたサーバーよりも常に高速です。

私は異なる時間に自宅のPCと2つの異なるAmazon AWSサーバーでこれを確認しました。

2州のデータを使用するAWS無料利用枠サーバーには1G RAMしかありませんが、1000レコードと45,000レコードのデータに対して一貫した43〜59ミリ秒のパフォーマンスがあります。

すべての状態がロードされ、スクリプトとデータがまったく同じである8G RAM AWSサーバーにまったく同じセットアップ手順を使用し、パフォーマンスは80〜105ミリ秒に低下しました。

私の理論では、ジオコーダーは住所を正確に一致させることができない場合、検索範囲を広げ始め、郵便番号や都市などの一部を無視し始めました。これが、ジオコードドキュメントが3000ミリ秒かかったにもかかわらず、間違った郵便番号で住所を再コロニー化できることを誇っている理由です。

2つの状態データのみがロードされると、サーバーは2つの状態でしか検索できないため、実りのない検索や非常に低いスコアの一致にかかる時間が大幅に短縮されます。

restrict_regionほとんどのアドレスが正しい状態であることを確信しているため、パラメータをジオコード関数の状態マルチポリゴンに設定してこれを制限しようとしました。これら2つのバージョンを比較します。

  select geocode('501 Fairmount DR , Annapolis, MD 20137',1); 
  select geocode('501 Fairmount DR , Annapolis, MD 20137', 1, the_geom) from tiger.state where statefp = '24';

2番目のバージョンで行われた唯一の違いは、通常、同じクエリをすぐに再度実行すると、関連データがキャッシュされたため、はるかに高速になることですが、2番目のバージョンではこの効果が無効になりました。

だから、restrict_region私が望んでいたように機能していません。多分、検索範囲を制限するためではなく、複数ヒット結果をフィルタリングするために使用されただけかもしれません。

postgre confを少し調整できます。

インデックスを紛失してインストールするという通常の疑いであるvacuum analyzeは、ダウンロードスクリプトがすでに必要なメンテナンスを行っているため、それらを台無しにしない限り、私にとっては何の違いもありませんでした。

ただし、この投稿に従ってpostgre confを設定すると役に立ちました。50状態のフルスケールサーバーは、一部の悪い形状のデータのデフォルト構成で320ミリ秒でしたが、2G shared_buffer、5Gキャッシュで185ミリ秒に改善し、その投稿に従って調整されたほとんどの設定でさらに100ミリ秒になりました。

これはpostgisにより関連しており、それらの設定は似ているように見えました。

私の場合、各コミットのバッチサイズはそれほど重要ではありませんでした。 ジオコードのドキュメントでは、バッチサイズ3を使用しました。1、3、5から10までの値を実験しました。これとの間に大きな違いはありませんでした。バッチサイズを小さくすると、より多くのコミットと更新が行われますが、本当のボトルネックはここにはないと思います。実際、今はバッチサイズ1を使用しています。常に予期しない不正な形式のアドレスが存在すると例外が発生するため、エラーが発生したバッチ全体を無視するように設定し、残りの行に進みます。バッチサイズ1の場合、無視されたとマークされたバッチ内の可能性のある適切なレコードをジオコーディングするために、テーブルを2回処理する必要はありません。

もちろん、これはバッチスクリプトの動作に依存します。詳細については、後でスクリプトを投稿します。

使用法に合っている場合は、アドレスの正規化を使用して不良アドレスをフィルタリングすることができます。 私は誰かがこれをどこかで言及したのを見ましたが、normalize関数はフォーマットでのみ機能するため、どのアドレスが無効であるかを実際に伝えることができないため、これがどのように機能するのか分かりませんでした。

後でアドレスが明らかに悪い形であり、それらをスキップしたいと思う場合これが助けることができることに気づきました。たとえば、ストリート名やストリート名が欠けている住所がたくさんあります。最初にすべてのアドレスを正規化するのは比較的高速です。その後、明らかな不良アドレスをフィルタリングしてからスキップできます。しかし、これは私の番地ではなく、番地や街路名のない住所でも番地や都市にマッピングすることができ、その情報は今でも役に立ちます。

そして、私の場合、ジオコーディングできないアドレスのほとんどには、実際にはすべてのフィールドがあり、データベースに一致するものはありません。これらのアドレスを正規化するだけではフィルタリングできません。

編集詳細については、ジオコーディングサーバーのセットアップと使用したスクリプトに関するブログ投稿を参照してください。

EDIT 2 200万件の住所のジオコーディングを終了し、ジオコーディングの結果に基づいて住所の多くのクリーンアップを行いました。きれいになった入力により、次のバッチジョブの実行速度が大幅に向上します。クリーンとは、一部の住所が明らかに間違っているため削除する必要があること、またはジオコーダーがジオコーディングで問題を引き起こす予期しないコンテンツがあることを意味します。私の理論は次のとおりです。 不良アドレスを削除すると、キャッシュの混乱を回避でき、良好なアドレスのパフォーマンスが大幅に向上します。

状態に基づいて入力を分離し、すべてのジョブがジオコーディングに必要なすべてのデータをRAMにキャッシュできるようにしました。ただし、ジョブ内の不良アドレスはすべて、ジオコーダーがより多くの州で検索するようにし、キャッシュを台無しにする可能性があります。

1. このディスカッションスレッドによると、同じ正規化手順を使用してTigerデータと入力アドレスを処理することになっています。Tigerデータはビルトインノーマライザーで処理されているため、ビルトインノーマライザーのみを使用することをお勧めします。pagc_normalizerを機能させたとしても、それを使用してTigerデータを更新しなければ役に立たない可能性があります。

   そうは言っても、とにかくgeocode（）はノーマライザーを呼び出すと思うので、ジオコーディングが実際に役に立たない前にアドレスを正規化します。ノーマライザの1つの可能な使用法は、正規化されたアドレスとgeocode（）によって返されたアドレスを比較することです。両方とも正規化されているため、誤ったジオコーディング結果を見つけやすくなります。

   ノーマライザによってジオコードから不良住所を除外できる場合、それは本当に役立ちます。ただし、ノーマライザーには一致スコアや評価のようなものはありません。

2. 同じディスカッションスレッドでは、デバッグスイッチについてもgeocode_address詳しく説明しています。ノードにgeocode_addressは正規化されたアドレス入力が必要です。

3. ジオコーダーは完全一致には高速ですが、困難な場合にはさらに時間がかかります。パラメータがあることに気付きrestrict_region、制限を状態として設定すると、どの状態になるかがはっきりしているので、無益な検索が制限される可能性があると考えました。正しいアドレスですが、少し時間がかかります。

   したがって、最初の完全一致検索が一致しない場合、ジオコーダーはすべての可能な場所を検索する可能性があります。これにより、いくつかのエラーで入力を処理できるようになりますが、一部の検索が非常に遅くなります。

   インタラクティブなサービスがエラーのある入力を受け付けるのは良いことだと思いますが、バッチジオコーディングのパフォーマンスを向上させるために、間違った住所の小さなセットをあきらめたい場合があります。

私はこの答えを投稿するつもりですが、できれば別の貢献者が次の内訳を助けてくれることを願っています。

ジオコーディングに読み込まれる州の数の影響は何ですか？50個すべてを取得しましたが、@ LR1234567よりもはるかに低いパフォーマンス（つまり、8倍の時間geocode）を経験しています。

バルクジオコーディングの最も効率的な方法は何ですか？バックロード全体が完了するまで、100のバッチを繰り返し実行するシリアルプロセスを実行しています。マルチスレッドのアプローチが望ましいでしょうが、どのアプローチが推奨されますか？

PostgreSQLジオコーディングに対する仮想化の影響は何ですか？私は他のいくつかの投稿に基づいて10％を推測していますが、その答えにはほとんど自信がありません

さて、私の答えは逸話に過ぎません。

（単一の接続に基づいて）私が得ている最高のものは、平均208ミリ秒geocodeです。これは、データセットからランダムに住所を選択することで測定されます。これは米国全体に広がっています。ダーティデータが含まれていますが、最も長時間実行されているgeocodesは明らかな意味で悪いようには見えません。

その要点は、CPUに縛られているように見えることと、1つのクエリが1つのプロセッサに縛られていることです。理論UPDATE的には、addresses_to_geocodeテーブルの補完的なセグメントで複数の接続を実行することで、これを並列化できます。それまでの間、geocode全国的なデータセットで平均208ミリ秒かかるようになりました。ほとんどの住所がどこにあるのか、どのくらい時間がかかっているのか（たとえば、上のヒストグラムを参照）と下の表の両方の点で、分布は偏っています。

これまでの私の最善のアプローチは、10000のバッチでそれを行うことですが、バッチごとにさらに多くのことを行うことである程度の改善が可能です。100バッチの場合、約251ミリ秒、10000で208ミリ秒になりました。

UPDATE addresses_to_geocode 
SET (rating, longitude, latitude, geo) = 
   (COALESCE((g.geom).rating,-1), 
            ST_X((g.geom).geomout)::numeric(8,5),   
            ST_Y((g.geom).geomout)::numeric(8,5), 
            geo) 
   FROM (
       SELECT "PatientId" as PatientId 
       FROM addresses_to_geocode  
       WHERE "rating" IS NULL 
       ORDER BY PatientId LIMIT 100) As a 
   LEFT JOIN (
       SELECT "PatientId" as PatientId, (geocode("Address",1)) As geom 
       FROM addresses_to_geocode As ag 
       WHERE ag.rating IS NULL 
       ORDER BY PatientId LIMIT 100) As g 
   ON a.PatientId = g.PatientId 
   WHERE a.PatientId = addresses_to_geocode."PatientId";

RPostgreSQLがテーブルを作成する方法のために、フィールド名を引用する必要があります dbWriteTable

これは、一度に1つのレコードを処理する場合の約4倍の速度です。一度に1つずつ実行すると、状態ごとに分類できます（以下を参照）。これを実行して、1つ以上のTIGER状態に悪い負荷またはインデックスがあったかどうかを確認しました。これにより、状態geocodeごとにパフォーマンスが低下することが予想されました。私は明らかにいくつかの悪いデータを持っています（一部のアドレスはメールアドレスです！）が、それらのほとんどは適切にフォーマットされています。前に言ったように、実行時間が最も長いクエリの一部には、形式に明らかな欠陥はありません。以下は、データセットの3000個のランダムアドレスからの状態の数、最小クエリ時間、平均クエリ時間、および最大クエリ時間の表です。

       state   n  min      mean   max
1          .   1 0.00 0.0000000  0.00
12        DC   6 0.07 0.0900000  0.10
9  CHIHUAHUA   1 0.16 0.1600000  0.16
2         00   1 0.18 0.1800000  0.18
6         AR   1 0.37 0.3700000  0.37
27        MT  17 0.14 0.4229412  1.01
14        GA  37 0.22 0.4340541  2.78
10        CO   1 0.54 0.5400000  0.54
16        IL 390 0.16 0.5448974  3.75
8         CA 251 0.17 0.5546614  3.58
5         AL   4 0.13 0.5575000  0.86
18        KS   3 0.43 0.5966667  0.75
23        ME 121 0.14 0.6266116  7.88
35        SC 390 0.14 0.6516923  6.88
24        MI  62 0.12 0.6524194  3.36
40        WA   3 0.23 0.7500000  1.41
32        OK 145 0.17 0.7538621  5.84
20        LA   1 0.76 0.7600000  0.76
31        OH 551 0.00 0.7623775 10.27
17        IN 108 0.19 0.7864815  3.64
43      <NA>  89 0.00 0.8152809  4.98
15        IA   1 0.82 0.8200000  0.82
30        NY 227 0.19 0.8227753 28.47
19        KY   3 0.56 0.8333333  1.36
36        TN 333 0.11 0.8566667  6.45
28        NC 129 0.24 0.8843411  4.07
13        FL  70 0.28 0.9131429  4.65
7         AZ 101 0.20 0.9498020  6.33
34        PA  56 0.14 0.9594643  3.61
29        NJ   1 1.03 1.0300000  1.03
33        OR 101 0.24 1.0966337 14.89
26        MS  28 0.25 1.1503571 11.89
3          9   6 0.58 1.2133333  1.93
4         AK   1 1.25 1.2500000  1.25
22        MD   9 0.50 1.3055556  4.17
25        MO  22 0.31 1.3381818  4.20
42        WY   1 1.38 1.3800000  1.38
38        VA 127 0.20 1.3873228  5.69
37        TX   4 0.53 1.4800000  3.28
21        MA   4 0.47 1.5725000  3.63
11        CT   5 0.38 1.6760000  4.68
39        VT   1 2.25 2.2500000  2.25
41        WI   2 2.27 2.2850000  2.30