問題タブ [ets]

私は ets の使い方を学んでいますが、私を悩ませていることの 1 つは、ときどき*、 … をets:matchスローすることbad argumentです。そして、それ以降、後続のすべての呼び出し (以前は機能していた呼び出しも含む) も : をスローしbad argumentます。

システムを「リセット」して、ets(つまり、シェルから) 再度クエリできるようにする方法はありますか?

*: 問題を再現することはできませんでしたが、「他のこと」をしようとしているときにかなり頻繁に発生します。

erlangサーバーを構築しています。ユーザーはhttpリクエストをサーバーに送信して、ステータスを更新します。サーバー上のhttp要求プロセスは、ユーザーステータスメッセージをメモリに保存します。サーバーは毎分、すべてのメッセージをリモートサーバーに送信し、メモリをクリアします。ユーザーが1分間に数回ステータスを更新すると、最後のメッセージが前のメッセージを上書きします。すべてのメッセージを読み取ってからクリアするまでの間、他のプロセスがステータスメッセージを書き込めないことが重要です。

それを実装するための最良の方法は何ですか？

1. dictを持つgen_server。キーはユーザーIDになります。dict：store / 3は、ステータスを更新または作成します。gen_serverは、「トランザクション」の問題を解決します。

2. ram_copiesを含むmnesiaテーブル。トランザクションを処理し、gen_serverを実装する必要はありません。このソリューションにはオーバーヘッドが多すぎますか？

3. より軽量でgen_serverを持つETSテーブル。ETSで取引を行うことは可能ですか？すべてのメッセージを読んでからクリアするまでの間にテーブルをロックするには？

ありがとう

私は次のets構造を持っています:

ets:select と fun2ms を使用して set1 と set2 の交差を取得したい場合、結果は [item1, item2] になります。

私はets:selectとfun2msでそれを達成しようと何時間も費やしましたが、成功しませんでした。ets:select と fun2ms の使用を手伝ってもらえますか?

すべての答えをありがとう！

ps: sets モジュールについては知っていますが、ets とこの正確なデータ構造を使用する必要があります。

私は次の項目を持つetsを持っています:

そして、私はリストを持っています[[at, door, me],[on, floor, chair],[small, bannanas]]

ets テーブル内のすべてのアイテムをリスト内のアイテムと比較する必要があり、最初のアイテムが同じアトムである場合は、丸括弧内のアイテムを置き換えます。したがって、 がある場合[at, door, me]、それは と一致し、すべての ets テーブルでアトム ドア[at, {other_place}, me]を変更する必要があります。{other_place}

ets:foldl短いバージョン：すべてのETSレコードを繰り返し処理するときに、それらを削除するために使用しても安全ですか？

ETSテーブルが情報を蓄積していて、それをすべて処理するときが来たとします。レコードがテーブルから読み取られ、何らかの方法で使用されてから削除されます。（また、テーブルがであると仮定すると、private並行性の問題は発生しません。）

別の言語では、同様のデータ構造で、for ... eachループを使用して、すべてのレコードを処理してから、hash / dict / map/whateverから削除することができます。ただし、etsモジュールにはforeach、たとえばのようにはありませんlists。

しかし、これはうまくいくかもしれません：

これは好ましいアプローチですか？少なくとも正しく、バグはありませんか？

処理中にデータ構造を変更することについて一般的な懸念がありますが、ets：foldlのドキュメントは、ETSが内部のレコードの変更に非常に慣れていることを示していますfoldl。私は基本的にテーブルをきれいに拭いているので、確実にしたいと思います。

私はsetテーブルでErlangR14Bを使用していますが、Erlangバージョン、またはテーブルのタイプにも注意点があるかどうかを知りたいです。ありがとう！

だから私はETSを使ってきました - うまくいきます。ただし、ルート データのキャッシュとして使用します。これは、モジュールのロード時にロードし、変更が行われたときに保存します (書き込みよりも読み取りの方がはるかに多い)。

私は、DETS を使用すると物事がずっときれいになると考えていました。テーブルの永続性の管理について心配する必要はありません。これは DETS の有効な使い方でしょうか? （サイズは問題ではありません。主に読み取りパフォーマンスの大幅な向上が懸念されます-すべてのデータは簡単にメモリに収まります）。

私はqlcを持っています

ここで、Tmpはバッグタイプのセットであり、Refはテストする必要のある特定の識別子です。

Etsには、次のような数百から数千のエントリが含まれています

つまり、各Refには、1つの定義、1つまたは2つ（4つのうち）のステータス、0以上（ほとんどの場合3つ以下）のパターン、および0つ以上（ほとんどの場合3つ以下）のタグがあります。

ある特定の識別子が他の識別子によってブロックされているかどうかをテストする必要があります。タグ上のパターンのいずれかに一致する識別子の数=パターンおよびステータス=パターンステータスがパターン制限以上の場合、ブロックされます。

qlcを最適化する方法はありますか？

((1 つのスレッドで複数の質問をすることをお許しください。それらは関連していると思います。))

こんにちは、モジュールごとのプリコンパイル済みデータに関して、Erlang に存在するベスト プラクティスについて知りたいと思いました。

例:私は、以前から知られている非常に複雑な正規表現を多用するモジュールを持っています。re:compile/2 のドキュメントには次のように書かれています。re の mp() データ型はまったく指定されておらず、ターゲットに依存しないビームが必要な場合はコンパイル時に配置できないため、実行時に RegEx をコンパイルする必要があります。((注: re:compile/2 は単なる例です。メモ化する複雑な関数はすべて私の質問に適合します。))

Erlang のモジュール (できます)には、モジュールがロードされたときに 1 回-on_load(F/A)実行する必要があるメソッドを示す属性があります。そのため、このメソッドでコンパイルする正規表現を配置し、結果をという名前の新しいets テーブルに保存できます。?MODULE

ダンの回答後に更新されました。

私の質問は次のとおりです。

• 私がetsを正しく理解している場合、そのデータは別のプロセスに保存され（プロセス辞書とは異なる方法で）、etsテーブルの値を取得するには非常にコストがかかります。(私が間違っている場合は、私が間違っていることを証明してください!) スピードアップのために、ets の内容をプロセス辞書にコピーする必要がありますか? (注意: データは決して更新されません。)
• すべてのデータを (多くのテーブル項目ではなく) 1 つのレコードとして ets/process ディクショナリに入れることの (かなりの) 欠点はありますか?

作業例:

私はO'ReillyErlangプログラミングの本を見ていますが、次のようなerlangシェルで実行される例があります。

ただし、コードで（シェルではなく）同様のことを行うと、次のようになります。

私はFUBARを取得します：

（余談ですが、なぜエラーが'関数で呼び出されないのだろうか...'おそらくそうio：format（ "〜p"、TheErrorMessage）は行を折り返しますか？）

とにかく、私はets：foldlを支持してselectを放棄しました。後者は機能し、楽しみの例外を介して、最初のアイテムが見つかったときにトラバーサルを終了できるためです。しかし、私はまだ興味があります...

...なに？（私はparse_transformでいくつかの読み取りを行いましたが、接続が欠落していることをerlangするのに十分な新人です。）

私は、サーバー コンポーネントが完全に erlang で書かれている既存の (ゲーム) プロジェクトに参加しています。場合によっては、このシステムからデータを取得するのが非常に困難になることがあります (プレーヤー 56 がいくつのウィジェットを持っているかに興味があります)。それを所有するプロセスから取得します。データを所有するプロセスを見つけることができると仮定すると、そのプロセスにメッセージを渡してメッセージが返されるのを待つことができますが、これは複数のマシンにうまく拡張できず、応答時間が長くなります。

このゲームに存在するタスクの多くを、複数のプロセスによって頻繁にアクセスされる情報が保護された ets テーブルに格納されるシステムに置き換えることを検討してきました。テーブルの所有者は、更新メッセージ (プレーヤーが 5 つのウィジェットを使用したばかり) を受信し、それに応じてテーブルを更新するだけです。すべての例外をキャッチし、単純に次の更新メッセージに進みます。プレーヤーが愚か者を購入するのに十分なウィジェットを持っているかどうかを知りたいプロセスは、テーブルをのぞくだけで済みます。(はい、ウィジェットの数を減らすメッセージがバッファーにある可能性があることは理解していますが、その問題は制御下にあります。)

残念ながら、私の質問は質問ではなく、コメントのリクエストです。役に立ち、十分に説明または参照されているものは何でも賛成します。

そのような実装の可能性のある欠点は何ですか? 私が興味を持っているのは、ライターが 1 人で複数のリーダーがいる場合に見られる可能性が高いロック競合の詳細、これを複数のマシンに分散する際にどのような問題が発生するか、および特に:この前。