大きなデータを格納するためにBLOBまたはテーブルを使用する必要がありますか？
問題
現在、Webアプリケーションのパフォーマンスを改善するためのソリューションを調査しています。このアプリケーションは小規模なプロジェクトではうまく機能しますが、大規模なプロジェクトで作業する場合、UIのパフォーマンスの問題に直面します。
ユースケースは次のとおりです：
ユーザーは、10000のラインアイテムを含むExcelドキュメントを送信する必要があります。各ラインアイテムには約50の用語が含まれ、各用語には1つ以上の属性を含めることができます。システムは、そのようなドキュメントをアップロードする200人のユーザーを処理できるプロジェクトをサポートする必要があります。最大10人のユーザーを同時にアクティブにすることができます。そのような大規模なプロジェクトが複数存在する可能性があります。
現在使用されているデータベースはOracleです。また、選択したソリューションがインメモリカラムナーRDBMSで適切に機能することを確認する必要もあります。
既存の機能は、Web UIとExcelインターフェースの両方を備えた小規模プロジェクトに適しています。ただし、Web UIには大規模なプロジェクトのパフォーマンスの問題があり、Excelインターフェースのみに依存します。
データの操作には、アップロード/インポート、ダウンロード/エクスポート、編集、レポートが含まれます。
アップロードの一部として発生するRDBMS内の他の更新があるため、すべてのアクションはトランザクションである必要があります。したがって、これを非トランザクションデータソースに入れることはできません。すべてのデータをロードする必要がある少なくとも1つのメインオペレーションがあります。この操作は非同期で実行できます。
既存のソリューション
TomcatとOracleで実行される既存のソリューションは、ワイドテーブルを使用します。このソリューションは最大1000の広告申込情報で機能し、アプリケーションサーバーでパフォーマンスの問題が発生します。パフォーマンスの問題はJavaオブジェクトのハイドレーションに関連し、アプリケーションサーバーでメモリの問題を引き起こします。これは、ワイドテーブルに多数のnull列とJava =空のフィールドが多数あるため、作成されるオブジェクトは大きくなります。
オプション
多数のラインアイテムを処理するには、既存のソリューションのメモリフットプリントを削減する必要があります。私たちは次のアプローチの間で決定しようとしています：
- BLOB
- 狭いテーブル
- 再設計Javaオブジェクト（新規）
BLOBソリューション
Null値を回避する1つの方法は、Excelドキュメントを簡潔なキー値の形式に変換して、ユーザーごとにBLOBとして圧縮してデータベースに保存できるようにすることです。このアプローチの利点は次のとおりです。
- DBで使用するスペースを大幅に減らします。
欠点は次のとおりです。
- すべてのユーザーのデータを処理する必要がある操作がいくつかあるため、実行できることは限られています。
- 少し編集すると、BLOB全体が書き直され、REDOログが増大します。
- 将来、このモデルに対して既存のUIを改造することは困難になります
- 大規模プロジェクトの新しいモデルを維持する
狭いテーブル
このアプローチは、各用語の行を含むいくつかのフィールドを持つことにより、null値を解決します。 null列の数は大幅に削減されます。 Javaこれらの行からハイドレートされたオブジェクトには空のフィールドがなく、サイズが小さくなる可能性があるため、メモリの問題が軽減されます。利点は次のとおりです。
- 狭いテーブルは、メモリ内の列アプローチに適しています
- 新しいテーブル構造に対して機能するようにUIを作り直す可能性を開いたままにします
欠点は次のとおりです。
- 行数が桁違いに増加します。 1つのプロジェクトは、10000x50x200行、つまり1億行になります。
- UIは変更されず、古いモデルから削除されるため、新しいモデルを維持します。
再設計Javaクラス
最初はこのアプローチを考慮していませんでしたが、それは良いオプションのように見えます。既存のデータモデルを使用しますが、マップをバックとするJavaクラスを改造します。このマップでは、設定されたフィールドのみが保持されます。これにより、多数のフィールドを持つクラスを避けることができるため、疎に配置されたオブジェクトのメモリフットプリント。
利点
- 3つのオプションすべての影響を最小限に抑えて、アプリケーションメモリの問題を解決します
- 既存のデータモデルを使用
欠点
- DB内の空の列を削除しません。でも今はこれで我慢できると思います。
- カラムナインメモリRDBMSに最適な形式ではない可能性があります
質問
取るべき最善のアプローチは何ですか？
pdate説明を明確にしていたときに、3番目のオプション（Java class）が再設計されている可能性）が浮かび上がってきました。有望に見えるので、さらに調査します。モデルへの影響はありません。これがユースケースに基づいて適切なオプションではないかどうか、および問題がある場合はお知らせください。
問題は、この情報をどのようにRDBMSに効率的に格納するかということです。
質問である必要がありますなぜこの情報をRDBMSに保存する必要がありますか？
いったんそれがあると、それで何をするつもりですか？
スプレッドシートをデータベースに「保存」し、それを再び引き出すだけの場合は、時間を無駄にすることをお勧めします。それはファイルです。それが属しているファイルシステムに配置し、そこから[はるかに]簡単に取得できます。
しかしながら ...
「アップロードされた」データと「スライスアンドダイス」を調べて、manyユーザーがアップロードしたデータ全体の要約を描画すると、データベースはほとんどの間違いなく行く方法です。
OK、1億行はたくさんありますが適切なインデックス付け（およびオプションがある場合はパーティション化）があれば、データベースはそれに対応します。
はい、大きな問題は、これらのExcelドキュメントがDBに格納されたら、それらをどのように処理するかです。それらをBLOBとして非常に楽しく保存できますが、ファイルシステムにファイルとして保存することもできます。後者を使用すると、ドキュメントをさまざまな方法で操作できます（コードを実行して変更するなど）。
後で取得するために保存するだけの場合は、BLOBとして保存します。 blobと一緒にコンテンツに関する追加のメタデータを保存できます。これは、ドキュメントに関するクエリを実行する必要がある場合に使用するアプローチです。
SQL Server 2012には、ハイブリッドファイル/ DBである ' filetables 'に格納されているファイルにインデックスを付ける機能があるため、両方の利点を得ることができます。
おそらく、ハイブリッドアプローチを検討してください。ドキュメントの取得と保存は、ドキュメント中心のデータベースまたは「NoSQL」データベースの範囲です。おそらく、実際のスプレッドシートを（たとえば）Cassandra）に格納し、メタデータ（および、スプレッドシート内のデータのサブセットのみを本当に気にする場合は、作業データのコピー）をOracleに保持します。
Tomcatでのメモリのプレッシャーについては、Flyweightデザインパターンをご覧ください。基本的に、データのビットごとにオブジェクトを作成しないことをお勧めします。代わりに、データが必要な場合にのみオブジェクトをインスタンス化します。たとえば、50個のアイテムで構成される1万行のオブジェクトを作成する代わりに、アイテムの場合と同様に、現在の操作に必要な数の行のみを作成します。これには、バッキングデータを未加工の形式（Excelスプレッドシート）で保持し、必要な場合にのみ個々の値をインスタンス化する必要があります。
これは、ファイルのコンテンツをどのように処理するかによって異なります。
シートの内容に基づいてクエリを実行する必要がある場合（そして、必ずそうする必要があると確信している場合）、テーブルソリューションを検討する必要があります。パフォーマンスの問題を改善する方法はいくつかあると思います（バッチ挿入...）。
説明を明確にしていくと、3番目のオプション（再設計されたJavaクラス））が浮かび上がりました。モデルへの影響はなく、有望であると思われるので、さらに調査します。ユースケースに基づいてこれが適切なオプションではなく、問題が発生した場合。