나는 과거에 많은 관계형 데이터베이스를 사용해 왔지만 모든 NoSQL 데이터베이스에 대해서도 읽었으며 Key-Value 저장소는 방해하는 것처럼 보입니다.
기하학적 객체를 저장할 때 주로 5 개의 색인화 된 열 ID, MIN_X, MAX_X, MIN_Y 및 MAX_Y를 사용합니다 (여기서 X 및 Y는 맵 투영에 있음). 다른 데이터에 대한 색인이 필요하지 않습니다.
지정된 위치 (지도 사각형)에서 객체를 조회하려면 X 및 Y 값이 필요하며 지정된 객체를 업데이트하려면 ID 값이 필요합니다.
이를 위해 키-값 저장소를 사용할 수있는 방법이 있습니까?
답변:
Google AppEngine을 사용하여 공간 / 속성 쿼리를 실행하고 주요 문제 (첫날부터)는 임의 크기의 선 / 다각형을 대규모로 색인화하는 방법입니다. 점 데이터는 그리 어렵지 않지만 (geohash, geomodel 등 참조) 무작위로 군집 된 작은 / 대형 다각형 세트는 항상 문제였습니다 (일부 경우 여전히)
GAE에서 여러 버전의 공간 색인 작성을 시도했지만 대부분 아래 두 가지 변형입니다. SQL 데이터베이스만큼 빠르지는 않았으며 모두 장단점이 있습니다. 그러나 대부분의 인터넷 기반 매핑 응용 프로그램에는 이러한 단점이 합리적으로 보입니다. 또한 최종 검색 매개 변수에 맞지 않는 피처를 제거하려면 아래 두 개를 인 메모리 지오메트리 컬링 (JTS 등을 통해)과 결합해야합니다. 마지막으로 GAE 관련 기능에 의존하지만 다른 아키텍처에도 적용될 수 있습니다 (또는 TyphoonAE를 사용하여 Linux 클러스터, ec2 등에서 실행).
그리드 -특정 영역의 모든 기능을 알려진 그리드 인덱스로 압축합니다. 그리드에 작은 공간 인덱스를 배치하여 포함 된 기능 세트를 빠르게 탐색하십시오. 대부분의 쿼리에서는 정확한 그리드 명명 규칙과 K / V 엔터티와의 관계 (쿼리가 아닌 가져 오기)를 알고 있으므로 몇 개의 그리드 만 가져와야합니다.
장점 -매우 빠르며 구현이 쉽고 메모리 풋 프린트가 없습니다.
단점 -전처리가 필요하고 사용자가 그리드 크기를 결정해야하며 큰 지오메트리가 여러 그리드에서 공유되며 클러스터링으로 인해 그리드가 과부하 될 수 있으며 직렬화 / 직렬화 해제 비용이 문제가 될 수 있습니다 (프로토콜 버퍼를 통해 압축 된 경우에도)
QuadKeys- 현재 구현입니다. 그리드 레벨 설정이 없다는 점을 제외하면 기본적으로 그리드와 동일합니다. 기능이 추가됨에 따라 경계가 완전히 포함 된 쿼드 키 그리드에 의해 색인화됩니다 (또는 경우에 따라 단일 쿼드 키를 사용할 수없는 경우 날짜 표시 줄을 생각하면 2 개로 분할 됨). qk를 찾은 후에는 피처의 미세한 입자 표현을 제공하는 더 작은 qk의 최대 수로 분할됩니다. 그런 다음 해당 기능에 대한 포인터 / 상자는 쿼리 할 수있는 경량 그리드 인덱스 (기능 그룹)로 압축됩니다 (원래 디자인에서 기능을 직접 쿼리했지만 결과 세트가 큰 경우 CPU 속도가 너무 느림)
폴리 라인 쿼드 키 http://www.arc2earth.com/images/help/GAE_QKS_1.png 폴리곤 쿼드 키 http://www.arc2earth.com/images/help/GAE_QKS_2.png
위에서 사용 된 쿼드 키 명명 규칙은 잘 알려져 있으며 더 중요한 것은 지역성을 유지하는 경향이 있습니다 ( 여기에 설명 됨 ).
위의 다각형은 다음과 같습니다.
쿼리 범위가 충분히 작 으면 qk를 통해 직접 가져올 수 있습니다. 이것은 GAE datatore에 대한 유일한 단일 배치 rpc 호출이므로 최적입니다. 범위가 너무 커서 가능한 qks (> 1000)가 너무 많으면 필터를 사용하여 쿼리 할 수도 있습니다 (예 : qk> = 0320101013 및 qk <= 0320101013 + \ ufffd). 쿼드 키 명명 규칙과 GAE가 문자열을 색인하는 방식은 위의 쿼리 가 해당 qk 값 아래로 떨어지는 기존 그리드 만 가져올 수 있도록합니다 .
다른 경고 및 성능 문제가 있지만 일반적으로 쿼드 키를 쿼리하는 기능은이를 가능하게합니다.
예-미국 카운티 쿼리 : geojson
장점 -매우 빠름, 그리드 크기 구성 없음, 메모리 풋 프린트 없음, 과밀 한 그리드 없음
단점 -전처리 필요, 일부 시나리오에서 가능한 오버 페치, 극좌표 데이터 없음
공간 채우기 곡선 - 올해 Google I / O 에서 Alfred의 NextGen Queries 강연 을 살펴보십시오 . 새로운 MultiQuery 연산자 (병렬로 실행)와 함께 일반 공간 / 시간 채우기 곡선을 포함하면 정말 멋진 공간 쿼리가 가능합니다. 전통적인 SQL 성능을 능가할까요? 말하기는 어렵지만 실제로 확장해야합니다. 또한 모든 형태 / 크기의 항상 사용되는 모바일 장치가 사이트 / 서비스에 대한 트래픽을 크게 증가시키는 미래에 빠르게 접근하고 있습니다.
마지막으로, NoSQL over SQL을 선택하기 전에 문제 영역을 면밀히 검토해야한다는 데 동의합니다. 우리의 경우 GAE의 가격 책정 모델을 정말로 좋아했기 때문에 선택의 여지가 없었지만 확장 할 필요가 없다면 시간을 절약하고 표준 SQL DB를 사용하십시오.
위치 기반 데이터를위한 CouchDB의 구현 인 GeoCouch에 대해 들었습니다. 또한 MongoDB에는 지형 공간 인덱싱 기능이 있다고 생각합니다.
이것은 주로 알고리즘에 관한 질문입니다. 스택 오버플로는 요청하기에 좋은 장소 일 수도 있습니다.
어쨌든 직접적인 질문에 대한 대답은 "그렇습니다. 공간 데이터를 나타 내기 위해 kvp 저장소를 사용할 수 있습니다"입니다. 그러나 더 좋은 질문은 "공간 데이터를 표현하기 위해 kvp 저장소를 사용해야합니까?"일 수 있습니다.
그 질문에 대한 답은 (다른 많은 사람들과 마찬가지로) "의존"입니다. 규모, (트랜잭션) 작업 부하, 데이터의 특성 및 처리 인프라에 따라 다릅니다.
kvp 저장소는 오버 헤드가 적으므로 대량의 삽입 및 업데이트 병렬 처리에 대한 처리량을 높일 수 있습니다. 그러나 공간 검색을 수행하는 것은 그리 빠르지 않습니다 (사각형 내의 모든 객체 찾기). 이를 위해 R-Tree와 같은 공간 인덱스가 필요합니다.
그러나 데이터 볼륨이 매우 크고 컴퓨터 클러스터가 크면 kvp 인덱스를 사용하면 약간의 이점을 얻을 수 있습니다. 실제로 확실하게 알 수있는 유일한 방법은 실제 데이터를 사용하여 성능을 측정하고 발생할 것으로 예상되는 패턴에 액세스하는 것입니다.
업데이트 :
여기 좀 더 자세한 정보가 있습니다. KVP 저장소를 사용하여 공간 조회를 수행 할 수 있습니다. 문제는 느리다는 것입니다. 이유를 보려면 다음과 같은 것을 고려하십시오.
***********
***********
***********
***********
****###****
****###****
****###****
***********
***********
***********
***********여기서 *와 #은 왼쪽 상단에 원점이있는 11x11 그리드로 배치 된 객체를 나타냅니다. 사각형 (4,4)-(7,7) 내에서 객체를 검색한다고 상상해보십시오. 모든 "#"을 찾아야합니다. b + -tree를 사용하여 KVP 저장소에서 인덱스를 나타내는 경우 "X"인덱스 또는 "Y"인덱스를 사용하여 결과를 찾을 수 있습니다. 이 경우 어느 것이 중요하지 않습니다. 설명을 위해 x 인덱스를 사용하겠습니다. X 인덱스에서 log (n) 조회를 수행하여 X 값이 "4"인 첫 번째 노드를 찾은 다음 값이 7보다 큰 노드를 찾을 때까지 b + 트리 리프 노드를 반복합니다. x 인덱스를 반복하여 원하는 y 범위를 벗어난 것은 거부합니다.
느립니다. 같은 밀도의 100K * 100K의 큰 격자에이를 상상해보십시오. 결국 9 개의 레코드 만 찾기 위해 "300, 000"개의 인덱스 항목을 스캔해야 할 것입니다. 그러나 균형이 잘 잡힌 R-Tree를 사용하는 경우 인덱스 조회는 약 90 개 정도의 레코드 만 스캔하면됩니다. 그것은 큰 차이입니다.
그러나 문제는 R-Tree의 균형을 유지하는 것이 비싸다는 것입니다. 그렇기 때문에 대답은 "의존적"이며 "어떻게해야합니까"라는 질문이 "어떻게해야합니까"보다 훨씬 중요합니다.
레코드를 많이 삽입하고 제거하고 주로 "개체 ID"조회를 수행하고 "공간"조회를 자주 수행하지 않는 경우 KVP 색인을 사용하면 실제로 시스템을 사용하려는 대상에 대한 성능이 향상됩니다 . 그러나 드물게 삽입하거나 삭제하지만 공간 검색을 많이 수행하는 경우 R- 트리를 사용하려고합니다.
위도 / 경도 값을 사용하는 경우 지오 해시 를 상점의 가치 부분으로 사용할 수 있습니다.
다음은 NYC를위한 것입니다. dr5regy6rc6ye
geohash를 사용하면 geohash의 끝에서 문자를 두드리기 시작하여 다양한 정밀도의 격자를 얻을 수 있습니다. http://geohash.org/dr5re
대부분의 경우 키 / 값 또는 키 / 값 / 유형 스토리지보다 관계형 데이터 스토리지에서 더 많은 유틸리티를 얻을 수 있습니다. 이러한 종류의 데이터 체계에 대한 효율적인 쿼리 및보고와 관련하여 상당히 복잡합니다.
내 조언은 사용 방법을 고려하기 전에 스케일에 실제로 NoSQL이 필요한지 여부를 면밀히 평가하는 것입니다.
나는 단지 캐싱 계층으로 키 / 값 저장소를 사용하는 거라고 볼 http://www.membase.org/ 또는 http://wiki.basho.com/display/RIAK/How+Things+Work (riak_kv_cache_backend)
앱 요구에 따라 여전히 데이터에 대한 SQL 액세스 권한을 원할 수 있습니다.
이것은 FOSS4G 컨퍼런스 에서 다가오는 몇 가지 이야기입니다 .