큰 XML 파일의 효율적인 저장 및 액세스

변환해야하며 시스템의 다른 부분에 XML로 제공해야하는 레코드가 포함 된 레거시 이진 파일 형식이 있습니다. 데이터 크기에 대한 이해를 돕기 위해 단일 파일은 50,000 개 이상의 레코드가있는 최대 50MB까지 가능합니다. 필자가 작업해야하는 XML 변환은이 특정 파일을 거의 20 기가 바이트까지 불어 넣습니다.큰 XML 파일의 효율적인 저장 및 액세스

gzip을 사용하여 파일을 압축하면 (언젠가는) 파일이 ~ 150Mb가되므로 중복성이 많습니다.

하지만 우리가 XML로 제공해야하는 것은 큰 파일의 일부인 개별 레코드입니다. 이 기록들 각각은 아주 작습니다. 기록에 무작위로 액세스해야합니다. 레코드 자체에는 다양한 필드가 있으므로 매우 큰 테이블이 없어도 열에 대한 요소 매핑이 없습니다.

시스템의 다른 부분은 postgresql 데이터베이스를 사용하므로 각 개별 XML 노드를 데이터베이스에 행으로 저장하는 것이 좋습니다. 그러나 우리는 비효율적 인 스토리지가 현명한 방법 일까 궁금해하고 있습니까?

<xml> 
<record><complex_other_xml_nodes>...<record> 
<record>...<record> 
<record>...<record> 
<record>...<record> 
<record>...<record> 
</xml>

아니면 XML 데이터베이스 (또는 다른 것)를 평가해야합니까? 아, 우리는 변환 후 XML을 업데이트하거나 변경할 필요가 없습니다. 이러한 레거시 레코드는 정적입니다.

출처

2009-07-01 Anonymous

당신은 vtd-xml을 보았습니까? –

XML의 단점 중 하나 때문에 DB에 데이터를 저장하는 것이 더 효율적입니다. 각 요소에는 메타 데이터가 있습니다. 따라서 하나의 정수 값을 포함하는 행은 하나의 값을 설명하기 위해 10자를 초과 할 수 있습니다. XML은 매우 어리 석다. DB에 데이터를 저장하면 메타 데이터가 스키마로 저장된 위치에 해당 값이 저장됩니다.

출처

2009-07-01 12:25:28 johnofcross

나는 내 질문에 더 분명 해졌어야했다. 레코드 포맷은 수백 가지의 가능한 필드가있는 복잡한 포맷이다. 따라서 데이터베이스에 쉽게 매핑 할 수는 없습니다. –

글쎄, XML 스키마가 있나? 그렇다면 DB 전환이 쉬울 것입니다. 그렇지 않은 경우 데이터 무결성을 허용하는 스키마를 만드는 것이 좋습니다. 그럴 수 없다면 각 레코드에 포함 된 데이터 유형을 결정하고 DB 유형에 매핑하십시오. – johnofcross

흠 ... 저도 비효율적 인 것으로 생각됩니다. 빈 열이 많거나 테이블의 수는 상당히 많습니다. XML은 속성 수와 가변 개수의 중첩 된 자식 노드가 각각 고유 한 속성 집합을 갖는 레코드 노드를 사용하는 것이 중요하지 않습니다. 따라서이 모든 것을 데이터베이스에 매핑하는 것이 옳다고 생각하지 않습니다. 계속 의견을 보내 주셔서 감사합니다. 우리는 가정에 대한 압박감에 감사드립니다. –

우선 XML 태그가없는 단일 열에 값을 저장하여 많은 공간을 절약 할 수 있습니다. 그런 다음 ' <record>'||column_name||'</record>'||chr(10)을 선택하는 간단한보기를 작성할 수 있습니다. 전체 XML 문서를 얻으려면 연결 기능을 사용하는 것이 좋습니다. (필자는 오라클 백그라운드에서 왔기 때문에 Postgresql에서 어떻게 처리되었는지는 잘 모르겠습니다), 단일 열 커서를 입력으로 사용하고 전체 결과를 하나의 연결 문자열로 나타냅니다. 그런 다음 <xml>과 </xml> 태그를 연결하면됩니다.

출처

2009-07-01 12:29:11 l0b0

고마워, 내 질문에 더 분명 했어야했다. 이진 레코드에는 수백 가지의 가능한 필드가 있습니다. 따라서 데이터베이스에 쉽게 매핑 할 수는 없습니다. –

적절한 인덱스가있는 데이터베이스 스토리지는 일반적으로 임의 액세스에 대해 더 빠를 것이지만 레코드를 개별 데이터 요소로 분할하는 데 많은 노력이 필요할 수 있습니다. 중간에 만나서 데이터를 쿼리하는 데 사용할 고유 식별자에 기반하여 단일 데이터 필드에 전체 레코드를 저장할 수 있습니다.

xml 파일을 '트리밍'하고 스키마를 제어하려는 경우 - 노드 이름을 한 문자 또는 두 문자로 만드는 것만 큼 과거의 많은 대역폭/파일 크기를 절약 할 수 있습니다. 물론 xml의 가독성은 사라집니다. B

출처

2009-07-01 12:54:03 WillyCornbread

데이터가 다른 접근하고 50,000 정적 파일에 50,000 XML 형식의 "기록"사전 생성을 자유롭게 변경 (드물게 또는) 정적 결코 때문에

아파치 (또는 더 나은 : lighttpd 또는 nginx)를 사용하여 정적 컨텐츠를 제공하십시오. 이것은 웹 사이트를 최적화하기위한 매우 일반적인 기법입니다. 이러한 정적 파일은 원본 데이터 파일을 변경해야하는 경우 필요에 따라 다시 생성 할 수 있습니다.

들어오는 HTTP 요청을 두 개 이상의 정적 컨텐츠 서버 시스템에로드 밸런싱하여 고 가용성 및 확장 성을 확보 할 수 있습니다. 각 시스템에는 고유 한 데이터 사본이 있습니다. 웹 서버 앞에서 HTTP 역방향 프록시 캐시를 사용하여 확장 성을 확보 할 수도 있습니다.

솔직히 기가 바이트는 이전 버전이 아니며, 행 인덱스가 무엇이든 상관없이 미리 만들어진 XML 덩어리를 50,000 개 이상 보유하는 단일 PostgreSQL 테이블을 만들면됩니다.

출처

2009-07-01 16:47:05

큰 XML 파일의 효율적인 저장 및 액세스

답변

관련 문제