2009-07-01 15 views
1

私は変換してシステムの他の部分にXMLとして提供しなければならないレコードを含む古いバイナリファイル形式を持っています。データサイズの感覚を与えるために、1つのファイルが50,000以上のレコードを持つ50メガまでのファイルである可能性があります。私が作業しなければならない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を更新または変更する必要はありませんが、これらの従来のレコードは静的です。

+0

あなたはvtd-xmlを見ましたか? –

答えて

4

XMLには欠点があるため、DBにデータを格納する方が効率的です。各要素にはメタデータが含まれています。したがって、1つの整数値を含む行は、その1つの値を記述するために10文字を超える文字を含むことがあります。 XMLは非常に言葉です。 DBにデータを格納すると、その値が格納され、メタデータがスキーマとして保存されます。

+0

私は私の質問でもっと明確にすべきだった...レコードフォーマットは、数百の異なる可能なフィールドを持つ複雑なフォーマットです。したがって、データベースへの簡単なマッピングはありません。 –

+0

それはXMLスキーマを持っていますか?もしそうなら、DBの移行は簡単になります。そうでない場合は、データの整合性を保つためのスキーマを作成することをお勧めします。それが不可能な場合は、各レコードにどのデータ型が含まれているかを判断し、DB型にマップしてください。 – johnofcross

+0

ええと...それは私を非効率的なものにしてしまいます...空の列がたくさんあるか、テーブルの数がかなり多いでしょう。 XMLは、属性の数が可変で、ネストされた子ノードの可変数がそれぞれ独自の属性セットを持つレコードノードでは自明ではありません。したがって、このすべてをデータベースにマッピングすることは正しいと感じません。 ご返信いただきありがとうございます。私たちは前提を押し戻すことに感謝します。 –

0

まず、XMLタグを使用せずに単一の列に値を格納して、大量の領域を節約したいとします。その後、' <record>'||column_name||'</record>'||chr(10)を選択する単純なビューを作成することができます。 XML文書全体を取得するには、連結機能を使用することをお勧めします(私はOracleのバックグラウンドを使用していますので、Postgresqlの仕組みはわかりません)。結果全体を1つの連結文字列として返します。次に、<xml>タグと</xml>タグを連結するだけでいいです。

+0

ありがとう、私は私の質問でより明確にされている必要があります。バイナリレコードには、数百の異なるフィールドが含まれています。したがって、データベースへの簡単なマッピングはありません。 –

0

適切なインデックスを持つデータベースストレージは、通常はランダムアクセスの方が高速ですが、レコードを個々のデータ要素に分割するために多くの労力を要します。真ん中で会い、データを照会するために使用する固有の識別子に基づいて、単一のデータフィールドにレコード全体を格納することがあります。

xmlファイルを「トリミング」してスキーマを制御したい場合は、ノード名を1文字または2文字にするなどの単純な操作で、過去に帯域幅/ファイルサイズが大きく節約されていますもちろん、xmlの可読性がなくなるというトレードオフがあります。

B

3

データは、静的、決して(またはまれに)変化しているので、あなたは、静的ファイル50,000に異なるアプローチと事前生成50,000 XML形式の「記録」を取るために自由であり、その後、 Apacheを使ってこの静的コンテンツを提供してください(またはlighttpdやnginxなど)。これはウェブサイトを最適化するための非常に一般的な手法です。これらの静的ファイルは、元のデータファイルを変更した場合に必要に応じて再生成することができます。

着信HTTP要求を2つ以上の静的コンテンツ・サーバー・マシンにロード・バランシングすることにより、高可用性とスケーラビリティーを得ることができます。それぞれに独自のデータ・コピーがあります。また、Webサーバーの前にHTTPリバースプロキシキャッシュを使用することでスケーラビリティを得ることもできます。

正直なところ、ギガバイトはこれまでのものではなく、行インデックスが何であれ、キーが付けられた50,000以上の事前生成されたXMLチャンクを保持する単一のPostgreSQLテーブルを作成するだけです。

関連する問題