পোস্টজিআইএসের ভাল ফর্ম্যাটেড অ্যাড্রেসগুলি জিওকোড করার জন্য আমার কত দ্রুত আশা করা উচিত?
আমি পোস্টগ্রিজ এসকিউএল 9.3.7 এবং পোস্টজিআইএস 2.1.7 ইনস্টল করেছি, জাতির ডেটা এবং সমস্ত রাজ্যের ডেটা লোড করেছি তবে জিওকোডিংটি আমার প্রত্যাশার চেয়ে অনেক ধীর বলে মনে হয়েছে। আমি কি আমার প্রত্যাশা অনেক বেশি রেখেছি? আমি প্রতি সেকেন্ডে গড়ে 3 জন পৃথক জিওকোড পাচ্ছি। আমার প্রায় 5 মিলিয়ন করা দরকার এবং এর জন্য আমি তিন সপ্তাহ অপেক্ষা করতে চাই না।
এটি জায়ান্ট আর ম্যাট্রিক্স প্রসেসিংয়ের জন্য একটি ভার্চুয়াল মেশিন এবং আমি এই ডাটাবেসটি পাশেই ইনস্টল করেছি যাতে কনফিগারেশনটি কিছুটা বোকা দেখায়। যদি ভিএম এর কনফিগারেশনে কোনও বড় পরিবর্তন সাহায্য করে, আমি কনফিগারেশনটি পরিবর্তন করতে পারি।
হার্ডওয়্যার চশমা
মেমোরি: 65 জিবি প্রসেসর: 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
ওএস সেন্টোস, 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 ও RAM এর 1/2 কার্যকর ক্যাশের মাপ 1/4 সম্পর্কে ফাইল:
shared_buffers = 16096MB
effective_cache_size = 31765MB
আমার আছে installed_missing_indexes()
এবং (কয়েকটি টেবিলের মধ্যে সদৃশ সন্নিবেশগুলি সমাধান করার পরে) কোনও ত্রুটি নেই।
জিওকোডিং এসকিউএল উদাহরণ # 1 (ব্যাচ) - গড় সময় 2.8 / সেকেন্ড
আমি http://postgis.net/docs/Geocode.html এর উদাহরণ অনুসরণ করছি , যা আমাকে জিওকোডের ঠিকানা সম্বলিত একটি সারণী তৈরি করেছে এবং তারপরে একটি এসকিউএল করছে 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 সেকেন্ডে ফিরে আসবে। এটি ছোট ব্যাচের জন্য কিছুটা ধীর।
জিওকোডিং এসকিউএল উদাহরণ # 2 (সারি সারি) ~ গড় সময়টি 1.2 / সেকেন্ড
আমি যখন জিওকোডগুলি দিয়ে একবারে এই জাতীয় দেখতে দেখতে একটি বিবৃতি দিয়ে আমার ঠিকানাগুলি খনন করি (বিটিডাব্লু, নীচের উদাহরণটি ৪.১৪ সেকেন্ড সময় নিয়েছে),
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.5x) তবে আমি ক্যোয়ারির সময়গুলি বিতরণের দিকে লক্ষ্য করতে পারি এবং দেখতে পাচ্ছি যে এটি দীর্ঘ সংখ্যালঘু সংখ্যালঘু যা এটিকে সবচেয়ে কমিয়ে দিচ্ছে (5 মিলিয়নের মধ্যে প্রথম 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,"'))")
যেখানে myAddress
একটি হল [Address], [City], [ST] [Zip]
স্ট্রিং একটি অ-PostgreSQL ডাটাবেস থেকে একটি ব্যবহারকারী ঠিকানা টেবিল থেকে সংকলিত।
আমি pagc_normalize_address
এক্সটেনশনটি ইনস্টল করার চেষ্টা করেছি (ব্যর্থ হয়েছিলাম) তবে এটি পরিষ্কার নয় যে এটি যে ধরণের উন্নতি খুঁজছি তা এনে দেবে।
পরামর্শ অনুসারে মনিটরিং তথ্য যুক্ত করতে সম্পাদিত
কর্মক্ষমতা
একটি সিপিইউ পেগড: [সম্পাদনা করুন, প্রতি কোয়েরি অনুসারে কেবল একটি প্রসেসর, সুতরাং আমার কাছে 5 টি অব্যবহৃত সিপিইউ রয়েছে]
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
একটি প্রোটোকে ১০০% প্যাগ করার সময় ডেটা পার্টিশনে ডিস্ক ক্রিয়াকলাপের নমুনা: [সম্পাদনা করুন: এই ক্যোয়ারী দ্বারা ব্যবহৃত কেবলমাত্র একটি প্রসেসর]
# 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
যে এসকিউএল বিশ্লেষণ
এটি 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 এ আরও ভাল ভাঙ্গন দেখুন