Iamは、ユーザーが私のサービスを使用して同時に何百もの通話を発信できるようにするVOIPプラットフォームを開発しています。
アスタリスクは、すべての通話詳細レコードをCDRテーブルに保存します。私のシステムの可能な限り最高のアーキテクチャのために、このテーブルを保持するのに最適な場所を知りたいです。
それをAsteriskBoxに保持し、cronを実行してデータベースサーバーと同期する必要があります。または、Asterisk BoxからDBサーバーを直接呼び出し、Asteriskを介してリモートですべてのデータをデータベースに直接記録する必要があります。
すべての人が、両方のアーキテクチャに独自の長所と短所があると感じています。専門家の助けを借りて、長期的なスケーラビリティと持続可能性のための最善の道を提案してもらいたいと思います。
最適なアーキテクチャは、分散ノード (サーバー) を使用することです。つまり、異なるノードで PBX、Web サーバー、および DB サーバーを使用します。PBX は、すべての呼び出しの後に CDR テーブル (これは DB サーバーにある必要があります) にデータを入力します。レポートと請求の目的で、これらのレコードを Web サーバーから取得できます。
Cron を使用して DB テーブルを同期することはお勧めしません。システム リソースと帯域幅も消費するためです (この cron はシステム リソースを消費するたびに実行され、Db と同期すると帯域幅が使用されるため)。 cron の実行に使用されるシステム リソース
第 2 に、CDR を PBX と同じノードに配置すると、cron によりシステム リソースが節約されますが、レポートと請求のために、このノードからデータをフェッチする必要があるため、帯域幅を節約できません。現在あなたが話しているように、このスキーマには大きな欠点があります。同時に 100 の呼び出し 1000 以上の場合はどうでしょうか??
この場合、必ず PBX クラスタリングを使用する必要があります。その場合、PBX クラスターによって同期される集中型の DB サーバーが必要になります。
したがって、あらゆる面で、私が提案するアーキテクチャはあなたのニーズに完全に適合します。質問で述べられているように、数百の同時呼び出しのみが必要であると述べられているように、PBx を他のノードに配置しながら、DB および Web サーバーに単一のノードを使用できます。
別のデータベース サーバーを使用して CDR を保存することは、趣味のアスタリスク実装以外では正しいオプションです。Asterisk を使用すると、CDR の宛先データベースを簡単に選択でき、MySQL、Postgresql などの無数の異なるデータベース オプションがあります。MSSQL など。Asterisk CDR の実装は単一のテーブルのみを使用するため、実際にはデータベース サーバーとの統合は非常に単純です。
非常に注意すべきことの 1 つは、データベース サーバーまたはデータベース サーバーと Asterisk サーバー間の接続に問題がある場合、通話処理に影響を与えることです。問題がある場合、CDR を書き込むためにデータベースに接続しようとしている間、Asterisk はブロックされます。実行中は、他の呼び出しは処理されません。CDR は課金に不可欠であり、それらをログに記録できないということは、通話が無料になる可能性があることを意味するため、これはおそらく望ましい動作です。バックアップとして、Asterisk サーバー上の .csv ファイルへの CDR ロギングをベルトとブレースのアプローチとして設定することもできます。
アスタリスクからデータベースに直接接続できるなら、それを使うべきだと思います。いくつかのアスタリスクのインストール (1 つの非常に大きなコール センターを含む) で見たことがありますが、うまく機能しました。
Asterisk からデータベースへの直接接続がないが、他のサービスへの HTTPS 接続がある場合、または課金テーブル構造が Asterisk テーブルと互換性がない場合に使用するもう 1 つのオプションは、CSV CDR ファイルを使用することです。このようなファイルは、数分ごとに CRM システムに送信されます。cron と小さな Python スクリプトを使用します。このようにして、CRM 課金システムで使用される CSV 形式に簡単に適応できます。