問題タブ [document-database]

私はアプリケーションを持っています。オブジェクト グラフを Mongo に書き込みます。特定のコレクションについては、データを正規化し、リレーショナル データベース (SQL Server または SQLite) にミラーリングしたいと考えています。

これを行う最善の方法は、コレクションで MapReduce ジョブを使用することだと考えていました。これは正しい方法でしょうか？これは可能ですか？それが違いを生む場合、私たちはWindowsで実行しています。

アップデート

私が探しているのは、JavaScript の MapReduce ジョブがこれにアプローチする最善の方法であるかどうかについての一般的なガイダンスです。2 つのフィールドを持つオブジェクトがあるFirstNameとしLastNameます。FirstNameこれをコレクションに書き込むときは、リレーショナル データベース (との 2 つの列があるLastName) に行が必要です。

もちろん、コレクションに書き込む時点で、アプリケーションの SQL テーブルにこれを書き込むこともできます。しかし、おそらくそれを行うのに適した場所はデータベース内であると思いました。これにより、必要に応じて、データをリレーショナル データベースに書き込む前に整形することができます。

少し詳しく説明したので、明示的には尋ねなかったが関連する他のいくつかの質問を見ることができます。MapReduce ジョブを実行する JavaScript は、Mongo の外部にアクセスすることさえできますか? サンドボックス化されていますか？そして、これを MapReduce ジョブとして実行すると、書き込みパフォーマンスに影響を与えます (そうではないと思いますが、IANAE、したがって質問です)。

RavenDB でのシリアライズ/デシリアライズに問題があります。データの保存に問題はありませんが、ドキュメントのクエリ時に問題があります。

Entity Framework v4.3 POCO ジェネレーターから生成されたかなり複雑な Account クラスがあります。

オブジェクトをクエリしてリストとして返すと、.NET リフレクション エラー「オブジェクトがターゲット タイプと一致しません」が発生します。

これは、保存時に他のネストされたクラスと nullables もシリアル化されているためであると考えましたが、次のように AccountWrapper という「ラッパー」クラスを作成できることがわかりました。

ここでは手動で JSON.NET (そうです、RavenDB Buid 960 に同梱されているものと同じ .dll) を使用して SerializedText フィールドにデータを入力し、それを RavenDB に保存します。このプロセスは機能します。RavenDB から AccountWrapper オブジェクトを取得し、SerializedText の内容を手動で逆シリアル化します。これにより、デフォルトの (デ) シリアル化プロセスに問題がある可能性があると思われます。

私の質問は、ドキュメントを保存/ロードするときに、RavenDB のシリアライズ/デシリアライズ機能を手動でオーバーライドできる方法はありますか? もしそうなら、誰かがそうする方法のきれいな例を見せてもらえますか? JsonConverter.Serialize()次に、JSON.NET の一部として標準を使用するようにすることができます。

クエリを実行する必要がある「実際の」データにインデックスを付けることができないため、AccountWrapper を使用することは明らかに悪い考えです。

(以下の例外の完全なスタック トレース)

ドキュメント データベース (CouchDB など) とグラフ データベース (Neo4j など) の両方にエンティティを格納するセットアップを検討しています。理論的根拠は、各エンティティ情報 (データ、ブロブ、値、複雑な内部構造) をドキュメント データベースに格納し、エンティティ関係 (親、子、関連エンティティ) をグラフ データベースに格納することです。

誰かがこのような設定をした/見た/噛まれたことがありますか? どのような問題が予想されますか? 最初に気になったのは、2 フェーズ コミットです。しかし、ここでもバックアップに問題があります。

ドキュメント データ ストアとキー値データ ストアを使用するのはいつですか??

ありがとうございました！

最後に結果を見る

ドキュメントDBを使用したい（さまざまな理由で）-おそらくCouchDBまたはMongoDB。ただし、複数のドキュメントのトランザクションにもACIDが必要です。

ただし、「追加のみ」のモデルで作業する予定です。変更は新しいドキュメントとして追加されます（追加は追加、更新はコピー+変換データの追加、削除は同じID +削除フラグを持つ空のドキュメントの追加）。定期的に、データベースで圧縮を実行して、最新でないドキュメントを削除します。

それを念頭に置いて、次のアイデアに穴はありますか？

進行中の現在のトランザクションのコレクションを維持します。このコレクションは、進行中のトランザクションのトランザクションID（GUID +タイムスタンプ）を持つドキュメントを保持します。

MVCCに少し似ていて、Gitに少し似ています。開始する前になんとか終了したことがわかっているトランザクションによって、取得コンテキストを設定しました。「トランザクションのリビジョン」ではなく「進行中のトランザクション」のリストを保持することで、単一のシーケンス（したがって単一の実行）を回避します。そしてもちろん、私はコミットされていないトランザクションを読むことを避け、競合のロールバックを提供します。

だから-これに穴はありますか？私のパフォーマンスはひどく損なわれますか？

編集1：お願いします-「複数のドキュメントトランザクションが必要な場合は、ドキュメントデータベースを使用しないでください」を槌で打たないでください。とにかく他の理由でドキュメントデータベースが必要です。

Edit2：取得トランザクションの開始後に開始されるトランザクションからのデータを回避するために、タイムスタンプが追加されました。タイムスタンプをシーケンスIDに変更する可能性があります。

Edit3：これが私が考えた別のアルゴリズムです-それは上記のものよりも良いかもしれません：

新しいアルゴリズム-理解しやすい（そして今回は修正できる可能性があります:)）

開始時にドキュメントはコミットされましたか？
現在実行中のトランザクション（取得を開始する前に開始されたが、その時点ではまだコミットされていないトランザクション）にトランザクションIDを持つドキュメントが表示された場合、それは望ましくありません。トランザクションID>=最上位のトランザクションID（取得を開始した後に開始されたトランザクション）のドキュメントが表示された場合、それは望ましくありません。

ドキュメントは最新（最新バージョン）ですか？
現在のトランザクションID（開始前に開始されたトランザクション）になく、最上位のトランザクションID（開始後に開始されたトランザクション）である、廃止されたドキュメントが表示された場合、過去にコミットを終了したトランザクションがありました。このドキュメントを廃止しました-したがって、私たちはそれを望んでいません。

ソートが損なわれないのはなぜですか？
並べ替えを最後の句として追加するため、実際の並べ替え作業が常に最初に表示されます。実際の並べ替えの「バケット」ごとに、異なるバージョンのモデルオブジェクトを表す複数のドキュメントを取得する場合があります。ただし、モデルオブジェクト間の並べ替え順序は変わりません。

カウンターがトランザクションをシリアルに（一度に1つずつ）実行しないのはなぜですか？
これはRDBMSではないため、実際にはトランザクションがないため、「更新の選択」の場合のようにトランザクションがコミットされるのを待ちません。別のトランザクションは、それが完了するとすぐにアトミックな変更を行うことができます。

圧縮：時々
、圧縮を行う必要があります。本当に古いドキュメントをすべて取得して、別のデータストアに削除します。これは、実行中の取得またはトランザクションには影響しません。

最適化：

1. 条件をクエリ自体に入れます。
2. すべてのインデックスにトランザクションIDを追加します。
3. 同じモデルオブジェクトIDを持つドキュメントが異なるノードにシャーディングされないようにしてください。

費用はいくらですか？
とにかく履歴と監査に複数のドキュメントバージョンが必要だとすると、追加のコストは、カウンターをアトミックに更新し、トランザクションレコードを作成し、各モデルオブジェクトの以前のバージョンを「封印」し（廃止マーク）、トランザクションドキュメントを削除することです。これは大きすぎてはいけません。上記の仮定が有効でない場合、特に検索の場合、追加コストが非常に高くなることに注意してください。

結果：

上記のアルゴリズムを実装しました（マイナーな変更を加えた改訂版）。機能的には、機能しています。ただし、パフォーマンス（少なくとも、マスタースレーブレプリケーショントポロジに3つのノードがあるMongoDBを超える場合、fsyncは必要ありませんが、「コミット」が終了する前にレプリケーションが必要です）はひどいものです。書いたばかりのものをさまざまなスレッドから常に読んでいます。トランザクションコレクションで一定のコレクションロックが発生し、インデックスが一定のロールオーバーに対応できません。10個のフィーダースレッドを使用する小さなトランザクションのパフォーマンスは、20TPSに制限されています。

要するに、良い汎用ソリューションではありません。

Mongoドキュメントを作成していて、値がない場合があるフィールド{key: value}がある場合、2つのオプションがあるように思われます。

1. 書き込み{key: null}、つまりフィールドにnull値を書き込みます
2. そのドキュメントにキーをまったく保存しないでください

どちらのオプションも簡単にクエリできます。{key : null}一方をクエリし、もう一方をクエリします{key : {$exists : false}}。

アプリケーションシナリオに影響を与える2つのオプションの違いを実際に考えることはできません（オプション2のストレージがわずかに少ないことを除いて）。

2つのアプローチのどちらかを他のアプローチよりも好む理由があるかどうか、そしてその理由を誰かに教えてもらえますか？

編集

質問をした後、2つのケースでインデックスの動作が異なる可能性があることにも気付きました。つまり、オプション2に対してスパースインデックスを作成できます。

いくつかのモデルのビューから計算を行う必要があります。例：

先生の見解で、gold_stars、silver_stars、bronze_starsの数を集計する必要があるとしましょう。ビューの値を集計する最もクリーンな方法は何ですか？after_updateコールバックを使用すると思いますが、もっと良い方法があるかどうかはわかりません。

アップデート

私が欲しいのは、先生が生徒全員が持っている金の星の数を表示し、次に銀、次に青銅を表示することです。

編集

私はドキュメントを正しく保存しているので、この質問の最初の部分は正しくありません。おそらくRavenDBの経験が浅いためです。ただし、単体テストでEmbeddableDocumentStoreを使用しているときに、RavenDBManagementStudioを開くことができるかどうかという疑問が残ります。

NUnitを使用した単体テスト中に、EmbeddableDocumentStoreにドキュメントを保存する際に問題が発生したようです。ドキュメントを実際に保存しているかどうかを確認するために、組み込みデータベースに接続しようとしています。

URL http：// computername：8080 /を開こうとすると（何らかの理由でraven dbは常に私のPCのコンピューター名を使用します）、ブラウザーの読み込みバーが回転し、単体テストを停止してURLを再試行するとChromeが表示します接続できなかったというメッセージが表示されます。コンテキストのコードを次に示します。

また、テストプロジェクトのルートにRaven.Studio.xapファイルがあります。

私はVS2012を使用しており、それが違いを生む場合は.Net4.5を使用しています。

私はエンティティのセットを持っていますそれらはすべて抽象クラスから派生しています

Nameすべてのエンティティを永続化するとき、フィールドをキーとして使用したいので、そのDocumentKeyGeneratorような実装をオーバーライドして提供します。

エンティティのリストを初めて永続化する場合は正常に機能しますが、再度永続化する場合は例外が発生します

RavenDBを使い始めたばかりなので、何が間違っているのか理解できませんか？

私は、ユーザーが簡単なテンプレートを作成して自分のWebサイトのページを開発できるプロジェクトに取り組んでいます。彼はそれらを保存し、完了したらインターネットに公開することもできます。

1. ユーザーが自分のテンプレートで作業しているとき、実行した作業のコピーを保存して、後でそのテンプレートに戻ることができます（電子メールのドラフトと同様）。
2. ユーザーによるこの保存された作業は、現在テンプレートページを解析することによってxmlファイルに保存されます。
3. これに代わる方法として、ページ全体を一意のユーザーIDに対してドキュメントデータベースに保存することを考えていました。これにより、解析を行う必要がなくなり、負荷と時間が削減されます。

今私の質問

1. xmlの代わりにドキュメントデータベース またはnosqlを使用して私が考えていることは可能ですか？
2. はいの場合、どちらがより柔軟に作業でき、保守が容易になりますか？
3. 他の操作にはphpとmysqlを使用しているので、ユーザーが作成したテンプレートのhtmlを保存するためだけにdocDBが必要です。