問題タブ [ets]

何千ものプロセスを含む erlang アプリケーションがあるとします。タプル、リスト、または任意の erlang 用語である単一のリソース X があり、これらすべてのプロセスがいつでもそこから何かを読み取り/選択する必要があるとします。

このような状況の例としては、クライアント プロセスがリモート マシンで読み書きする必要がある API システムなどがあります。読み取り/書き込み要求ごとに、新しい接続を作成したくない場合があります。したがって、接続のプールを作成し、それらを開いているパイプ/ソケット/チャネルのプールと見なします。

現在、このリソースのプールは、読み取りまたは書き込みの要求ごとに、そのプロセスが利用可能な開いているチャネル/リソースを取得するように、何千ものプロセスによって共有されます。

質問は、プロセス (単一のプロセス) がこの情報をプロセス ディクショナリまたは受信ループに保持している場合はどうなるかということです。これは、空きリソースが必要になるたびに、すべてのプロセスがこのプロセスにメッセージを送信する必要があることを意味します。この単一のリソースに対する需要が高いため、この単一のプロセスは常に巨大なメールボックスを持つことになります。

または、ETS テーブルを使用して、行を 1 つだけにすることもできます#resources{key=pool,value= List_of_openSockets_or_channels}。しかし、これは、すべてのプロセスが (高い確率で) 同じ瞬間に ETS テーブルから同じ行を読み取ろうとすることを意味します。

10,000 のプロセスが同じ行/レコードに対して同時に/ほぼ同時に読み取りを試行した場合、ETS テーブルはどのように処理しますか? それでも、プロセスを使用する場合、そのメールボックスは、10,000 のプロセスが同時に同じリソースに対してメッセージを送信する場合 (各リクエスターに返信する必要があります)。そして、このアクションは非常に頻繁に発生する可能性があることを覚えておいてください. プロセスが必要なものをより速く取得できるように、どのオプション（プロセスが何とかダウンするという可用性の問題を無視する）は、より高いスループットを提供しますか？

Erlang VM で需要の高いデータ構造を処理して、数百万のプロセスに非常に高速にアクセスできるようにする、他に良い方法はありますか?

私は Erlang を学んでいるので、これは Erlang 設計の選択についての理解を深めるための質問です。

ETS データ構造 (辞書/ツリー) が Erlang の組み込み型 (リスト/タプルなど) とは異なる方法で扱われるのはなぜですか。つまり、それらはガベージ コレクションされず、変更可能であるため、それらを使用するすべての関数には副作用があります。メモリ リークを避けるために ETS テーブルを追跡しなければならないのは、特に煩わしいようです。

Erlang がリストのように振る舞う (不変でガベージ コレクトされる) 辞書データ型をもたない理由はありますか?

ETSは、コピーが非常に高価な構造のような大規模なデータベースにのみ使用され、それ以外の場合はキー/値データ構造にタプルのO(n)リストを使用するという前提ですか?

R の将来の値を予測するために、forecast パッケージの ets() および auto.arima() 関数を使用しています。これら 2 つの中で最適なモデルを選択するには、どの基準を使用する必要がありますか?

以下は、ets (data.ets) と auto.arima (data.ar) からの精度出力です。

および各モデルの AIC は次のとおりです。

以下は、ets と auto.arima の両方の適合モデルです。

親切に助けてください。

当座預金口座と普通預金口座も保持する ETS を使用して銀行口座管理システムを作成していますが、erlang 変数は不変であるため、一連の口座番号を生成して保持する方法がわかりません。

では、アカウント番号を生成して保存する関数を実装して、次回アカウントが作成されたときに次のアカウント番号を前のアカウント番号に割り当てるにはどうすればよいでしょうか?

erlang のメモリ内キャッシュ システムに関する提案が必要です。

1. キャッシュ アイテムはキー値ベースのストレージです。key は通常 ASCII 文字列です。value は erlang の型で、number / list / tuple / などがあります。
2. キャッシュ項目はどのノードでも設定できます。
3. キャッシュ アイテムは、どのノードでも取得できます。
4. キャッシュアイテムは、異なるサーバー上であってもすべてのノードで共有されます
5. ダーティ リードが許可されているため、ロックやトランザクションによってパフォーマンスが低下することは望ましくありません。
6. 完全に分散されており、集中型のマシンやサービスはありません。
7. 良い成果
8. 簡単なインストールと展開、構成とメンテナンス

最初の選択は記憶喪失症のようですが、経験がありません。それは私の要件を満たしていますか？どのようにパフォーマンスを期待できますか?

別のオプションですがmemcached -- 、memcachedデーモンが別のOSプロセスからのものであるため、余分なシリアライゼーション/デシリアライゼーションが実行されるため、パフォーマンスはmnesiaよりも低いと思います。

プロセス内で一意のアトム名を持つ ETS テーブルを作成しています。プロセスが実行され、終了します。プロセスの終了により、ETS で消費されたリソース (メモリ) がクリアされますか?

を使用した後、ETS テーブルをクリーンアップ/削除する必要がありますか?

これは私がやっていることです:

.

同じアトム識別子で別の ETS テーブルを作成しようとすると、エラーが発生するようです。そのため、上記は機能しないようです。上記のとおり、別のプロセスから挿入する必要があるため、ETS テーブル オプションをプライベートにすることはできません(プライベートが ETS リソースをクリアする場合に備えて)。

つまり、最終的な質問: 特定の ETS テーブルからすべてのリソースを削除する方法は?

2 つの ETS テーブルを 1 つの ETS テーブルに結合してみます。私が知っている唯一の方法は、3 番目のテーブルを作成し、2 つのテーブルのレコードを 3 番目のテーブルに挿入することです。より良い方法はありますか？