会話データの増加の抑制

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：11分

    • 操作が実行されると、会話関連テーブルのサイズが大きくなり、システムパフォーマンスに影響を与える可能性があります。十分なレコードを保持しながらパフォーマンスを向上させるには、過去のデータをアーカイブし、進行中の会話に使用されるテーブルをクリーンアップするプロセスを設定します。

    推奨されるアクティベーション

    仮想エージェントやエージェントチャットの頻繁な使用に関連するデータの増加を制限するには、次の表のクリーナージョブをアクティブ化します。

    テーブル名 クリーナージョブのサマリー 推奨
    AWA エージェントチャネルの可用性 [awa_agent_channel_availability] 90 日以上経過した AWA エージェントチャネルの可用性ログを削除します。 アクティブ化が推奨されます。
    AWA エージェントの在席状況 [awa_agent_presence] 90 日以上経過した AWA エージェントプレゼンスログを削除します。 アクティブ化が推奨されます。
    AWA エージェントの在席履歴 [awa_agent_presence_history] 180 日以上経過 AWA エージェントの在席履歴ログを削除します。 アクションは必要ありません。既にアクティブ化されています。
    AWA ドキュメントサイズ [awa_document_size] 90 日以上経過した AWA ドキュメントサイズのログを削除します。 アクティブ化が推奨されます。
    AWA インスタンス統計情報 [awa_instance_stats] 60 日以上経過した AWA インスタンス統計ログを削除します。 アクションは必要ありません。既にアクティブ化されています。
    AWA キュー統計情報 [awa_queue_stats] 60 日以上経過した AWA キュー統計情報ログを削除します。 アクションは必要ありません。既にアクティブ化されています。
    AWA サービスチャネル統計情報 [awa_service_channel_stats] 60 日以上経過した AWA サービスチャネル統計ログを削除します。 アクションは必要ありません。既にアクティブ化されています。
    AWA 作業アイテム [awa_work_item] 承認またはキャンセルされた作業アイテムログのうち、90 日以上経過した AWA 作業アイテムログを削除します。 アクティブ化が推奨されます。
    インタラクション [interaction] 90 日以上経過したインタラクションログを削除します。 アクティブ化が推奨されます。
    インタラクション JSON BLOB [interaction_json_blob] 60 日以上経過したインタラクションの JSON BLOB ログを削除します。 アクティブ化が推奨されます。
    ライブグループプロファイル [live_group_profile] 60 日以上経過したライブグループプロファイルログを削除します。 アクティブ化が推奨されます。
    コンシューマー [sys_cs_consumer] ユーザー ID [user_id]=5136503cc611227c0183e96598c4f706 で、60 日以上経過したコンシューマーログを削除します。 既にアクティブに設定されているか、名前 [name] = ゲストユーザーを条件に追加してください。
    コンシューマーデバイスコンテキスト [sys_cs_consumer_device_context] 参照カスケードルール [reference_cascade_rule]=delete ルールをコンシューマーアカウント [consumer_account] 列に追加します。 アクションは必要ありません。
    会話 [sys_cs_conversation] 60 日以上経過した会話ログを削除します。 アクションは必要ありません。既にアクティブ化されています。

    クリーニングする必要があるテーブル

    これらのテーブルは、長時間実行されているインスタンスでは数百万件のレコードに増加する可能性があるため、クリーンアップする必要があります。

    • エージェント在席履歴 [awa_agent_presence_history]
    • AWA ドキュメントサイズ [awa_document_size]
    • AWA 作業アイテム [awa_work_item]
    • コンシューマー [sys_cs_consumer]
    • コンシューマーデバイスコンテキスト [sys_cs_consumer_device_context]
    • 会話 [sys_cs_conversation]
    • インタラクション [interaction]
    • インタラクション JSON BLOB [interaction_json_blob]
    • ライブ グループ プロフィール [live_group_profile]

    会話メッセージ [sys_cs_message] テーブルやライブフィードメッセージ [live_message] テーブルなど、他の関連テーブルも大きくなる可能性があります。これらのテーブルには reference_cascade_rule_delete 前のリストのテーブルのクリーニングの副作用としてクリーニングされる原因となる属性があります。

    テーブル内のどのレコードを削除する必要があるか

    自動フラッシュ構成では、[ 一致フィールド ] と [ 経過時間 (秒)] フィールドを選択できます。[一致フィールド] フィールドはテーブルの日付列に対応し、[経過時間 (秒)] フィールドは削除がトリガーされるタイミングを示します。レコードの [一致フィールド ] フィールドの日付が [ 経過時間 (秒 )] フィールドよりも過去のポイントに達すると、クリーナーは実行時にレコードを削除します。

    理想的には、[ 一致フィールド ] フィールドは、レコードがアクティブになっている期間を示す必要があります。次の表の列は、問題のテーブルの [Matchfield ] フィールドと同様に適切に機能し、[ Conditions ] フィールドに追加条件が表示されます (指示されている場合)。

    テーブル 列 列はインデックス付きですか? 他の条件
    AWA エージェントチャネルの可用性 [awa_agent_channel_availability] 更新日時 (sys_updated_on) いいえ agent.active=false
    AWA エージェントの在席状況 [awa_agent_presence] 更新日時 (sys_updated_on) いいえ
    AWA エージェントの在席履歴 [awa_agent_presence_history] 更新日時 (sys_updated_on) 要
    AWA ドキュメントサイズ [awa_document_size] 更新日時 (sys_updated_on) いいえ
    AWA 作業アイテム [awa_work_item] 更新日時 (sys_updated_on) 要 stateINaccepted、cancelled
    インタラクション [interaction] 更新日時 (sys_updated_on) 要
    インタラクション JSON BLOB [interaction_json_blob] 更新日時 (sys_updated_on) いいえ
    ライブグループプロファイル [live_group_profile] 更新日時 (sys_updated_on) いいえ
    コンシューマー [sys_cs_consumer] 更新日時 (sys_updated_on) いいえ name=ゲストユーザー
    会話 [sys_cs_conversation] 更新日時 (sys_updated_on) いいえ

    interaction.closed_at と sys_cs_conversation.conversation_completed は、失敗した会話や一部のクローズ済みインタラクションの値を持たないため、[ 一致フィールド ] フィールドの適切なオプションではありません。適切なステータス変更が発生したときにこの日付が空の場合にこの日付を設定するビジネスルールを使用してギャップを埋めることができますが、わかりやすくするために、これらのテーブルには [sys_updated_on] フィールドを使用します。

    その他のテーブルは、クローズされたチャットのみが削除されるようにする [ステータス] フィールドの条件によって制限できます。一般に、インタラクションを数日以上開いたままにしておくことは避けるべきであるため、これらの条件を省略することで、クエリを簡素化し、最後の更新後に高速に実行できます。ケースなどの実行時間の長いタスクも表示されるため、awa_work_itemテーブルのステータスがより重要になる場合があります。

    sys_cs_consumerテーブルの問題は、通常は新しい会話を既存のユーザーと照合するためにこれらのレコードを保持する必要がありますが、ゲストユーザーの場合は会話ごとに異なるレコードが作成されることです。

    sys_cs_consumer_device_context テーブルには、CS コンシューマーアカウント [sys_cs_consumer_account] テーブルへの参照がありますが (それ自体が sys_cs_consumer テーブルへの参照があります)、参照は reference_cascade_rule=delete でマークされていません。このルールをコンシューマーアカウント参照に追加することをお勧めします。これにより、クリーナーが sys_cs_consumer テーブルと sys_cs_consumer_account テーブルのレコードを削除するときに、これらも削除されます。

    awa_agent_presenceテーブルとawa_agent_channel_availabilityテーブルは、他のテーブルと同じようにチャットごとに大きくなることはありませんが、アサインエンジンによって定期的にアクセスされるため、アクティブでなくなったユーザーからの古いエントリが生じる可能性があります。長い未使用のエントリは、ここでもクリーンアップする必要があります。awa_agent_channel_availability列は頻繁に更新されない可能性があるため、特に注意する必要があります。このため、非アクティブなユーザーに関連付けられたレコードのみを削除できるように、そのクリーナーに追加条件を追加する必要があります。

    レコードを安全に削除できるタイミング

    レコードを安全に削除できるタイミングを決定する際には、いくつかの考慮事項があります。

    • 進行中の会話のレコードは削除しないでください。

      セッションベースのチャット会話の場合、経過時間しきい値はわずか数日です。SMS/メッセージング会話が含まれる場合、経過時間しきい値は数週間以上に延長される場合があります。これを評価する方法の 1 つは、com.glide.cs.*_idle_timeout という形式のすべてのプロパティを調べて、値が最も高いプロパティを見つけることです。

    • 最近のアクティビティに関するダッシュボード/レポートに寄与するレコードは削除しないでください。

      [インタラクション - 高度なアナリティクスの AWA ] ダッシュボードには、過去 3 か月を振り返る週次の傾向インジケーターが含まれています。これを完全にサポートするには、インタラクションレコードとawa_work_itemレコードを少なくとも 90 日間保持する必要があります。

    • 後で参照するためにデータをアーカイブする必要がある場合は、レコードを削除しないでください。

      このタイミングは、必要なアーカイブを行うために追加されるカスタムロジックのタイミングによって異なります。これは、決定要因にならないように十分に早く実行されるように設定できるはずです。

    上記を考慮して、次の経過時間 (秒) のしきい値が推奨されます。
    • インタラクション、awa_work_item:7776000(90日-ただし、週次トレンドインジケーターを使用しない場合、またはルックバックを短い期間に設定する場合は、これを短縮できます)。
    • sys_cs_conversation、live_group_profile、interaction_json_blob、sys_cs_consumer:2592000 (30 日) または 5184000 (60 日)。

    パフォーマンスに関する考慮事項

    インデックスsys_updated_on欠落しているテーブルにインデックスが必要ですか?

    テストは、12,000,000+ のインタラクションがあるインスタンスで実行され、テーブルのクリーンアップは、sys_updated_onフィールド (インタラクション) にインデックスがあるテーブルとないテーブル (interaction_json_blob) で構成されています。どちらの場合も、最初の実行とその後の実行では、削除に費やされた時間 (場合によっては何分も) が、レコードのクエリに費やされた時間 (2 秒以下) をはるかに上回りました。この結果を考えると、パフォーマンスへの影響が最小限に抑えられるため、テーブルにインデックスを追加する必要はありません。

    最初のテーブルクリーナージョブと繰り返されるテーブルクリーナージョブはいつ実行する必要がありますか?

    通常、テーブルクリーナー sys_triggerは 1 時間に 1 回実行されます。古いレコードが多数あるテーブルに 1 つ以上のクリーナーが設定されている場合、その最初の実行中に実行される削除の数が非常に多くなり、システムに余分な負荷がかかる可能性があります。テーブルクリーンアップ構成を調整してアクティブ化する前に、このテーブルクリーナースケジュールを一時的に変更して、次回の実行が営業時間外 (通常はシステムの負荷が軽い時間帯) に行われるようにします。

    営業時間外がない場合は、テーブルクリーナーを管理するプロパティがいくつか役立ちます。特に、glide.db.tablecleaner.chunk_delete_max_time_spent は、クリーナーが 1 回の実行中にレコードの一括削除を試みる時間を制限します。値は秒単位で指定され、デフォルトは 1200 (20 分) です。つまり、ベースシステムのセットアップでは、テーブルクリーナーは 1 時間ごとに最大 20 分間実行されます (参考までに、1 つのテストでは、カスケード削除を含めて、20 分間に約 400,000 件のインタラクションが削除される可能性があります)。1 時間ごとに 20 分というのが強すぎる場合は、プロパティ値を減らすことができます。