Як швидко я повинен очікувати, що PostGIS геокодувати добре відформатовані адреси?


17

Як швидко я повинен очікувати, що PostGIS геокодувати добре відформатовані адреси?

Я встановив PostgreSQL 9.3.7 та PostGIS 2.1.7, завантажив дані нації та дані про всі стани, але встановив, що геокодування значно повільніше, ніж я передбачав. Чи я поставив свої очікування занадто високими? Я отримую в середньому 3 окремих геокоди за секунду. Мені потрібно зробити близько 5 мільйонів, і я не хочу чекати цього на три тижні.

Це віртуальна машина для обробки гігантських R матриць, і я встановив цю базу даних збоку, щоб конфігурація могла виглядати трохи глухо. Якщо допоможе істотна зміна в конфігурації VM, я можу змінити конфігурацію.

Технічні характеристики

Пам'ять: 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файлі приблизно 1/4 доступної оперативної пам’яті та ефективного розміру кешу до 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 / сек

Коли я копаюсь до моїх адрес, роблячи геокоди по одному із заявою, яке виглядає приблизно так (btw, приклад нижче займав 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 рази на запис), але я можу подивитися на розподіл разів запитів і побачити, що це меншість тривалих запитів, які сповільнюють це найбільше (лише перші 2600 з 5 мільйонів мають час пошуку). Тобто верхні 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

Зразок дискової активності на розділі даних, тоді як один процесор прив’язаний до 100%: [редагувати: цим запитом використовується лише один процесор]

# 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


1
Що робить машина під час запуску запитів? Він блокується на IO чи це вузьке місце десь ще?
til_b

1
Скільки штатів ви завантажили. Я, як правило, колись від 30 мс - 150 мс на адресу на 64-бітному вікні Windows з 4–8 ГБ оперативної пам’яті. Зазвичай, хоча я працюю лише з 1 або 2 станами. Не було зроблено орієнтир щодо впливу більшої кількості держав на продуктивність.
LR1234567

@ LR1234567 50 держав
aaryno

1
@til_b процесора штучно підтримується на рівні 99,7%
aaryno

Це здається, що ми просто чекатимемо пару тижнів, які знадобляться, щоб закінчити цю справу, оскільки це разова річ і що у нас залишиться багато соку, як тільки це буде зроблено, щоб не відставати від 100 адрес / день завантаження. ми переживаємо. Я буду тримати це відкритим, поки ми не закінчимо, якщо вийде щось справді переконливе, що дозволяє нам обійти наші прив’язані процесори.
aaryno

Відповіді:


7

Я витратив багато часу на експерименти з цим, я думаю, що краще розмістити повідомлення окремо, оскільки вони є з іншого кута.

Це дійсно складна тема, див. Докладнішу інформацію в моєму блозі про налаштування сервера геокодування та сценарій, який я використовував . Ось лише короткі підсумки:

Сервер із лише двома даними про стан завжди швидший, ніж сервер, завантажений усіма 50 станами даних.

Я перевірив це своїм домашнім ПК у різні часи та двома різними серверами Amazon AWS.

Мій сервер вільного ярусу AWS з даними двох станів має лише 1G оперативної пам’яті, але він має стабільну продуктивність 43 ~ 59 мс для даних із 1000 записами та 45000 записами.

Я використовував таку саму процедуру настройки для 8G RAM-сервера AWS з усіма завантаженими станами, точно такий же сценарій та дані, і продуктивність знизилася до 80 ~ 105 мс.

Моя теорія полягає в тому, що коли геокодер не може точно відповідати адресу, він почав розширювати діапазон пошуку та ігнорувати якусь частину, наприклад, поштовий індекс або місто. Ось чому документ з геокодом може похвалитися тим, що він може повторно переглядати адресу з неправильним поштовим індексом, хоча це зайняло 3000 мс.

Завантажені лише дані про 2 стани, сервер забирає набагато менше часу на безрезультатний пошук або матч з дуже низькою оцінкою, оскільки він може шукати лише у двох станах.

Я спробував обмежити це, встановивши 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 conf.

Звичайний підозрюваний у встановленні відсутніх індексів, вакуумний аналіз для мене не змінився, тому що сценарій завантаження вже зробив необхідне обслуговування, якщо ви не заплуталися з ними.

Однак встановлення postgre conf відповідно до цієї публікації допомогло. Мій повномасштабний сервер із 50 станами мав 320 мс із конфігурацією за замовчуванням для деяких гірших форм даних, він покращився до 185 мс із 2G спільним_буфером, кешем 5G і пішов до 100 мс далі з більшістю налаштувань, налаштованих відповідно до цієї публікації.

Це більше стосується постгігів і їх налаштування здавалося схожими.

Розмір партії кожного комітету не мав великого значення для мого випадку. Документація про геокод використовувала пакетний розмір 3. Я експериментував зі значеннями від 1, 3, 5 до 10. Я не знайшов суттєвої різниці в цьому. З меншим розміром партії ви робите більше комісій та оновлень, але, думаю, справжньої горловини пляшки тут немає. Насправді я зараз використовую партію розміром 1. Оскільки завжди є якась несподівана неправильно сформована адреса, спричинить виняток, я встановлю всю партію з помилкою як ігноровану та продовжую залишати рядки. При розмірі партії 1 мені не потрібно вдруге обробляти таблицю для геокодування можливих хороших записів у партії, позначених як ігноровані.

Звичайно, це залежить від того, як працює ваш пакетний сценарій. Свій сценарій з більш детальною інформацією я опублікую пізніше.

Ви можете спробувати використати нормалізовану адресу для фільтрації поганої адреси, якщо вона відповідає вашому використанню. Я бачив, як хтось десь згадав про це, але я не був впевнений, як це працює, оскільки функція нормалізації працює лише у форматі, вона не може насправді сказати, яка адреса недійсна.

Пізніше я зрозумів, що якщо адреса в явно поганій формі, і ви хочете їх пропустити, це може допомогти. Наприклад, у мене багато адрес, на яких відсутня назва вулиці або навіть назви вулиць. Нормалізація всіх адрес спочатку буде відносно швидкою, потім ви можете відфільтрувати очевидну погану адресу, а потім пропустити їх. Однак це не відповідало моєму використанню, оскільки адреса без номера вулиці чи навіть назви вулиці все ще може бути відображена на вулицю чи місто, і ця інформація для мене все ще корисна.

І більшість адрес, які не можна геокодувати в моєму випадку, насправді містять усі поля, просто в базі даних немає відповідності. Ви не можете фільтрувати ці адреси, лише нормалізуючи їх.

EDIT Детальніше див. У моєму дописі про налаштування сервера геокодування та сценарій, який я використовував .

EDIT 2 Я закінчив геокодування 2 мільйони адрес і багато очистив адреси на основі результатів геокодування. З кращим очищеним входом наступна партійна робота працює набагато швидше. Під чистим я маю на увазі, що деякі адреси, очевидно, помиляються, і їх слід видалити, або вони мають несподіваний вміст для геокодера, щоб викликати проблеми в геокодування. Моя теорія полягає в тому, що, якщо видалити погані адреси, можна уникнути псування кешу, що значно покращить продуктивність на хороших адресах.

Я розділив вхід на основі стану, щоб переконатися, що кожна робота може мати всі дані, необхідні для геокодування, кешованого в оперативній пам'яті. Однак кожна погана адреса в роботі змушує геокодер шукати в інших штатах, що може зіпсувати кеш.


Великий відгук. У моєму вікні, як це буває, фільтрація на стан прискорює матч приблизно на 50 (!), Але я підозрюю, що у мене можуть виникнути проблеми з індексом.
АКО

2
  1. Згідно з цією дискусійною темою , ви повинні використовувати ту саму процедуру нормалізації для обробки даних Тигра та вашої вхідної адреси. Оскільки дані Тигра обробляються за допомогою вбудованого нормалізатора, краще використовувати лише вбудований нормалізатор. Навіть якщо ви працюєте з pagc_normalizer, він може не допомогти вам, якщо ви не використовуєте його для оновлення даних про Tiger.

    Зважаючи на це, я думаю, що геокод () все одно викликатиме нормалізатор, тому нормалізація адреси до геокодування може бути не дуже корисною. Одне можливе використання нормалізатора може порівняти нормалізовану адресу та адресу, повернуту геокодом (). З ними обидва нормалізуються, може бути простіше знайти неправильний результат геокодування.

    Якщо ви можете відфільтрувати неправильну адресу з геокоду за допомогою нормалізатора, це дійсно допоможе. Однак я не бачу, що нормалізатор має щось подібне до матчу чи рейтингу.

  2. Цей же дискусійний потік також згадав про перемикач налагодження, geocode_addressщоб показати більше інформації. Вузолgeocode_address потребує нормалізованого введення адреси.

  3. Геокодер швидкий для точної відповідності, але потребує набагато більше часу для складних випадків. Я виявив, що є параметрrestrict_region і подумав, що, можливо, це обмежить безрезультатний пошук, якщо я встановлю обмеження як стан, оскільки я впевнений, у якому стані він буде. Виявилося, встановивши його на неправильний стан, не зупинив геокод, щоб отримати правильна адреса, хоча це потребує певного часу.

    Тож, можливо, геокодер буде шукати у всіх можливих місцях, якщо перший точний пошук не відповідає. Це робить його можливим обробляти вхід з деякими помилками, а також робити пошук дуже повільним.

    Я думаю, що для інтерактивного сервісу добре приймати введення з помилками, але іноді ми можемо захотіти просто відмовитися від невеликого набору неправильних адрес, щоб мати кращі показники в пакетному геокодування.


Який вплив було restrict_regionна час, коли ви встановили правильний стан? Також із потоку користувачів postgis, про який ви посилаєтесь вище, вони згадують, що виникають проблеми з адресами, з 1020 Highway 20якими я також стикався.
ааріно

Встановлення правильного стану, ймовірно, не покращиться, оскільки, якщо адреса буде добре відформатована, геокодер може в будь-якому разі отримати стан.
dracodoc

1

Я збираюся опублікувати цю відповідь, але, сподіваюся, інший довідник допоможе розбити наступне, що, на мою думку, намалює більш цілісну картину:

Який вплив має кількість держав, завантажених на геокодування? У мене все 50, і я бачу набагато нижчу продуктивність, ніж @ LR1234567 (тобто 8 разів на одиницю geocode).

Який найефективніший метод масового геокодування? Я запускаю послідовний процес, запускаю партії по 100 повторно, поки не завершиться все завантаження. Багатопотоковий підхід був би кращим, але які підходи рекомендуються?

Який вплив віртуалізації на геокодування PostgreSQL? Я здогадуюсь 10% на основі деяких інших публікацій, але я мало впевнений у цій відповіді

Тепер моя відповідь, яка є лише анекдотом:

Найкраще, що я отримую (на основі одного з'єднання) - це в середньому 208 мс на рік geocode. Це вимірюється шляхом вибору випадковим чином з мого набору даних, який поширюється в США. Вона включає деякі брудні дані, але найдовші запуски geocodeне здаються поганими .

Суть її в тому, що я, здається, пов'язаний з процесором і що один запит пов'язаний з одним процесором. Я можу паралелізувати це, маючи теоретично декілька з'єднань, що 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

Це приблизно в 4 рази так швидко, як якщо б я робив їх по одній записи за один раз. Коли я роблю їх по одному, я можу отримати розбивку за станом (див. Нижче). Я зробив це, щоб перевірити, чи є у одного або декількох станів 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.