prosource

오라클 With C#의 1,000만 개 이상의 레코드 목록 작성

probook 2023. 10. 30. 21:05
반응형

오라클 With C#의 1,000만 개 이상의 레코드 목록 작성

저는 1억개 이상의 기록을 보유한 데이터베이스를 가지고 있습니다.천만 건 이상의 기록이 포함된 쿼리를 실행하고 있습니다.이 과정은 시간이 너무 많이 걸려서 이 시간을 단축해야 합니다.획득한 레코드 목록을 csv 파일로 저장하고 싶습니다.어떻게 하면 최대한 빠르고 최적으로 할 수 있을까요?당신의 제안을 기다리겠습니다.감사해요.

쿼리가 이미 필요한 행/열로 제한되어 있고 인덱싱을 잘 활용하고 있다고 가정합니다.

그 정도의 규모라면 한 번에 모든 것을 메모리에 로드하려고 하지 않는 것이 중요합니다. 따라서 다음과 같은 것은 잊어버리십시오.DataTable, 대부분의 Full-fat ORM(일반적으로 행을 ID 관리자 및/또는 변경 관리자와 연결하려고 함).당신은 날것을 사용해야 할 것입니다.IDataReader(발신)DbCommand.ExecuteReader), 또는 그 에 버퍼링되지 않은 반복기를 구축하는 모든 API(여러 개가 있습니다. 저는 dapper에 치우쳐 있습니다.CSV를 쓰기 위한 목적으로 원시 데이터 판독기는 아마도 괜찮을 것입니다.

그 이상으로 대역폭이 제한되어 있기 때문에 훨씬 더 빠르게 진행할 수 없습니다.데이터베이스 서버에서 CSV 파일을 생성하여 네트워크 오버헤드가 발생하지 않도록 하는 것이 이 파일을 더 빨리 얻을 수 있는 유일한 방법입니다.

C#에서 이 작업을 수행해야 할 가능성은 매우 낮습니다.대량 데이터 로드/내보내기 영역입니다(데이터 웨어하우징 시나리오에서 일반적으로 사용됨).

많은 (무료) 툴(Toad by Quest Software)이 사용자가 어떤 플랫폼에서도 작성할 수 있는 것보다 더 강력하고 효율적으로 이 작업을 수행할 것으로 예상됩니다.

최종 사용자에게는 실제로 이 기능이 필요하지 않다는 느낌이 듭니다.(단순히 관찰할 수 있는 것은 부서 비서가 실제로 해당 기능의 복사본을 메일로 보낼 필요가 없다는 것입니다. 너무 커서 그런 방식으로 유용하지 않다는 것입니다.)

저는 그 일에 적합한 도구를 사용할 것을 제안합니다.그리고 당신이 무엇을 하든지

  • 사용자 자신의 데이터 유형 변환 롤하지 않기
  • 인용 문헌과 함께 CSV를 사용하고 이들 내부의 이중 인용문을 탈출하는 것을 생각합니다.
  • 지역별 옵션을 생각합니다(IOW: 수출/수입 시 항상 불변문화 사용!)

"이 과정은 시간이 너무 많이 걸리므로 이 시간을 단축해야 합니다."

이 프로세스는 세 가지 하위 프로세스로 구성됩니다.

  1. 10m 이상의 기록을 검색 중
  2. 파일에 레코드 쓰기
  3. 네트워크를 통해 레코드 전송(원격 데이터베이스에 대해 로컬 클라이언트와 작업 중인 것으로 추정됨)

이러한 문제 중 일부 또는 전부가 병목 현상이 될 수 있습니다.따라서 총 경과 시간을 줄이려면 시간이 어디에 사용되는지 파악해야 합니다.측정 기준을 얻으려면 C# 코드를 계측해야 할 것입니다.

쿼리가 문제인 것으로 판명되면 이를 조정해야 합니다.테이블의 큰 청크(> 10%)를 검색할 때 인덱스가 도움이 되지 않으므로 전체 테이블 검색 성능을 높이는 것이 도움이 됩니다.예를 들어, 디스크 정렬을 방지하기 위해 메모리를 늘립니다.병렬 쿼리는 Enterprise Edition이 있고 CPU가 충분한 경우 유용할 수 있습니다.또한 문제가 하드웨어 문제(스핀들 경합, 닷지 인터커넥트 등)가 아닌지 확인합니다.

파일에 쓰는 것이 문제가 될 수 있습니까?디스크 속도가 느리거나(예: 조각화), 동일한 디렉토리에 쓰는 다른 프로세스와 경합하고 있을 수 있습니다.

네트워크를 통해 대량의 데이터를 전송하는 것은 분명히 잠재적인 병목 현상입니다.고객에게 관련 데이터만 보내는 것이 확실합니까?

대안적인 아키텍처: PL/SQL을 사용하여 데이터 서버의 파일에 레코드를 기록하고, 대량 수집을 사용하여 관리 가능한 레코드 배치를 검색한 다음 FTP를 통해 파일을 필요한 곳으로 전송합니다.

진짜 질문은 데이터베이스에서 많은 행을 읽어야 하는 이유입니다(그리고 기본 데이터셋의 많은 부분).이 시나리오를 피할 수 있는 많은 접근법이 있습니다. 동기화 처리, 메시지 대기열 및 사전 통합이 명백합니다.

그건 제쳐두고...데이터를 통합하거나 조정하는 경우 PL/SQL에서 대부분의 로직을 구현하면 네트워크를 통해 데이터를 전송해야 하는 비용이 절감됩니다(로컬 호스트에만 해당하더라도 여전히 큰 오버헤드가 발생합니다).다시 말하지만, 플랫 파일에 버리기를 원한다면 C#에서 이를 구현하는 것은 도움이 도움이 되지 않습니다.

언급URL : https://stackoverflow.com/questions/8323353/listing-more-than-10-million-records-from-oracle-with-c-sharp

반응형