위키데이터/개발/쿼리

This page is a translated version of the page Wikidata/Development/Queries and the translation is 100% complete.

이 노트는 위키데이터의 쿼리가 구현되는 방법을 설명합니다. 쿼리는 다소 큰 주제이기 때문에 이 문서는 불완전하고 더 다듬어야 할 여러 부분이 포함되어 있습니다.

개요

일반적으로 여기에 제시된 버전은 기본적으로 쿼리에 대한 한정자와 참조를 무시하지만 결과 집합에서는 그대로 유지합니다. 그러나 첫 번째 반복에서는 이를 기준으로 제한하거나 정렬하거나 표시하는 것 외에는 아무 것도 할 수 없습니다. 또한 모든 쿼리는 우선 순위가 지정된 문장에 대해서만 수행됩니다. 다른 모든 문은 지금까지 쿼리에 대해 무시됩니다.

위키데이터는 쿼리(Query)를 사용할 수 있고 쿼리결과(QueryResult)를 반환할 수 있습니다. 클라이언트(예를 들어, 위키백과)는 쿼리결과를 차례로 가져와 쿼리결과시각화(QueryResultVisualization)로 전환할 수 있습니다.

쿼리는 다음으로 구성됩니다

쿼리컨셉(QueryConcept) (또는 쿼리 설명, 그러나 개체 설명과 혼동하지 마세요)
선택 요청(SelectionRequest)의 배열 그리고
몇 가지 쿼리옵션(QueryOption): 정렬(Sort), 오프셋(Offset) 및 제한(Limit)

쿼리컨셉은 쿼리에 응답하는 쿼리결과에 속할 수 있는 개체를 결정할 수 있습니다. 쿼리컨셉은

개념의 결합
개념의 분리
모든 값을 가진 속성
특정 값 또는 값 범위를 가진 속성
개념을 충족시키는 가치가 있는 속성
(나중에 참조 및 한정자를 처리하기 위해 추가 쿼리 컨셉 요소를 추가할 수 있음)

쿼리 개념의 예로는 인구가 1,000,000명 이상이고 '도시'인 모든 것, '국가' '일본'에서 '태어난' 모든 것, 그리고 1500년 이전에 '태어난' 또는 단순히 'ISBN' 3-237-233-443이 있는 모든 것(후자는 일반적으로 단일 결과일 것입니다).

선택요청은 쿼리결과의 "열"을 설명합니다. 가장 단순한 경우에는 속성이어야 합니다. 나중에 선택한 결과를 추가로 필터링하거나 영역을 통해 분할된 인구와 같은 계산을 설명하는 특정 청구 패턴을 추가할 수 있습니다.

쿼리옵션에는 정렬(Sort)의 배열이 있으며, 각각은 소터(Sorter)를 기존 선택요청 중 하나에 참조하고 제한, 주어진 정렬을 기반으로 특정 시점에서 결과 집합을 잘라냅니다. 간단한 경우는 인구를 기준으로 결과 집합을 내림차순으로 정렬하고 처음 5000개의 결과만 취하는 것입니다(일반적으로 많은 쿼리컨셉은 커리옵션이 필요하지 않을 것으로 예상되지만 완전한 쿼리결과를 보유하고 클라이언트에서 결과를 시각화할 때 추가로 정렬 및 제한할 수 있습니다).

참고로 레이블이나 다국어 텍스트 유형의 값으로 정렬하는 것은 불가능할 것입니다.

쿼리결과(QueryResult)는 각각 클레임이 있는 개체의 배열입니다. 클레임은 선택요청(SelectionRequest)을 기반으로 선택되거나 생성됩니다. (기본적으로 쿼리 결과는 행이 개체, 열이 선택 요청, 모든 필드에 한정자 및 참조를 포함하여 해당 클레임이 포함된 테이블 형식 구조입니다.)

위키데이터는 쿼리가 쿼리결과를 반환하는 모듈을 제공합니다. 위키데이터는 쿼리에 임시로 응답할 수 있는지 여부를 결정하고, 그렇다면 응답합니다. 허용되는 경우 쿼리 결과가 캐시되었는지 여부를 확인하고 캐시된 결과를 반환합니다. 위키데이터는 언제든지 질문에 대답하고 싶지 않다고 간단히 대답할 수 있습니다.

쿼리는 위키의 페이지인 쿼리 개체에 저장할 수 있습니다. 페이지에는 쿼리컨셉, 선택 사항, 옵션 등이 표시되며 이미 캐시된 경우 최신 쿼리 결과도 표시됩니다. 모든 개체와 마찬가지로 페이지에는 레이블, 설명 및 별칭이 있습니다. 일반적으로 위키백과는 이름으로 이러한 쿼리에 접근하고 쿼리 결과(예를 들어, 막대 차트, 지도, 테이블, 대화형 위젯)를 표시하는 데 사용할 포맷터의 종류와 추가 제한 및 정렬을 수행해야 하는지 여부를 로컬에서 결정합니다.

쿼리 결과는 캐시되고 수시로 다시 계산됩니다. 위키데이터 사용자는 쿼리를 (우선순위?) 대기열에 넣어 다시 계산할 수 있습니다. 쿼리를 "빌드"하는 동안 이러한 (우선순위?) 대기열도 사용할 수 있습니다. 이렇게 하면 명시적 요청에 대해서만 쿼리 결과를 다시 계산하거나 쿼리 결과의 "시청 버전"을 가질 수 있습니다.

또한 위키데이터는 결국 쿼리컨셉을 제공하는 모듈을 제공할 것이며 개체는 항목이 컨셉에 포함되어 있는지 여부에 대한 설명을 반환할 것입니다.

첫 번째 구현 단계: 속성-값 쿼리 (SQL)

구현의 첫 번째 반복은 임시 쿼리만 지원합니다(즉, 여전히 캐시될 수 있지만 쿼리 개체에 대한 컨셉은 아직 없으며 특정 값이 있는 속성인 "쿼리컨셉" 유형이 하나만 있습니다.

기술적으로 이것은 모든 속성 값을 테이블에 포함하고 속성 및 값에 대한 인덱스를 사용하여 구현됩니다. 이것은 SQL에서 수행할 수 있습니다. 쿼리 유형은 기본적으로 "독일에 위치" 또는 "ISBN 1-393-2334-X 있음"입니다. 이러한 쿼리에는 조인이나 다른 것이 필요하지 않습니다.

데이터 유형당 하나의 테이블이 있습니다(즉, 문자열을 가리키는 테이블, 항목을 가리키는 테이블, 숫자를 가리키는 테이블 등. 이것은 짧은 목록입니다). 테이블은 다음과 같은 구조를 갖습니다: row-id(관리에 필요한 경우), entity-id, statement-id, property-id, value(유형은 이 테이블의 데이터 유형에 따라 다릅니다. 예를 들어, 항목의 경우 item-id, 문자열 문자열 등), statement-blob(액세스를 위해 JSON의 전체 구조화된 명령문 포함 - 그렇지 않으면 엔터티 콘텐츠에 대한 조회가 필요함)(statement-blob이 있는지 여부에 대해 확실하지 않음). 이 테이블은 명령문이 변경될 때마다(자주) 업데이트됩니다. 이 테이블에는 현재 약 1,250만 개의 명령문이 있는 만큼의 행이 있으며, 꽤 성장할 것으로 예상됩니다(연말까지 약 5,000만 개?). 잦은 업데이트로 인해 row-id는 곧 32비트 범위를 넘어 증가할 것으로 예상됩니다.

쿼리의 경우 테이블은 속성 ID/값 쌍에 대해 인덱싱됩니다(나중에 엔티티 ID를 통한 조인 성능에 도움이 될 수 있는 경우 엔티티 ID가 이 인덱스에 추가될 수 있음). 엔티티가 변경될 때 업데이트의 경우 엔티티 ID 및 명령문 ID에 두 번째(고유한) 인덱스가 있습니다.

지리 데이터에 대한 거리 쿼리에 대한 지원은 SQL 접근 방식에서 구현되지 않습니다.

EntitiesByPropertyValues (첫 번째 반복)

매개변수: 속성(필수), 값(속성에 따라 다름, 필수), 엔터티 유형(필수, 오프셋(선택), 제한(선택))

반환값: 기본 snak에 지정된 속성이 있고 값이 정확히 지정된 값인 명령문이 있는 모든 엔티티 ID 목록. 선택적으로 필요한 경우 추가 결과를 위한 오프셋입니다.

(값은 범위 쿼리를 포함하기 위해 나중에 느슨해집니다. 즉, 보다 큼, 보다 작음 등)

두 번째 구현 단계: 범위, 좌표 및 결합 쿼리(Solr / ElasticSearch)

그런 다음 접속사(독일에 위치한 도시 및 위치)와 지리 데이터(이 좌표에 가까움)를 쿼리할 수 있는 가능성으로 다음 단계로 이동하려고 합니다. 이것은 SQL에서 잘 작동하지 않습니다. 우리의 현재 생각과 테스트는 이러한 종류의 쿼리를 지원하는 좋은 기술로 Solr 또는 ElasticSearch를 지적합니다.

Solr 또는 ElasticSearch에서 모든 항목은 문서로 표시되고 각 명령문은 문서의 하나 이상의 기능으로 이어집니다. Solr 또는 ElasticSearch는 지리 좌표, 범위 및 정렬도 지원합니다.