大きなオブジェクトを格納する最良の方法は何ですか? 私の場合、それはツリーまたはリンクされたリストのようなものです。
私は次のことを試しました：
1) リレーショナルデータベース
ツリー構造には適していません。
2) ドキュメントデータベース
RavenDB を試しましたが、SaveChanges メソッドを呼び出すと System.OutOfMemory 例外が発生しました
3) .Net シリアル化
動作が非常に遅い
4) プロトブフ
タイプを逆シリアル化するList<List<>>ことはできず、リンクされた構造についてはわかりません。
そう...？
あなたはprotobufに言及しています-私は、サイズが数百メガバイトのオブジェクトでprotobuf-netを日常的に使用していますが、DTOとして、理想的にはツリーとして適切に記述する必要があります(その使用法はサポートされていますが、双方向グラフではありません)一部のシナリオでは）。
二重にリンクされたリストの場合、それは単に「前の」リンクをシリアル化されていないものとしてマークし、デシリアライズ後のコールバックで修正を行い、「前の」リンクを正しく設定することを意味します。普通に簡単。
現在、ネストされたリストをサポートしていないという点で正しいです。これは通常、リストを持つもののリストを使用して回避するのは簡単ですが、私はこれを暗黙的にしたいと思います。つまり、ライブラリはモデルを変更する必要なくこれをシミュレートできるはずです。私がこれを行うことに興味がある場合は、お知らせください。
シリアライズしたいモデルの具体的な例があり、ガイダンスを提供してほしい場合は、お知らせください。ここに投稿できない場合は、私のメールアドレスが私のプロフィールにあります。完全にあなた次第です。
Json.NET を試して、結果をファイルに保存しましたか?
オプション [2] : NOSQL (ドキュメント) データベース
カサンドラをお勧めします。
カサンドラウィキから、
Cassandra's public API is based on Thrift, which offers no streaming abilities
any value written or fetched has to fit in memory. This is inherent to Thrift's
design and is therefore unlikely to change. So adding large object support to
Cassandra would need a special API that manually split the large objects up
into pieces. A potential approach is described in http://issues.apache.org/jira/browse/CASSANDRA-265.
As a workaround in the meantime, you can manually split files into chunks of whatever
size you are comfortable with -- at least one person is using 64MB -- and making a file correspond
to a row, with the chunks as column values.
したがって、ファイルが 10MB 未満であれば問題ありません。ファイル サイズを制限するか、大きなファイルをチャンクに分割してください。