1

大きなドキュメント (10 ～ 20MB) を保存できるデータベース システムを探しており、次のことができます。

  • 特定のドキュメントのコンテンツに場所別にアクセスできます。たとえば、位置 100 から 500 の間のテキストをフェッチします。
  • データベースはドキュメントから部分的なコンテンツのみを返す必要があります (ドキュメント全体をロードせずに)。だから私は効率を探しています。
  • 指定された場所 (または範囲) でテキスト ブロックの挿入、更新、および削除を処理する必要があります。
  • これらの場所を使用して境界を定義したいと考えています。たとえば、場所 100 ～ 500 はページ番号です。4

これは、ユーザーが連続したドキュメントの形式でコンテンツを作成する Web アプリケーションで使用されます (たとえば、1 つのドキュメントは、数百ページの簡略化された Google ドキュメントです)。MongoDB について考えたことはありますが、よくわかりません。

-

ここではどのようなデータベースを使用できますか? (オープンソースのデータベースを探しています)

また

そのようなシステムを自分で書かなければならない場合、どのようなアプローチが必要で、どこから始めればよいでしょうか?

ありがとうございました ：）

4

1 に答える 1

1

私はいつも、データベース内にファイルを置くことに不快感を覚えていました。ファイルシステムはファイルの理想的なデータベースです (サイズは O/S が処理できるサイズに制限されません)。インデックス作成/検索は別のアプリケーションで処理でき、データベースは uri 風の単純なテーブルに縮小できます。システム内の実際の各ファイルとその他の適切なメタデータにリンクします。

あなたの場合、 luceneのようなファイル インデクサー/検索エンジンは、従来の DMBS をファイル システムとして使用しようとするよりも、プロジェクトにより適している可能性があります。

コンテンツをデータベースに入れることを計画しているので、ドキュメントをシステムに追加する方法を制御できると思います。これにより、特別なリポジトリに勝手にファイルがドロップ、変更、または削除されることを心配することなく、プレゼンテーション層をファイルシステム データ ストアとより簡単かつ高度に統合できます。

したがって、非常に基本的な高レベルのシステム概要は次のようになります。

[(APP) Your System]---------[(DB) Catalog ]
           |       \              |
           |        --------      |
           |                \     |
[(FileSystem) Files]--------[(App) Indexer]

あなたのシステムは、ドキュメントのメンテナンスと正面検索のすべてのスマートを実行し、インデクサーはファイル システムを監視し、カタログ DB を更新します。(インデクサーが十分な機能またはメタデータを追加する機能を提供することになる場合、カタログは不要かもしれませんが、「100 から 300 の間のドキュメント」に基づいて検索する必要がある場合は、インデクサーと組み合わせて使用​​する方が簡単かもしれません)

于 2013-11-25T01:19:56.130 に答える