오라클 여러 스키마 집계 실시간보기

Question

모든,

내가 현재 평가하려고 오라클 디자인 결정에 대한 몇 가지 지침을 찾고 스키마는 동일한 oracle db 서버에 있습니다. 세 가지 스키마의 데이터를 모두 표시하는 응용 프로그램을 만들려고하지만 표시되는 데이터는 실시간 정렬 및 데이터에 전역 적으로 적용되는 우선 순위 규칙을 기반으로합니다 (예 : 적용된 우선 순위 가중치에 따라 세 가지 스키마 중 하나에서 데이터를 끌어 오십시오.)

임시 해결책

이 세 가지 스키마의 관련 열 논리적 링크를 유지 DB에서 VIEW를 만들기, 매개 변수화 우선 순위 가중치를 받아 저장 프로 시저를 작성합니다. 그런 다음 응용 프로그램은 저장 프로 시저를 호출하여 뷰에서 '우선 순위가 지정된'행을 선택한 다음 연결된 행을 검색하여 반환 된 행을 기반으로하는 추가 데이터를 직접 쿼리합니다.

각 쿼리를 수행 할 때 데이터 정렬/우선 순위를 지정하는 경우 성능에 대한 우려가 있지만 우선 순위 지정 규칙이 자주 변경되므로이 문제를 해결할 방법이 없습니다. 스키마 당 2-3 백만 행의 데이터 세트에 대해 이야기하고 있습니다.

누구든지 데이터에 대해 집계 및 정렬 된보기를 제공하는 방법에 대한 대안이 있습니까?

Answer 1

여러 스키마 (또는 심지어 multiple databases)에서 쿼리하는 것은 동일한 쿼리 내에서도별로 중요하지 않습니다. 성능이 문제가되면 그냥

SELECT SOMETHING 
FROM 
    SCHEMA1.SOME_TABLE ST1, SCHEMA2.SOME_TABLE ST2 
WHERE ST1.PK_FIELD = ST2.PK_FIELD 

같이 관심있는 스키마와 테이블 이름 앞에 추가, 그 큰 화제 ... 최적의 쿼리 계획, 인덱스 및 데이터베이스 연결의 당신의 방법입니다 수 모두 경기에 나옵니다. 한 가지 염두에 두어야 할 것은 실시간 일 필요가없는 경우 materialized views (aka "snapshots")을 사용하여 한 곳에서 데이터를 캐시 할 수 있다는 것입니다. 그런 다음 합리적인 성능으로 쿼리 할 수 ​​있습니다.

필요에 따라 적절한 간격으로 새로 고치도록 스냅 샷을 설정하기 만하면됩니다.

Answer 2

데이터가 실제로 3 개의 스키마에서 온 것은 중요하지 않습니다. 중요한 것은 데이터의 빈도, 기준 변경 빈도 및 쿼리 빈도입니다.

제한된 수의 기준 (즉, 데이터가 제한된 수의 방식으로 표시됨)이 며칠마다 변경되고 미친 듯이 쿼리 될 경우 구체화 된보기를 확인해야합니다.

기준이 거의 무한하면 재사용하지 않으므로 구체화 된 뷰를 작성하는 것이 중요하지 않습니다. 기준 자체가 매우 자주 변경되는 경우에도 마찬가지입니다. 구체화 된보기의 데이터는이 경우에도 도움이되지 않습니다.

답변을받지 못한 또 다른 질문은 소스 데이터가 얼마나 자주 업데이트되고 최신 정보를 얻는 것이 얼마나 중요한지입니다. 자주 업데이트되는 소스 데이는 일정 기간 동안 구체화 된 뷰가 "부실"해지거나 데이터를 "신선한"상태로 유지하기 위해 구체화 된 뷰를 불필요하게 새로 고치는 데 많은 시간을 소비하고 있음을 의미합니다.

솔직히 말해, 하드웨어가 충분하다면 2-3 백만 레코드는 오라클에게 더 이상 필요하지 않습니다. 나는 환상적인 (materialized) view를 시도하기 전에 간단한 동적 쿼리를 먼저 벤치마킹 할 것이다.

Answer 3

오라클의 2 천만 행을 쿼리하는 것은 실제로 문제가되지 않지만 실제로 얼마나 자주 수행하는지에 따라 다릅니다. 매 10 분의 1 초마다 db 서버에 부하가 발생할 수 있습니다!

비즈니스 요구 사항과 데이터의 좋은 모델에 대한 세부 정보가 없으면 좋은 성능 아이디어를 제공하기가 항상 어렵습니다. 일반적으로 이론을 제안한 다음 데이터베이스에 대해 시도하고 "충분히 빠르다"면 액세스합니다.

결과가 얼마나 정확한지 물어볼 가치가 있습니다. 이 쿼리에 대해 정확한 값을 필요로하거나 좋은 예상치가 필요합니까?

Tom Kyte (Ask Tom 명성의)는 항상이 분야에서 흥미로운 아이디어를 가지고 있습니다. This article describes generating a proper dynamic search query - but Tom points out that when you query Google it never tries to get the exact number of hits for a query - it gives you a guess. 좋은 예상치를 적용 할 수 있다면 쿼리 성능을 향상시킬 수 있습니다.