問題タブ [document-database]

WindowsでMongoDBを実行しています。コレクションを削除して再作成するスレッドが1つ以上あります。

このコマンドを使用mongo.exeするshow collections()と、同じ名前のコレクションが複数表示されます（同じ名前のコレクションが1,000をはるかに超えています！）。

検証を実行すると、次のようになります。

私は得る：

このsize()コマンドは0をfind()返し、何も返しません。

私の質問は：MongoDBスレッドは安全ですか？次の質問は、「これを正しく実行していますか（ドロップして再作成）、またはコレクションのコンテンツ全体を更新するためのより良い方法はありますか？」のようなものになります。

Yo-これはそれ自体がravendbの問題ではありません-一般的なドキュメントデータベースに関する別の設計上の質問です。

ですから、私はDenormalizedReferenceをかなり使用してきましたが、多くの場所でDDDがかなり難しくなっていることに気づきました。

たとえば、子コレクションを持つオブジェクトがあるとします。

この子コレクションは、親がオーバーロードされたコンストラクターでインスタンス化され、List<SomeOtherType>

ここで、コンストラクターで、渡されたSomeOtherTypeコレクションからこのリストを作成したいと思います。つまり、SomeOtherTypeごとに新しいSomeTypeを作成する必要があります。

DocumentSessionをドメインに渡さないと（これは行いません）、親ARを保存すると、IdとNameを除く各子オブジェクトのプロパティが失われるため、これは機能しません。

他のみんなはこれをどのように扱っていますか？

アプリケーション（またはその一部）を切り替えて、NHibernateでSQLサーバーからRavenDBを使用することに興味があります。

Ravenで見つけられない重要な機能は、クエリのインターフェイスの使用法です。例：

NHでは、任意のISearchableの[名前]フィールドの内容を検索できますQueryOver<ISearchable>()。

私はレイヴンでこれを見つけることができないようです、私は何かが欠けていますか？私が見つけた最も近いものは、識別子の前にある文字列部分を変更することですが、これはやりたくないことです。Class1とClass2の主な機能は検索できないことです！

ありがとう

Stu

私は現在MongoDBを試しています。私はNHibernate/SQLの考え方から移行しているので、最初はデータアクセス用のリポジトリパターンを実装しました。

ネストされたドキュメントを使い始めるまで、これはすべて問題なく見えました。今では少しミスマッチがあるように見え始めています。しかし、私はリポジトリに満足しており、リポジトリが提供する抽象化、関心の分離、およびテスト容易性が好きです。

人々はドキュメントデータベースでリポジトリパターンをうまく使用していますか？そうでない場合は、どのデータアクセス方法を使用しますか？抽象化/SoCはどうですか？

調整プロセスがあり、バックグラウンドスレッドによって、外部WebサービスからオブジェクトIDのリストを定期的に取得し、欠落しているエンティティを埋め込みRavenDbデータベースに追加しようとします。このプロセスを実行するループは次のとおりです。

GetPageByPageId()およびの実装は次のAddPage()とおりです。

問題は、リストに重複するIDがある場合、最初のIDを追加してそのIDを再度チェックすると、結果が空として返されることです。新しく追加されたエンティティを登録するファイナライズステップが欠落しているようです。後で別のスレッドからセットをクエリすると、その指定されたIDを持つエンティティが返されます。誰かがここで問題が何であるかを見ることができますか？

ありがとう、

データベースに約 1 億件のレコードを保存する必要があります。それらの約 60 ～ 70% が毎日削除され、同じ量のレコードが毎日挿入されます。Hbase や Big Table のような文書データベースがこれに収まる気がします。Cassandra、MongoDb など、他にも多くのデータ ストアがあります。毎日膨大な量の読み取り/書き込み (数千万のオーダー) が発生するため、この種の問題にはどのデータ ストアが役立ちますか。

C＃を使用して、独自のEコマースWebサイトの顧客プロファイリングプロジェクト（Google Analyticsと類似していますが、同一ではありません）に取り組みます。私はこの種のプロジェクトにかなり慣れていません。また、顧客プロファイリングプロジェクトもまったく新しいプロジェクトです。それについて何か提案をいただけますか？

「ウェブサイトの訪問データの追跡」と「追跡データの分析」の2つの部分があるべきだと思います。

それについて何か提案をいただけますか？ありがとう：

• この種のプロジェクトには、どのようなデザインパターンが最適ですか？（パイプラインとフィルター？または他の？）私はC＃を使用しています。
• どのようなデータベースが最適ですか？RDBMSまたはドキュメントデータベース？
• 追跡されたデータを格納するためのデータベーステーブルをモデル化する方法は？
• Googleでこのテーマを検索するために使用できるキーワードは何ですか？
• 読むべき記事や本を教えていただけますか？（本を読む時間があまりないので、記事の方がいいです）
• あなたが私が学ぶ必要があると思う他のこと。

前もって感謝します！

優れた検索機能を提供する文書データベースがあるかどうか、誰か知りませんか? RavenDb は Lucene.net をある程度使用しているようですが、Truffler.net クライアント API が提供するような、より統合された検索エクスペリエンスを探しています。彼らは、優れた検索機能を提供する Elasticsearch の上に .net クライアントを構築しました。

ドキュメント データベース クライアントのいずれかがクライアント API を介して直接同様の機能を提供できれば、それはキラー機能になると思いますが、それが実現可能かどうかはわかりません。

ドキュメント データベース (RavenDB) に格納するエンティティのドキュメント モデルを作成しています。私がモデリングしているドメインは、 を中心に展開していIncidentsます。インシデントには、ソース、優先度、カテゴリ、影響のレベル、およびその他の多くの分類属性があります。RDBMS では、プライオリティ テーブル、カテゴリ テーブル、インパクト テーブルなどへの外部キーを持つインシデント テーブルがありますが、ドキュメント データベースでそれを処理する方法がわかりません (これが私の最初のドキュメント BD です)。

2 種類の参照データがあります。

1. 単純な参照値: Countries、States、Sources、Languages。属性: 名前しかありませんが、これは多言語システムであるため、各言語に名前があります。サポートされている操作: 作成、削除、名前変更、非アクティブ化、マージ。

2. 複雑な参照データ: シンプル ルックアップと同じプラス: それらのいくつかには多くのフィールドがあり、独自のビジネス ルールと検証ルールがあります。たとえば、2 つPrioritiesが同じRank値を持つことはできません。Categoriesで構成されているなど、より複雑な構造を持つものもありますSubcategories。

それらをドキュメントとして (またはドキュメントの一部として) どのようにモデル化すればよいでしょうか?

PS:ドキュメント データベース モデリング ガイドラインへのリンクも歓迎します。

私のシステムでは、従業員ログのリクエストとリクエストは機器に関するものです。

リクエストを表示する必要があるたびに従業員と機器のドキュメントが読み込まれないようにするために、リクエストドキュメントの従業員名と機器の在庫番号、メーカー名、モデルを非正規化します。

私はここで間違った方向に進んでいますか？これはアンチパターンですか？

そうすると、従業員の名前が変更されたり、機器の在庫番号が変更されたりする非常にまれなケースで、影響を受けるすべてのリクエストドキュメントを更新する必要があることに気付きました。

PS：ドキュメントデータベースモデリングガイドラインへのリンクもいただければ幸いです。