나는 하둡을 읽고있다 : 톰 화이트의 결정적인 가이드. 챕터 13.6 "HBase와 RDMS"에서 그는 많은 데이터가있는 경우 최근 항목 10 개를 얻는 것과 같은 간단한 쿼리조차도 매우 비싸고 Python과 PL/SQL을 사용하여 다시 작성해야한다고했습니다.Hadoop에 설명 된대로 RDBMS가 좋지 않습니까?
그는 예를 들어 다음 쿼리 제공 :
SELECT id, stamp, type FROM streams
WHERE type IN ('type1','type2','type3','type4',...,'typeN')
ORDER BY stamp DESC LIMIT 10 OFFSET 0;
을 다음과 같이 말한다 : "는 RDBMS 쿼리 플래너 취급이 쿼리를 다음과 같이
MERGE (
SELECT id, stamp, type FROM streams
WHERE type = 'type1' ORDER BY stamp DESC,
...,
SELECT id, stamp, type FROM streams
WHERE type = 'typeK' ORDER BY stamp DESC
) ORDER BY stamp DESC LIMIT 10 OFFSET 0;
여기서 문제는 우리가 있다는 것입니다 이후에는 상위 10 개의 ID 만 표시되지만 플래너의 쿼리는 실제로 전체 병합을 구체화 한 다음 끝 부분을 제한합니다. 까지 힙을 수행 한 사용자 정의 PL/Python 스크립트 을 작성했습니다. ... 거의 모든 경우에,이
예상 perforamnce 및 expermiental 결과
나는 데이터 세트를 상상할 수 없었다 ... 네이티브 SQL 구현과 쿼리 계획의 전략 상회 그 같은 간단한 질의 권리를 수행하기 위해 pl/python을 작성해야하는 문제가 발생합니다. 그래서 나는이 문제에 대해 잠시 동안 놀았으며 다음 관측을 제안했습니다.
이러한 쿼리의 성능은 O (KlogN)로 제한됩니다. 이 번역 될 수 있기 때문에 그렇게 뭔가를 다음과 같이
이SELECT * FROM (
SELECT id, stamp, type FROM streams
WHERE type = 'type1' ORDER BY stamp DESC LIMIT 10,
UNION
...,
SELECT id, stamp, type FROM streams
WHERE type = 'typeK' ORDER BY stamp DESC LIMIT 10
) t ORDER BY stamp DESC LIMIT 10;
(각 쿼리의 'LIMIT (10)를'주의 BTW 내가 주문 노동 조합을 제한 할 수 없다는 것을 알고하지만 난 선택을 포장 밖으로 제거했습니다. 가독성을 위해)
각 하위 쿼리는 색인 O (logN)에서 올바른 위치를 찾고 10 개의 항목을 반환하는만큼 빠르게 실행되어야합니다. 우리가 K 회 반복한다면 우리는 O (KlogN)를 얻는다.
쿼리 플래너가 너무 나빠서 첫 번째 쿼리를 최적화 할 수 없더라도 pl/python에 아무 것도 쓰지 않고 원하는 성능을 얻을 수 있습니다.
내 계산을 다시 확인하기 위해 9,000,000 개의 테스트 레코드로 채워진 하나의 postgresql보다 위에있는 쿼리를 실행했습니다. 결과는 두 쿼리가 모두 첫 쿼리의 경우 매우 빨랐으며 두 번째 쿼리의 경우 300ms였습니다 (유니온이있는 쿼리).
따라서 쿼리가 9,000,000 (logn = 23) 개의 레코드로 100ms 실행되고 9,000,000,000 (logn = 33) 개의 레코드로 실행되는 경우 140ms로 실행되어야합니다.
질문
- 당신은 위의 추론에 어떤 결함을 볼 수 있습니까?
- 위와 같은 쿼리를 pl/python으로 다시 작성해야하는 데이터 세트를 상상할 수 있습니까?
- O (K log n)에서 이러한 쿼리가 작동하지 않는 상황이 있습니까?
아니요, 그렇지 않습니다. 어떤 데이터베이스는 필드의 필터에있는 각 항목에 대해 전체 테이블을 한 번 쿼리하고 모든 레코드를 병합 한 다음 주문한 다음 끝에 제한을 수행합니까? – MkV