会話データの増加を制限する

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間：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] 承認またはキャンセルされた AWA 90 日以上経過した作業アイテムログを削除します。 アクティベーションが推奨されます。
    インタラクション [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] [コンシューマーアカウント [consumer_account] 列に参照カスケードルール [reference_cascade_rule]=delete ルールを追加します。 アクションは必要ない。
    会話 [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 属性があります。

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

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

    [ 一致フィールド ] フィールドには、レコードがアクティブになっている期間を示すのが理想的です。次の表の列は、該当するテーブルの [一致フィールド ] フィールドと同様に適切に機能します。[ 条件 ] フィールドに追加の条件が示されている場合は、そのフィールドを使用します。

    テーブル 列 列にインデックスが付けられていますか? 他の条件
    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 Consumer Account [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 日間保持する必要があります。

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

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

    上記を考慮して、次の秒単位のしきい値をお勧めします。
    • interaction、awa_work_item:7776000(90日-ただし、Weekly Trendsインジケーターを使用しない場合、またはルックバックをより短い時間に設定する場合は、これを短縮できます)。
    • 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 つのテストでは、カスケード削除を含めて約 400,000 件のインタラクションが 20 分で削除される可能性があります)。毎時 20 分ではアグレッシブすぎる場合は、プロパティ値を減らすことができます。