会話データの増加を制限

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月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] 承認またはキャンセルされ、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] フィールドはテーブルの日付列に対応し、[Age in seconds] フィールドは削除がトリガーされるタイミングを示します。レコードが [一致フィールド ] フィールドの日付が [経過時間 (秒)] フィールドよりも過去の日付になるポイントに達すると、クリーナーは実行時にレコードを削除します。

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

    テーブル 列 列にインデックスが付けられていますか? 他の条件
    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日-ただし、週次トレンド指標を使用しない場合、またはルックバックを短い時間に設定する場合は、これを短縮できます)。
    • 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_spend は、クリーナーが 1 回の実行中にレコードのバッチ削除を試みるのに費やす時間を制限します。値は秒単位で指定され、デフォルトは 1200 (20 分) です。これは、基本システムセットアップでは、テーブルクリーナーが最大 20 分間 1 時間ごとに実行されることを意味します (参考までに、1 つのテストでは、カスケード削除を含め、約 400,000 件のインタラクションが 20 分で削除される可能性があります)。1 時間あたり 20 分ではアグレッシブすぎる場合は、プロパティ値を減らすことができます。