PostGIS가 올바른 형식의 주소를 지오 코딩하는 데 얼마나 빠릅니까?

PostGIS가 올바른 형식의 주소를 지오 코딩하는 데 얼마나 빠릅니까?

PostgreSQL 9.3.7 및 PostGIS 2.1.7을 설치하고 국가 데이터와 모든 주 데이터를로드했지만 지오 코딩이 예상보다 훨씬 느리다는 것을 알았습니다. 기대치를 너무 높게 설정 했습니까? 초당 평균 3 개의 개별 지오 코드가 표시됩니다. 나는 약 5 백만을해야하며 이것을 위해 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 / 초

다음과 같은 문장으로 지오 코드를 한 번에 하나씩 수행하여 내 주소를 파헤 치면 (아래 예제는 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 배) 쿼리 시간의 분포를 볼 수 있으며이를 가장 느리게하는 소수의 긴 쿼리임을 알 수 있습니다 (5 백만의 처음 2600 만 조회 시간이 있음). 즉, 상위 10 %는 평균 약 100ms, 하위 10 % 평균 3.69 초, 평균은 754ms, 중앙값은 340ms입니다.

# 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,"'))")

여기서 myAddressA는 [Address], [City], [ST] [Zip]비 PostgreSQL을 데이터베이스에서 사용자 주소 테이블에서 컴파일 된 문자열.

pagc_normalize_address확장 프로그램 을 설치하려고했지만 실패 했지만 이것이 내가 원하는 종류의 개선을 가져올 것이라는 것은 확실하지 않습니다. 제안에 따라 모니터링 정보를 추가하도록 편집

공연

하나의 CPU가 페깅됩니다. [편집, 쿼리 당 하나의 프로세서 만 있으므로 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

하나의 프로세스가 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 에서 더 나은 고장보기

나는 이것을 실험하는 데 많은 시간을 보냈다. 각도가 다르기 때문에 별도로 게시하는 것이 좋습니다.

이것은 정말 복잡한 주제입니다. 지오 코딩 서버 설정 및 사용한 스크립트 에 대한 내 블로그 게시물에서 자세한 내용을 참조하십시오 . 여기에 간단한 요약이 있습니다.

2 개 상태 데이터 만있는 서버는 항상 50 개 상태 데이터가 모두로드 된 서버보다 빠릅니다.

다른 시간과 두 개의 다른 Amazon AWS 서버에서 내 홈 PC로 이것을 확인했습니다.

2 개 상태 데이터가있는 AWS 프리 티어 서버는 1G RAM 만 있지만 1000 개의 레코드와 45,000 개의 레코드가있는 데이터에 대해 43 ~ 59ms의 일관된 성능을 제공합니다.

모든 상태가로드되고 정확히 동일한 스크립트 및 데이터가있는 8G RAM AWS 서버에 대해 정확히 동일한 설정 절차를 사용했으며 성능은 80 ~ 105ms로 떨어졌습니다.

내 이론은 지오 코더가 주소를 정확하게 일치시킬 수 없을 때 검색 범위를 넓히고 우편 번호 또는 도시와 같은 일부 부분을 무시하기 시작했다는 것입니다. 지오 코드 문서는 3000 밀리 초가 걸렸지 만 잘못된 우편 번호로 주소를 다시 복제 할 수 있다고 자랑합니다.

2 개 상태 데이터 만로드하면 서버는 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 개 상태의 풀 스케일 서버는 불량한 형태의 데이터에 대한 기본 구성으로 320ms를 사용했으며 2G shared_buffer, 5G 캐시를 사용하여 185ms로 개선했으며 해당 게시물에 따라 조정 된 대부분의 설정으로 100ms 더갔습니다.

이것은 postgis와 더 관련 이 있으며 설정은 비슷해 보입니다.

각 커밋의 배치 크기는 내 경우에별로 중요하지 않았습니다. 지오 코드 문서는 배치 크기 3을 사용했습니다. 1, 3, 5에서 10에서 10까지의 값을 실험했습니다. 이것과 큰 차이는 없었습니다. 배치 크기가 작을수록 커밋과 업데이트가 더 많아 지지만 실제 병목이 여기에 없다고 생각합니다. 실제로 배치 크기 1을 사용하고 있습니다. 예기치 않은 잘못된 주소가 항상 예외를 발생시키기 때문에 전체 배치를 무시하고 오류로 설정하고 나머지 행을 진행합니다. 배치 크기 1을 사용하면 무시 된 것으로 표시된 배치에서 가능한 양호한 레코드를 지오 코딩하기 위해 두 번째로 테이블을 처리 할 필요가 없습니다.

물론 이것은 배치 스크립트의 작동 방식에 따라 다릅니다. 자세한 내용은 나중에 스크립트를 게시하겠습니다.

사용에 적합한 주소를 정규화하여 잘못된 주소를 필터링 할 수 있습니다. 누군가가 이것을 어딘가에서 언급하는 것을 보았지만 정규화 함수가 형식으로 만 작동하기 때문에 이것이 어떻게 작동하는지 잘 모르겠습니다. 어떤 주소가 유효하지 않은지를 실제로 말할 수는 없습니다.

나중에 주소의 모양이 잘못되어 건너 뛰고 싶다면 도움이 될 수 있음을 깨달았습니다. 예를 들어 거리 이름이나 거리 이름이 누락 된 많은 주소가 있습니다. 모든 주소를 먼저 정규화하면 비교적 빠르며, 잘못된 주소를 필터링 한 다음 건너 뛸 수 있습니다. 그러나 거리 번호 또는 거리 이름이없는 주소는 여전히 거리 또는 도시에 매핑 될 수 있기 때문에 내 사용법에 적합하지 않으며 그 정보는 여전히 나에게 유용합니다.

필자의 경우 지오 코딩 할 수없는 대부분의 주소는 실제로 모든 필드를 가지고 있지만 데이터베이스에는 일치하지 않습니다. 이 주소를 정규화하여 필터링 할 수는 없습니다.

편집 자세한 내용은 지오 코딩 서버 설정 및 사용한 스크립트 에 대한 내 블로그 게시물을 참조하십시오 .

편집 2 200 만 개의 주소를 지오 코딩하고 지오 코딩 결과를 기반으로 주소를 정리했습니다. 입력이 더 깨끗해지면 다음 배치 작업이 훨씬 더 빠르게 실행됩니다. 깨끗하다는 것은 일부 주소가 분명히 잘못되어 지오 코더가 지오 코딩에 문제를 일으킬 수있는 예상치 못한 콘텐츠가 있거나 지워 졌음을 의미합니다. 내 이론은 : 잘못된 주소를 제거하면 캐시가 엉망이되지 않도록하여 좋은 주소의 성능을 크게 향상시킵니다.

모든 작업이 RAM에 캐시 된 지오 코딩에 필요한 모든 데이터를 가질 수 있도록 상태에 따라 입력을 분리했습니다. 그러나 작업의 모든 잘못된 주소는 지오 코더가 더 많은 상태를 검색하도록하여 캐시를 망칠 수 있습니다.

1. 이 토론 스레드 에 따르면 Tiger 데이터와 입력 주소를 처리하기 위해 동일한 정규화 절차를 사용해야합니다. Tiger 데이터는 내장 노멀 라이저로 처리되었으므로 내장 노멀 라이저 만 사용하는 것이 좋습니다. pagc_normalizer가 작동하더라도 Tiger 데이터를 업데이트하는 데 사용하지 않으면 도움이되지 않을 수 있습니다.

   즉, geocode ()는 어쨌든 노멀 라이저를 호출하므로 지오 코딩 전에 주소를 표준화하면 실제로 유용하지 않을 수 있습니다. 노멀 라이저의 한 가지 가능한 사용법은 표준화 된 주소와 geocode ()에 의해 리턴 된 주소를 비교할 수 있습니다. 둘 다 정규화되면 잘못된 지오 코딩 결과를 찾기가 더 쉬울 수 있습니다.

   노멀 라이저로 지오 코드에서 잘못된 주소를 필터링 할 수 있다면 실제로 도움이됩니다. 그러나 노멀 라이저에는 일치 점수 또는 등급과 같은 것이 없습니다.

2. 동일한 토론 스레드에서도 geocode_address자세한 정보를 표시하기 위해 디버그 스위치를 언급했습니다 . 노드 geocode_address는 정규화 된 주소 입력이 필요합니다.

3. 지오 코더는 정확한 일치를 위해 빠르지 만 어려운 경우에는 훨씬 더 많은 시간이 걸립니다. 매개 변수 restrict_region가 있으며 어떤 상태에 있는지 확실하지 않기 때문에 제한을 상태로 설정하면 결과가없는 검색을 제한 할 것이라고 생각했습니다. 잘못된 상태로 설정하면 지오 코드가 중지되지 않았습니다. 시간이 걸리더라도 올바른 주소입니다.

   따라서 첫 번째 정확한 검색이 일치하지 않으면 지오 코더가 가능한 모든 위치를 볼 수 있습니다. 이로 인해 오류가 발생하여 입력을 처리 할 수 ​​있지만 검색 속도가 매우 느려집니다.

   대화 형 서비스가 오류가있는 입력을 받아들이는 것이 좋지만 때로는 배치 지오 코딩에서 더 나은 성능을 얻기 위해 작은 잘못된 주소 집합을 포기하고 싶을 수도 있습니다.

이 답변을 게시 할 예정이지만 다른 기고자가 다음을 분석하는 데 도움이되기를 바랍니다. 더 일관성있는 그림을 그릴 것입니다.

지오 코딩에로드 된 상태 수의 영향은 무엇입니까? 나는 50을 모두 얻었고 @ LR1234567보다 성능이 훨씬 낮습니다 (즉, 8x time per per geocode).

대량 지오 코딩을위한 가장 효율적인 방법은 무엇입니까? 전체 백로드가 완료 될 때까지 일련의 100을 반복적으로 실행하는 직렬 프로세스를 실행하고 있습니다. 다중 스레드 방식이 바람직하지만 어떤 방식이 권장됩니까?

PostgreSQL 지오 코딩에 대한 가상화의 영향은 무엇입니까? 다른 게시물을 기준으로 10 %를 추측하고 있지만 그 대답에 대해서는 거의 확신이 없습니다.

이제 내 대답은 일화입니다.

하나의 연결을 기반으로하는 가장 좋은 것은 평균 208ms입니다 geocode. 이것은 내 데이터 세트에서 무작위로 주소를 선택하여 측정되며 미국 전역으로 확장됩니다. 더러운 데이터가 포함되어 있지만 가장 오래 실행되는 데이터 는 명백한 방식 geocode으로 나쁘지 않은 것으로 보입니다 .

요점은 내가 CPU에 바인딩되어 있고 단일 쿼리가 단일 프로세서에 바인딩되어있는 것입니다. 이론적으로 테이블 UPDATE의 보완 세그먼트에서 여러 연결을 실행하여 병렬화 할 수 있습니다 addresses_to_geocode. 그 동안 geocode전국 데이터 세트에서 평균 208ms 가 소요됩니다. 분포는 내 주소의 대부분이 어디에서 왔으며 얼마나 오래 걸리는가 (예 : 위의 히스토그램 참조)와 아래 표에서 비뚤어집니다.

지금까지 내 최선의 접근 방식은 배치 당 10000 회를 처리하는 것입니다. 100의 배치에 대해 약 251ms, 10000으로 208ms를 얻었습니다.

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