MySQL에서 공간 인덱스를 사용할 때 성능이 좋지 않습니다.

Question

지리 공간이 아니지만 꽤 잘 맞는 데이터 세트를 푸는 실험을 조금하고 있습니다. 결과가 다소 불안정합니다. 데이터 세트는 게놈 데이터이다. 유전자와 같은 요소가 특정 시작 및 중지 좌표 (X 축)를 차지하는 DNA 영역이있는 인간 게놈. 우리는 Y 축을 차지하는 DNA의 여러 영역 (염색체)을 가지고 있습니다. 목표는 하나의 Y 좌표를 따라 두 개의 X 좌표를 교차하는 모든 항목을 다시 가져 오는 것입니다. LineString (시작 1, 끝 2).

이 이론은 소리 같았다 그래서 기존 MySQL 기반의 게놈 프로젝트로 밀어 같은 테이블 구조를 내놓았다 :

CREATE TABLE `spatial_feature` (
    `spatial_feature_id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `external_id` int(10) unsigned NOT NULL, 
    `external_type` int(3) unsigned NOT NULL, 
    `location` geometry NOT NULL, 
    PRIMARY KEY (`spatial_feature_id`), 
    SPATIAL KEY `sf_location_idx` (`location`) 
) ENGINE=MyISAM; 

external_id 우리가이 테이블에 인코딩 한 개체의 식별자를 나타냅니다 & external_type은 원본을 인코딩합니다. 모든 것이 좋게 보였고 나는 잘 작동하는듯한 몇 가지 예비 데이터 (30,000 행)를 넣었습니다. 이 값이 3 백만 행을 초과하면 MySQL은 공간 인덱스 사용을 거부하고 강제로 사용하면 속도가 느려집니다 (전체 테이블 스캔을 사용하는 경우 40 초 vs. 5 초). 더 많은 데이터가 추가되면 인덱스가 사용되기 시작했지만 성능 저하가 지속되었습니다. 인덱스를 강제로 해제하면 쿼리가 8 초가됩니다. 내가 좋아하는 외모를 사용하고 쿼리 :이 들어가

select count(*) 
from spatial_feature 
where MBRIntersects(GeomFromText('LineString(7420023 1, 7420023 1)'), location); 

데이터는 Y 치수에 따라 매우 조밀 수있다 (당신은 모든 건물, 전화 상자, 포스트 박스의 위치를 ​​녹음 한 것처럼 생각하고 매우 긴 길의 비둘기). 필자는 R-Indexes가 Java의 데이터뿐만 아니라이 분야의 다른 사람들과도 어떻게 반응하는지에 대한 테스트를 통해이를 플랫 파일 형식에 적용하여 성공을 이끌어 냈습니다. 그러나 아무도이 테스트의 목표 인 데이터베이스 AFAIK에 적용하지 않았습니다.

특정 축을 따라 크게 다르지 않은 공간 모델에 대량의 데이터를 추가 할 때 비슷한 문제가 발생 했습니까? 좌표 사용을 취소하면 문제가 지속됩니다. 그 원인

• 맥 OS 10.6.6
• 의 MySQL 5.1.46

도움말 있다면 나는 다음과 같은 설정을 실행하는거야!

도를 읽은 후

+----+-------------+-----------------+------+-----------------+------+---------+------+---------+----------+-------------+ 
| id | select_type | table   | type | possible_keys | key | key_len | ref | rows | filtered | Extra  | 
+----+-------------+-----------------+------+-----------------+------+---------+------+---------+----------+-------------+ 
| 1 | SIMPLE  | spatial_feature | ALL | sf_location_idx | NULL | NULL | NULL | 3636060 | 33.33 | Using where | 
+----+-------------+-----------------+------+-----------------+------+---------+------+---------+----------+-------------+ 
1 row in set, 1 warning (0.00 sec) 

재 작성된 SQL이 쿼리의 성능이

가난 왜 여전히 강조하지 다음

select count(0) AS `count(*)` from `arabidopsis_thaliana_core_7_60_9`.`spatial_feature` where intersects(geometryfromtext('LineString(7420023 1, 7420023 1)'),`arabidopsis_thaliana_core_7_60_9`.`spatial_feature`.`location`) 

처럼 보인다

의 설명에서 계획을 가져 기사는 @Fraser가 rickonrails에서 게시 한 것으로서 문제가 메모리에없는 색인과 관련이있는 것처럼 보입니다. 기사에서 언급 한 기술과 유사한 기술을 적용하면 (핵심 버퍼를 매우 크게 만든다) 인덱스 쿼리를 사용하도록 쿼리를 강제 실행합니다. 우리는 여전히 지역 &을 쿼리하는 것 사이의 지연을 보지만 그 지역의 부분 집합을 검색하지만 그것은 모두 인덱스의로드가 올바른지를 가리 킵니다.

이야기의 도덕은 무엇입니까? MySQL의 R- 인덱스는 메모리에 저장 될 때까지 성능이 떨어지며 성능이 뛰어납니다.내가 실제로 원하는 것을위한 좋은 해결책은 아니지만 여전히 MySQL에 흥미로운 각도를 제공합니다.

모든 도움 사람들에게 감사드립니다.

Answer 1

목표는

좌표가 여러 필드 인덱스 재치를 사용하여 생각 해 봤나 하나의 Y 함께 두 개의 X 좌표를 교차하는 모든 항목을 돌아 오게하는 것입니다? 마찬가지로 : 당신이 y 값의 제한된 작업하는 경우

CREATE INDEX spacial_search ON spatial_feature(y, x) 

이는 방식이다.

Answer 2

저는 유전학 학위를 갖고 있으며 프로그래머입니다. X와 Y를 사용하여 명명법을 쓸 필요가 없습니다. 너무 어리석은 ... 시작과 정지가 필요합니다. 직위 (축이 아님) 및 염색체입니다. 먼저 염색체 번호로 색인을 작성한 다음 위치를 색인 한 다음 염색체를 색인화합니다. (질문 : 당신이 개 독서 프레임을 가질 수 진핵 생물 또는 염색체에서 다루고?)

EG : ("X"= 위치와 "Y"= 염색체 곳)

CREATE INDEX spatial_index_1 ON spatial_feature(chromosome, position); 
CREATE INDEX spatial_index_2 ON spatial_feature(position, chromosome); 

덧붙여 염색체는 매우 긴 당신이 할 수있는 문자열 (데이터와 마찬가지로) (블롭 (code gene과 junk DNA 등) 코딩과 같은 것들을 빠르게 처리하기 위해서)

Answer 3

EXPLAIN plan에서 우리는 공간을 쿼리에 사용할 수는 있지만 ('possible_keys' 열), 그것은 사용되지 않습니다 ('키'열에 NULL이 있습니다.) 나는 그것이 자동으로 선택되지 않은 이유를 모르지만, 명시 적으로

select count(*) 
from spatial_feature 
force index (sf_location_idx) -- <== this is the 'force index' clause 
where MBRIntersects(GeomFromText('LineString(7420023 1, 7420023 1)'), location); 

Answer 4

가 확실 관계형 데이터베이스가 갈 수있는 방법입니다 위치 : MySQL의는 '힘 지수'절을 사용하여 쿼리를 지정하여 인덱스를 사용하는 truct? 내가 당신이라면 Solr 또는 Elastic Search에 데이터 세트를 밀어 넣을 것입니다 (다른 곳에서는 마스터 데이터 세트를 저장하는 것이 좋습니다). 이 엔진은 인덱싱을 위해 제작되었으므로 응답 시간의 차이를 알 수 있습니다.