পোস্টজিআইএসের ভাল ফর্ম্যাটেড অ্যাড্রেসগুলি জিওকোড করার জন্য আমার কত দ্রুত আশা করা উচিত?


17

পোস্টজিআইএসের ভাল ফর্ম্যাটেড অ্যাড্রেসগুলি জিওকোড করার জন্য আমার কত দ্রুত আশা করা উচিত?

আমি পোস্টগ্রিজ এসকিউএল 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_bufferspostgresql.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]

প্রথম 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 এ আরও ভাল ভাঙ্গন দেখুন


1
আপনি অনুসন্ধান চালানোর সময় যন্ত্রটি কী করবে? এটি আইওতে বাধা দেয় বা অন্য কোথাও বাধা?
টিল_বি

1
আপনি কতগুলি রাষ্ট্র বোঝা করেছেন? আমি সাধারণত 30 মিমি থেকে যে কোনও জায়গায় পেতে পারি - 4-8 গিগাবাইট র্যাম সহ একটি উইন্ডোজ -৪-বিট বাক্সে ঠিকানা প্রতি 150 এমএস। সাধারণত যদিও আমি কেবল 1 বা 2 টি রাজ্যের সাথে কাজ করছি। পারফরম্যান্সে আরও রাজ্যের প্রভাবের জন্য মাপদণ্ড হয়নি।
LR1234567

@ এলআর 1234567 50 টি রাজ্য
আরিয়নো

1
@til_b সিপিইউ 99.7%
আরিয়নো

দেখে মনে হচ্ছে যে আমরা এক সপ্তাহের জিনিসটি শেষ করে এই জিনিসটি শেষ করতে কয়েক সপ্তাহ অপেক্ষা করতে যাচ্ছি এবং এটি 100 অ্যাড্রেস / দিনের রানটাইম বোঝাটি শেষ করার পরে আমাদের প্রচুর রস বাকি থাকবে আমরা অভিজ্ঞতা আছে। আমরা সত্যিই কিছু জোরালো কিছু আসে যা আমাদের শেষ হয়ে যাওয়া সিপিইউগুলি পেতে দেয়, যতক্ষণ না শেষ হয় আমি এই উন্মুক্ত রাখব।
আর্যানো

উত্তর:


7

আমি এটি নিয়ে অনেক সময় ব্যয় করেছি, আমি মনে করি যে তারা ভিন্ন কোণ থেকে আলাদাভাবে পোস্ট করা ভাল।

এটি সত্যিই একটি জটিল বিষয়, জিওকোডিং সার্ভার সেটআপ এবং আমার ব্যবহৃত স্ক্রিপ্ট সম্পর্কে আমার ব্লগ পোস্টে আরও বিশদ দেখুন ,

50 টি রাজ্যের ডেটাযুক্ত সার্ভারের চেয়ে কেবল 2 টি স্টেটাস ডেটা সহ একটি সার্ভার সর্বদা দ্রুত।

আমি এটি আমার হোম পিসির সাথে বিভিন্ন সময়ে এবং দুটি পৃথক অ্যামাজন এডাব্লুএস সার্ভার দিয়ে যাচাই করেছি।

2 টি স্টেটের ডেটা সহ আমার এডাব্লুএস ফ্রি টায়ার সার্ভারটিতে কেবল 1 জি র‌্যাম রয়েছে তবে 1000 রেকর্ড এবং 45,000 রেকর্ড সহ ডেটাগুলির জন্য এটির ধারাবাহিকভাবে 43 ~ 59 এমএস পারফরম্যান্স রয়েছে।

আমি 8 গিগাবাইট র‌্যাম এডাব্লুএস সার্ভারের জন্য ঠিক একই সেটআপ প্রক্রিয়াটি ব্যবহার করেছি সমস্ত রাজ্যের লোড হওয়া, ঠিক একই স্ক্রিপ্ট এবং ডেটা, এবং কর্মক্ষমতাটি 80 ~ 105 এমএসে নেমে গেছে।

আমার তত্ত্বটি হ'ল জিওকডার ঠিকানায় ঠিকানার সাথে মেলে না, তখন এটি অনুসন্ধানের পরিধিটি প্রশস্ত করতে এবং কিছু অংশ, যেমন জিপকোড বা শহরকে উপেক্ষা করতে শুরু করে। এই কারণেই জিওকোড ডকুমেন্ট গর্ব করে যে এটি ভুল জিপ কোডের সাথে ঠিকানাটি পুনরায় সংশ্লেষ করতে পারে যদিও এটি 3000 এমএস নিয়েছিল।

মাত্র ২ টি স্টেটের ডেটা লোড হওয়ার সাথে সাথে সার্ভারটি ফলহীন অনুসন্ধানে বা খুব কম স্কোরের ম্যাচে অনেক কম সময় নেয়, কারণ এটি কেবল ২ টি রাজ্যে অনুসন্ধান করতে পারে।

আমি restrict_regionজিওকোড ফাংশনে স্টেট মাল্টিপলিগনগুলিতে প্যারামিটার সেট করে এটি সীমাবদ্ধ করার চেষ্টা করেছি , এই আশায় যে ফলহীন অনুসন্ধান এড়াতে পারবেন যেহেতু আমি বেশিরভাগ ঠিকানার সঠিক অবস্থান আছে বলে আমি নিশ্চিত। এই দুটি সংস্করণ তুলনা করুন:

  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';

দ্বিতীয় সংস্করণে কেবলমাত্র পার্থক্যটি হ'ল আমি যদি একই তাত্ক্ষণিকভাবে তাত্ক্ষণিকভাবে আবার চালিত করি তবে এটি আরও দ্রুত হবে কারণ সম্পর্কিত ডেটা ক্যাশে হয়েছিল, তবে দ্বিতীয় সংস্করণটি এই প্রভাবটিকে অক্ষম করে।

সুতরাং restrict_regionহিসাবে আমি আকাঙ্ক্ষিত কাজ করছে না, হয়তো এটা শুধু একাধিক হিট ফলাফলের ফিল্টার করতে, সীমা অনুসন্ধান রেঞ্জ না ব্যবহার করা হয়েছিল।

আপনি নিজের পোস্টগ্রি কনফিউশনটি কিছুটা টিউন করতে পারেন।

অনুপস্থিত সূচকগুলি ইনস্টল করার ক্ষেত্রে সাধারণ সন্দেহ, ভ্যাকুয়াম বিশ্লেষণ আমার পক্ষে কোনও তাত্পর্যপূর্ণ করেনি, কারণ ডাউনলোড স্ক্রিপ্ট ইতিমধ্যে প্রয়োজনীয় রক্ষণাবেক্ষণ করেছে, যদি না আপনি এগুলির সাথে গোলমাল করেন।

তবে এই পোস্ট অনুসারে postgre কনফারেন্স সেট করা সাহায্য করেছিল। 50 টি রাজ্য সহ আমার পূর্ণ স্কেল সার্ভারটিতে 320 এমএসের সাথে আরও খারাপ আকারের ডেটার জন্য ডিফল্ট কনফিগারেশন ছিল, এটি 2 জি শেয়ারড_বাফার, 5 জি ক্যাশে দিয়ে 185 এমএসে উন্নত হয়েছিল এবং সেই পোস্ট অনুসারে বেশিরভাগ সেটিংসের সাথে আরও 100 এমএসে চলে গেছে।

এটি পোস্টগিসের সাথে আরও প্রাসঙ্গিক এবং তাদের সেটিংস অনুরূপ বলে মনে হয়েছে।

প্রতিটি প্রতিশ্রুতির ব্যাচের আকার আমার ক্ষেত্রে খুব বেশি গুরুত্ব দেয় না matter জিওকোড ডকুমেন্টেশনে একটি ব্যাচের আকার 3 ব্যবহার করা হয়েছে I আমি 1, 3, 5 থেকে 10 পর্যন্ত 10 টি মান পরীক্ষা করেছি I আমি এর সাথে কোনও উল্লেখযোগ্য পার্থক্য পাই না। ছোট ব্যাচের আকারের সাথে আপনি আরও কমিট এবং আপডেট করেন তবে আমার মনে হয় আসল বোতল ঘাড় এখানে নেই। আসলে আমি এখন ব্যাচের আকার 1 ব্যবহার করছি। যেহেতু সবসময় কিছু অপ্রত্যাশিত অসুস্থ গঠন ঠিকানা ব্যতিক্রম ঘটায়, তাই আমি ত্রুটিযুক্তভাবে পুরো ব্যাচটিকে উপেক্ষা করে সেট করব এবং অবশিষ্ট সারিগুলির জন্য এগিয়ে যাব। ব্যাচের আকার 1 সহ আমার দ্বিতীয়বার টেবিলটি প্রক্রিয়া করার দরকার নেই, উপেক্ষা করা হিসাবে চিহ্নিত ব্যাচের সম্ভাব্য ভাল রেকর্ডগুলি জিওকোড করতে।

অবশ্যই এটি আপনার ব্যাচের স্ক্রিপ্ট কীভাবে কাজ করে তার উপর নির্ভর করে। আমি আমার স্ক্রিপ্ট আরও বিশদ পরে পোস্ট করব।

খারাপ ব্যবহারের ঠিকানাটি যদি আপনার ব্যবহারের সাথে মানানসই হয় তবে আপনি সাধারণ ঠিকানাটি ব্যবহার করতে চেষ্টা করতে পারেন। আমি কাউকে কোথাও এটি উল্লেখ করে দেখেছি, তবে আমি নিশ্চিত ছিলাম না যে এটি কীভাবে কাজ করে যেহেতু স্বাভাবিককরণ ফাংশনটি কেবলমাত্র ফর্ম্যাটে কাজ করে, এটি আপনাকে সত্যিই বলতে পারে না কোন ঠিকানাটি অবৈধ।

পরে আমি বুঝতে পারি যে ঠিকানাটি যদি স্পষ্টত খারাপ আকারে থাকে এবং আপনি সেগুলি এড়াতে চান তবে এটি সাহায্য করতে পারে। উদাহরণস্বরূপ আমার প্রচুর ঠিকানা রয়েছে রাস্তার নাম বা রাস্তার নামগুলি missing প্রথমে সমস্ত ঠিকানাটি স্বাভাবিক করুন তুলনামূলকভাবে দ্রুত হবে, তারপরে আপনি সুস্পষ্ট খারাপ ঠিকানাটি ফিল্টার করতে পারেন তারপরে সেগুলি এড়িয়ে যান। তবে এটি আমার ব্যবহার স্যুট করেনি যেহেতু রাস্তার নম্বর বা রাস্তার নাম ছাড়া কোনও ঠিকানা এখনও রাস্তায় বা শহরে ম্যাপ করা যেতে পারে এবং সেই তথ্য এখনও আমার পক্ষে কার্যকর।

এবং আমার ক্ষেত্রে জিওকোড করা যায় না এমন বেশিরভাগ ঠিকানাগুলিতে আসলে সমস্ত ক্ষেত্র রয়েছে, কেবল ডাটাবেসে কোনও মিল নেই। আপনি এই ঠিকানাগুলি কেবলমাত্র সাধারণ করে ফিল্টার করতে পারবেন না।

সম্পাদনা সম্পাদনা আরও তথ্যের জন্য, জিওকোডিং সার্ভার সেটআপ এবং আমার ব্যবহৃত স্ক্রিপ্ট সম্পর্কে আমার ব্লগ পোস্টটি দেখুন ।

সম্পাদনা 2 আমি 2 মিলিয়ন ঠিকানা জিওকোডিং শেষ করেছি এবং জিওকোডিং ফলাফলের ভিত্তিতে ঠিকানার উপর প্রচুর পরিস্কার করেছি। আরও ভাল সাফ ইনপুট দিয়ে, পরবর্তী ব্যাচের কাজটি আরও দ্রুত চলছে। পরিষ্কার দ্বারা আমার অর্থ কিছু ঠিকানা স্পষ্টতই ভুল এবং সরানো উচিত, বা জিওকোডিংয়ের ক্ষেত্রে সমস্যা তৈরি করার জন্য জিওকোডারের জন্য অপ্রত্যাশিত সামগ্রী থাকতে হবে content আমার তত্ত্বটি হল: খারাপ ঠিকানাগুলি মুছে ফেলা ক্যাশে বিশৃঙ্খলা এড়াতে পারে, যা ভাল ঠিকানায় পারফরম্যান্সকে উল্লেখযোগ্যভাবে উন্নত করে।

আমি প্রতিটি চাকরিতে জিওকোডিংয়ের জন্য প্রয়োজনীয় সমস্ত ডেটা র‌্যামে থাকতে পারে তা নিশ্চিত করার জন্য আমি রাষ্ট্রের ভিত্তিতে ইনপুট পৃথক করেছিলাম। তবে কাজের প্রতিটি খারাপ ঠিকানা জিওকোডারকে আরও রাজ্যে অনুসন্ধান করতে সক্ষম করে, যা ক্যাশে গোলমাল করতে পারে।


দুর্দান্ত সাড়া। আমার বাক্সে, যেমনটি ঘটে, রাষ্ট্রের জন্য ফিল্টারিং ম্যাচের গতি 50 (প্রায়) এর একটি গুণককে বাড়িয়ে দেয় তবে আমার সন্দেহ হয় যে আমার সূচির সমস্যা থাকতে পারে।
একো

2
  1. এই আলোচনার থ্রেড অনুসারে , টাইগার ডেটা এবং আপনার ইনপুট ঠিকানার প্রক্রিয়া করার জন্য আপনার একই স্বাভাবিককরণ পদ্ধতি ব্যবহার করার কথা। যেহেতু বাঘের ডেটা বিল্ট-ইন নরমালাইজারের সাথে প্রক্রিয়াজাত করা হয়েছে, তাই এটি বিল্ট-ইন নরমালাইজার ব্যবহার করা আরও ভাল। এমনকি যদি আপনি প্যাগসি_নরমালাইজার কাজ করেও পান তবে আপনি যদি বাঘের ডেটা আপডেট করার জন্য এটি ব্যবহার না করেন তবে এটি আপনাকে সাহায্য করবে না।

    বলা হচ্ছে, আমি মনে করি জিওকোড () যেকোন উপায়ে নরমালাইজারকে কল করবে তাই জিওকোডিংটি সত্যিই দরকারী না হওয়ার আগে ঠিকানার ঠিকানাটিকে স্বাভাবিক করুন। নরমালাইজারের একটি সম্ভাব্য ব্যবহার হ'ল সাধারণীকৃত ঠিকানা এবং জিওকোড () দ্বারা ফেরত ঠিকানাটির তুলনা করা যেতে পারে। তাদের উভয়কেই স্বাভাবিক করা গেলে ভুল জিওকোডিংয়ের ফলাফলটি পাওয়া সহজ হতে পারে।

    যদি আপনি জোরো কোডের বাইরে খারাপ ঠিকানাটি নরমালাইজারের মাধ্যমে ফিল্টার করতে পারেন তবে এটি সত্যই সহায়তা করবে। তবে আমি দেখতে পাই না যে নরমালাইজারের কাছে ম্যাচের স্কোর বা রেটিংয়ের মতো কিছু রয়েছে।

  2. একই আলোচনার থ্রেডে geocode_addressআরও তথ্য দেখানোর জন্য একটি ডিবাগ সুইচ উল্লেখ করেছে mentioned নোডের geocode_addressস্বাভাবিককরণের ঠিকানা ইনপুট দরকার।

  3. জিওকডার নির্ভুল ম্যাচের জন্য দ্রুত তবে জটিল ক্ষেত্রে আরও বেশি সময় নেয়। আমি সেখানে একটি প্যারামিটার পেয়েছি restrict_regionএবং ভেবেছিলাম যে এটি ফলহীন অনুসন্ধানকে সীমাবদ্ধ রাখবে যদি আমি সীমাটি রাষ্ট্র হিসাবে নির্ধারণ করি তবে আমি নিশ্চিত যে এটি কোন রাজ্যে আসবে। কোনও ভুল অবস্থানে সেট করার ফলে জিওকোড পাওয়া বন্ধ হয় নি ge সঠিক ঠিকানা, যদিও এটি কিছুটা সময় নেয়।

    সুতরাং সম্ভবত প্রথম সন্ধানটির মিল না থাকলে জিওকডার সমস্ত সম্ভাব্য জায়গাগুলিতে সন্ধান করবে। এটি কিছু ত্রুটি দিয়ে ইনপুট প্রক্রিয়া করতে সক্ষম করে তোলে, তবে কিছু অনুসন্ধান খুব ধীর করে তোলে।

    আমি মনে করি ত্রুটিযুক্ত ইনপুট গ্রহণ করার জন্য একটি ইন্টারেক্টিভ পরিষেবার পক্ষে এটি ভাল তবে আমরা কখনও কখনও ব্যাচের জিওকোডিংয়ে আরও ভাল পারফরম্যান্স পেতে ভুল ঠিকানার একটি ছোট সেট ছেড়ে দিতে চাই।


আপনি restrict_regionসঠিক স্থিতি স্থাপনের সময়সীমার উপর কী প্রভাব পড়েছিল ? এছাড়াও, উপরে পোস্ট করা পোস্ট-ব্যবহারকারীদের থ্রেড থেকে, তারা উল্লেখ করেছে 1020 Highway 20যে আমি ঠিক তেমন ঠিকানাগুলির সাথেও সমস্যা ছিল।
aaryno

সঠিক অবস্থা নির্ধারণ করা সম্ভবত উন্নতি করতে পারে না, কারণ ঠিকানাটি ভালভাবে ফর্ম্যাট করা থাকলে জিওকোডার যেভাবেই রাজ্যটি পেতে পারেন।
dracodoc

1

আমি এই উত্তরটি পোস্ট করতে যাচ্ছি তবে আশা করি অন্য কোনও অবদানকারী নীচের বিষয়গুলি ভাঙ্গতে সহায়তা করবে যা আমি মনে করি আরও সুসংগত ছবি আঁকবো:

জিওকোডিংয়ে বোঝা রাষ্ট্রের সংখ্যা কী হবে? আমি সমস্ত 50 পেয়েছি এবং আমি @ এলআর 1234567 (অর্থাত্ প্রতি 8x সময় geocode) এর চেয়ে অনেক কম পারফরম্যান্স দেখছি ।

বাল্ক জিওকোডিংয়ের সবচেয়ে কার্যকর পদ্ধতি কোনটি? আমি একটি সিরিয়াল প্রক্রিয়া চালাচ্ছি, পুরো ব্যাকলোড শেষ না হওয়া পর্যন্ত বারবার 100 টি ব্যাচ চালাচ্ছি। একটি বহু-থ্রেড পদ্ধতির পছন্দনীয় হবে তবে কী পদ্ধতির প্রস্তাব দেওয়া হচ্ছে?

পোস্টগ্রেএসকিউএল জিওকোডিংয়ে ভার্চুয়ালাইজেশনের প্রভাব কী? আমি কিছু অন্যান্য পোস্টের উপর ভিত্তি করে 10% অনুমান করছি, তবে সেই উত্তরের উপর খুব কম আস্থা আছে

এখন আমার উত্তর, যা কেবল একটি উপাখ্যান:

আমি যে সেরাটি পাচ্ছি (একক সংযোগের ভিত্তিতে) প্রতি 208 এমএস গড়ে geocodeএটি আমার ডেটাसेट থেকে এলোমেলোভাবে ঠিকানাগুলি নির্বাচন করে পরিমাপ করা হয়, যা পুরো মার্কিন জুড়েই প্রসারিত। এটিতে কিছু নোংরা ডেটা রয়েছে তবে দীর্ঘকাল ধরে চলমান geocodeগুলি সুস্পষ্ট উপায়ে খারাপ বলে মনে হয় না ।

এর সংক্ষিপ্তসারটি হ'ল আমি সিপিইউ আবদ্ধ এবং একক ক্যোয়ারী একটি একক প্রসেসরের সাথে আবদ্ধ। তত্ত্বের টেবিলের UPDATEপরিপূরক বিভাগগুলিতে ঘটে যাওয়া একাধিক সংযোগ চলার সাথে আমি এটি সমান্তরাল করতে পারি addresses_to_geocode। ইতিমধ্যে, আমি geocodeদেশব্যাপী ডেটাসেটে গড়ে 208 এমএস নেব। বিতরণটি আমার বেশিরভাগ ঠিকানা যেখানে রয়েছে এবং যেখানে তারা কতক্ষণ নিচ্ছে (যেমন, উপরের হিস্টোগ্রামটি দেখুন) এবং নীচের টেবিল উভয় ক্ষেত্রেই অঙ্কিত হয়।

আমার এখন পর্যন্ত সর্বোত্তম পন্থা হ'ল 10000 ব্যাচে এটি করা, প্রতি ব্যাচে আরও কিছু করা থেকে অনুমানযোগ্য উন্নতি সহ। 100 ব্যাচের জন্য আমি প্রায় 251ms পেয়েছিলাম, 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

এটি প্রায় 4x হিসাবে দ্রুত যেমন আমি একবারে তাদের একটি রেকর্ড করি। আমি যখন তাদের একবারে করি তখন আমি রাষ্ট্রের মাধ্যমে একটি ব্রেকডাউন পেতে পারি (নীচে দেখুন)। আমি এক এবং একাধিক টিআইজিআর রাজ্যের কোনও খারাপ বোঝা বা সূচক ছিল কিনা তা যাচাই করার জন্য আমি এটি করেছি, যার ফলস্বরূপ আমি 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
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.