4

たくさんのDB書き込みを必要とするErlangアプリケーションを開発しています。私のスキーマには、主キーに加えて、一意の制約が適用された別の属性があります。

ID、unique_constraint_field、およびその他のフィールドがあるとします。更新しようとしているunique_constraint_field値の値が他の行にすでに存在していないことを前提として、一意のIDに対応するDBの行を更新する必要があります。

更新の量が多いため（各更新は1行にのみ影響します）、実行する必要があります（低レイテンシも必要です）更新ステートメントではなく、主キーとその属性の一意の制約に依存して重複をキャッチしますサブクエリを使用します。これにより、1回のクエリで更新を実行でき（95％の確率で発生）、残りの5％で例外をキャッチして、主キーまたは一意の属性違反について必要なアクションを実行できます。

現在、ODBCmysqlドライバーを使用しています。ただし、ドライバは、エラーに対して非常に一般的なエラーメッセージを返します。エラーをキー違反と見なすと、現在私のプロトタイプは正常に機能していますが、このモデルには明らかにかなりの欠陥があります。erlangからmysqlに接続するための他の適切なドライバー/方法が見つかりません。

ErlangとMnesiaが非常にシームレスに融合するため、Mnesia（速度要件のメモリのみのモード）に切り替えることを考えています。ただし、Mnesiaには、単一のクエリでDB更新を実行するために使用できる一意のキー制約がないことがわかります。

Erlang内からこの要件を実装するための最良の方法として提案が必要です。Mnesiaで条件付き更新を実行する方法はありますか？または、他に検討すべき高速DBの代替手段はありますか？どんな助け/洞察も大歓迎です。

4

3 に答える 3

2

mnesia調整しない限り、大量の書き込みでクラッシュする可能性があります。ただし、のように見える複雑な主キーを使用できます。これにより、更新がはるかに簡単になります。大量の書き込みを処理するために特別に作成されたディスクテーブル上のosmosforと呼ばれる新しいerlangライブラリもあります。{ID, UniqueConstraint}ordered_set

于 2009-07-26T15:34:07.823 に答える
1

最善の解決策はわかりませんが、レコード用とインデックス用の2つのテーブルを作成し、インデックスunique_constraint_fieldをチェックして更新するトランザクションのCRUD操作から各CUDを処理します。理由は、mnesiaではインデックスタイプを設定できず、常に重複バッグであるためです。とにかくあなたのインデックスはユニークになるので、それは追加のパフォーマンスペナルティを導入するべきではないと思います。mnesiaインデックス機能を使用する場合でも、独自のCUD操作を作成する必要があり、結果は2つのテーブルを使用する場合とほぼ同じように見えます。幸い、mnesiaは開発者の労力を最小限に抑えてネストされたトランザクションを処理します。これは、従来のRDBMSと比較して比較的簡単です。

于 2009-07-02T09:09:00.387 に答える
1

Ulf Wigerは、mnesiaをリレーショナルデータベースとして使用できるライブラリをリリースしました。これは「rdbms」と呼ばれ、数年前のものであり、長い間更新されていませんが、おそらくそのまま使用することも、少なくとも彼の作業に基づいて対処することもできます。必要に応じてソースを取得します。

それについての彼の説明：

'rdbms' contribが、複合属性と、インデックス値が一意である必要があることを指定するオプションを含むユーザー定義のインデックス作成のサポートを提供することにより、これに対する解決策を提供したという私の標準的な応答を無視します。

Rdbms / has /は商用利用されていますが、一般的に商用利用の準備ができているとは思いません。ユーザーからのプレッシャーを感じていないので、しばらくは何もしていませんが、それを変更したい人はもちろん、私に連絡して自分の主張を主張してください。

http://ulf.wiger.net/rdbms/doc/rdbms.html （ドキュメントにはまだまだ多くの要望があります。上記を参照してください。）

'unique'制約について言及しているドキュメントはここにあります。パフォーマンスが低下する可能性があります。mnesiaは、Key-Valueストレージであることが意図されています。正確には思い出せませんが、「一意の」インデックスを定義すると、それらをチェックするときにフルテーブルトラバーサルが必要になる可能性があります。

全体として、それは古いので、おそらくそれを実行するのに問題があるでしょう。それについてはtrapexitスレッドを参照してください。それがどのように行われたかを研究するためにそれを使用することはより良い考えかもしれません。

于 2009-07-17T18:41:01.727 に答える