Begrenzung des Wachstums von Konversationsdaten

Mit der Ausführung von Vorgängen nehmen konversationsbezogene Tabellen zu, was sich auf die Systemleistung auswirken kann. Um die Leistung zu verbessern und gleichzeitig genügend Datensätze zu speichern, richten Sie einen Prozess ein, um frühere Daten zu archivieren und die Tabellen zu bereinigen, die für laufende Konversationen verwendet werden.

Empfohlene Aktivierungen

Um das Datenwachstum zu begrenzen, das mit der häufigen Verwendung von Virtual Agent und Mitarbeiterchateinhergeht, aktivieren Sie die Bereinigungsaufgaben in der folgenden Tabelle:

Tabellenname	Zusammenfassung des Bereinigungsauftrags	Empfehlung
AWA Service Desk-Mitarbeiter-Kanalverfügbarkeit [awa_agent_channel_availability]	Entfernt AWA Verfügbarkeitsprotokolle für Service Desk-Mitarbeiter-Kanäle, die älter als 90 Tage sind.	Aktivierung empfohlen.
AWA Anwesenheit des Service Desk-Mitarbeiters [awa_agent_presence]	Entfernt AWA Protokolle für die Anwesenheit von Service Desk-Mitarbeitern, die älter als 90 Tage sind.	Aktivierung empfohlen.
AWA Verlauf der Anwesenheit des Service Desk-Mitarbeiters [awa_agent_presence_history]	Entfernt AWA  – Anwesenheitsverlaufsprotokolle von Service Desk-Mitarbeitern, die älter als 180 Tage sind.	Keine Aktion erforderlich, bereits aktiviert.
AWA Dokumentgröße [awa_document_size]	Entfernt Protokolle zur Dokumentgröße AWA, die älter als 90 Tage sind.	Aktivierung empfohlen.
AWA Instanzstatistiken [awa_instance_stats]	Entfernt AWA Instanzstatistikprotokolle, die älter als 60 Tage sind.	Keine Aktion erforderlich, bereits aktiviert.
AWA -Warteschlangenstatistiken [awa_queue_stats]	Entfernt AWA Warteschlangenstatistikprotokolle, die älter als 60 Tage sind.	Keine Aktion erforderlich, bereits aktiviert.
AWA -Servicekanalstatistiken [awa_service_channel_stats]	Entfernt Protokolle mit Servicekanalstatistiken für AWA, die älter als 60 Tage sind.	Keine Aktion erforderlich, bereits aktiviert.
AWA Arbeitselement [awa_work_item]	Entfernt AWA Arbeitselementprotokolle, die akzeptiert oder storniert wurden und älter als 90 Tage sind.	Aktivierung empfohlen.
Interaktion [interaction]	Entfernt Interaktionsprotokolle, die älter als 90 Tage sind.	Aktivierung empfohlen.
Interaktions-JSON-Blob [interaction_json_blob]	Entfernt JSON-Blob-Protokolle für Interaktionen, die älter als 60 Tage sind.	Aktivierung empfohlen.
Live-Gruppenprofil [live_group_profile]	Entfernt Live-Gruppenprofilprotokolle, die älter als 60 Tage sind.	Aktivierung empfohlen.
Verbraucher [sys_cs_consumer]	Entfernt Verbraucherprotokolle, die eine Anwender-ID [user_id]=5136503cc611227c0183e96598c4f706 haben und älter als 60 Tage sind.	Bereits auf aktiv festgelegt oder Name [name] = Gastanwender zur Bedingung hinzufügen.
Verbrauchergerätekontext [sys_cs_consumer_device_context]	Fügt der Spalte „Verbraucherkonto“ [consumer_account] die Referenzkaskadierungsregel [reference_cascade_rule]=delete rule hinzu.	Keine Aktion erforderlich
Konversation [sys_cs_conversation]	Entfernt Konversationsprotokolle, die älter als 60 Tage sind.	Keine Aktion erforderlich, bereits aktiviert.

Welche Tabellen bereinigt werden sollen

Diese Tabellen müssen bereinigt werden, da sie in Instanzen mit langer Laufzeit auf Millionen von Datensätzen anwächst:

• Service Desk-Mitarbeiter – Anwesenheitsverlauf [awa_agent_presence_history]
• AWA Dokumentgröße [awa_document_size]
• AWA Arbeitselement [awa_work_item]
• Verbraucher [sys_cs_consumer]
• Verbrauchergerätekontext [sys_cs_consumer_device_context]
• Konversation [sys_cs_conversation]
• Interaktion [interaction]
• Interaktions-JSON-Blob [interaction_json_blob]
• Live-Gruppenprofil [live_group_profile]

Es gibt andere zugehörige Tabellen, z. B. die Tabellen „Konversationsnachricht“ [sys_cs_message] und „Live-Feed-Nachricht“ [live_message], die ebenfalls groß werden können. Diese Tabellen weisen Attribute reference_cascade_rule_delete auf, die als Nebeneffekt der Bereinigung der Tabellen in der vorherigen Liste zu einer Bereinigung führen.

Welche Datensätze in den Tabellen gelöscht werden sollen

Über die Konfiguration für das automatische Leeren können Sie die Felder Übereinstimmungsfeld und Alter in Sekunden auswählen. Das Feld Übereinstimmungsfeld entspricht einer Datumsspalte in der Tabelle, und das Feld Alter in Sekunden gibt an, wann die Löschungen ausgelöst werden. Wenn ein Datensatz einen Punkt erreicht, an dem das Feld Übereinstimmungsfeld ein Datum aufweist, das weiter in der Vergangenheit liegt als das Feld Alter in Sekunden, löscht die Bereinigung den Datensatz, wenn sie ausgeführt wird.

Idealerweise sollte das Feld Übereinstimmungsfeld angeben, wie lange der Datensatz aktiv ist. Die Spalten in der folgenden Tabelle eignen sich gut als Übereinstimmungsfeld für die betreffenden Tabellen, mit der zusätzlichen Bedingung im Feld Bedingungen, wo angegeben.

Tabelle	Spalte	Ist die Spalte indiziert?	Zusätzliche Bedingung
AWA Service Desk-Mitarbeiter-Kanalverfügbarkeit [awa_agent_channel_availability]	Aktualisiert (sys_updated_on)	Nein	agent.active = falsch
AWA Anwesenheit des Service Desk-Mitarbeiters [awa_agent_presence]	Aktualisiert (sys_updated_on)	Nein
AWA Verlauf der Anwesenheit des Service Desk-Mitarbeiters [awa_agent_presence_history]	Aktualisiert (sys_updated_on)	Ja
AWA Dokumentgröße [awa_document_size]	Aktualisiert (sys_updated_on)	Nein
AWA Arbeitselement [awa_work_item]	Aktualisiert (sys_updated_on)	Ja	stateINaccepted,canceled
Interaktion [interaction]	Aktualisiert (sys_updated_on)	Ja
Interaktions-JSON-Blob [interaction_json_blob]	Aktualisiert (sys_updated_on)	Nein
Live-Gruppenprofil [live_group_profile]	Aktualisiert (sys_updated_on)	Nein
Verbraucher [sys_cs_consumer]	Aktualisiert (sys_updated_on)	Nein	name=Gastanwender
Konversation [sys_cs_conversation]	Aktualisiert (sys_updated_on)	Nein

„interaction.closed_at“ und „sys_cs_conversation.conversation_completed“ sind keine guten Optionen für das Feld „Matchfield“, da sie keine Werte für fehlerhafte Konversationen und einige geschlossene Interaktionen enthalten. Die Lücken können mit Business-Regeln geschlossen werden, die dieses Datum festlegen, wenn es bei einer entsprechenden Statusänderung leer ist. Verwenden Sie jedoch der Vereinfachung halber das Feld sys_updated_on für diese Tabellen.

Andere Tabellen können durch Bedingungen im Statusfeld eingeschränkt werden, die sicherstellen, dass nur geschlossene Chats gelöscht werden. Da Interaktionen im Allgemeinen nie länger als ein paar Tage offen bleiben sollten, können diese Bedingungen weggelassen werden, damit die Abfragen nach der letzten Aktualisierung einfacher und schneller ausgeführt werden. Der Status in der Tabelle „awa_work_item“ ist möglicherweise wichtiger, da auch länger laufende Aufgaben wie Fälle dargestellt werden.

Das Problem mit der Tabelle „sys_cs_consumer“ besteht darin, dass Sie diese Datensätze normalerweise beibehalten möchten, um neue Konversationen mit vorhandenen Benutzern abzugleichen. Bei Gastbenutzern wird jedoch für jede Konversation ein anderer Datensatz erstellt.

Für die Tabelle „sys_cs_consumer_device_context“ ist ein Verweis auf die Tabelle „CS-Verbraucherkonto“ [sys_cs_consumer_account] vorhanden (die selbst einen Verweis auf die Tabelle „sys_cs_consumer“ enthält), aber der Verweis ist nicht mit reference_cascade_rule=delete gekennzeichnet. Es wird empfohlen, diese Regel der Verbraucherkontoreferenz hinzuzufügen. Auf diese Weise löscht die Bereinigung, wenn sie die Datensätze in den Tabellen „sys_cs_consumer“ und „sys_cs_consumer_account“ löscht, auch diese.

Die Tabellen „awa_agent_presence“ und „awa_agent_channel_availability“ wachsen nicht pro Chat auf die gleiche Weise wie andere Tabellen, werden jedoch regelmäßig von der Zuweisungs-Engine aufgerufen und können veraltete Einträge von Anwendern enthalten, die nicht mehr aktiv sind. Lange, nicht verwendete Einträge sollten auch hier bereinigt werden. Bei der Spalte „awa_agent_channel_availability“ ist besondere Sorgfalt erforderlich, da sie möglicherweise nicht häufig aktualisiert wird. Aus diesem Grund sollte dieser Bereinigung eine zusätzliche Bedingung hinzugefügt werden, damit nur Datensätze von inaktiven Anwendern entfernt werden können.

Wann können die Datensätze sicher gelöscht werden?

Es gibt verschiedene Aspekte bei der Bestimmung, wann die Datensätze sicher gelöscht werden können:

• Löschen Sie keine Datensätze für laufende Konversationen.

  Für sitzungsbasierte Chatunterhaltungen beträgt die Altersgrenze einige Tage. Wenn SMS-/Messaging-Konversationen einbezogen werden, kann die Altersgrenze einige Wochen oder länger betragen. Eine Möglichkeit, dies auszuwerten, besteht darin, alle Eigenschaften des Formulars „com.glide.cs.*_idle_timeout“ zu durchsuchen und die mit dem höchsten Wert zu finden.

• Löschen Sie keine Datensätze, die zu Dashboards/Berichten zu aktuellen Aktivitäten beitragen.

  Das Dashboard AWA für das Dashboard „Interaktionen – erweiterte Analytics“ enthält einen Indikator für wöchentliche Trends, der drei Monate zurückblickt. Um dies vollständig zu unterstützen, müssen Sie die Datensätze „interaction“ und „awa_work_item“ mindestens 90 Tage lang aufbewahren.

• Löschen Sie keine Datensätze, deren Daten zur späteren Verwendung archiviert werden müssen.

  Das Timing hierfür hängt vom Timing der anwenderdefinierten Logik ab, die für die erforderliche Archivierung hinzugefügt wird. Sie sollten in der Lage sein, dies so einzurichten, dass es früh genug ausgeführt wird, um nicht der entscheidende Faktor zu sein.

In Anbetracht des Vorstehenden werden die folgenden Schwellenwerte für das Alter in Sekunden empfohlen:

• interaction, awa_work_item: 7776000 (90 Tage - Dies kann jedoch reduziert werden, wenn Sie den Indikator „Wöchentliche Trends“ nicht verwenden oder wenn Sie bereit sind, den Rückblick dafür auf eine kürzere Zeitspanne festzulegen.)
• sys_cs_conversation, live_group_profile, interaction_json_blob, sys_cs_consumer: 2592000 (30 Tage) oder 5184000 (60 Tage).

Leistungsüberlegungen

Werden sys_updated_on-Indizes für die Tabellen benötigt, die fehlen?

Die Tests wurden in einer Instanz mit über 12.000.000 Interaktionen ausgeführt, wobei eine Tabellenbereinigung für eine Tabelle mit einem Index im Feld „sys_updated_on“ (Interaktion) und eine Tabelle ohne Index (interaction_json_blob) konfiguriert wurde. In beiden Fällen überstieg die für das Löschen aufgewendete Zeit (potenziell viele Minuten) die für das Abfragen der Datensätze aufgewendete Zeit (max. 2 Sekunden) bei der ersten und nachfolgenden Ausführung bei weitem. Angesichts dieses Ergebnisses müssen den Tabellen keine zusätzlichen Indizes hinzugefügt werden, da die Auswirkungen auf die Leistung minimal sind.

Wann sollte die erste und wiederholte Tabellenbereinigungsaufgabe ausgeführt werden?

Normalerweise wird „sys_trigger“ für die Tabellenbereinigung einmal pro Stunde ausgeführt. Wenn ein oder mehrere Bereinigungen für Tabellen mit vielen veralteten Datensätzen festgelegt werden, kann die Anzahl der bei dieser ersten Ausführung durchgeführten Löschungen sehr hoch sein und das System zusätzlich belasten. Bevor Sie die Konfiguration für die Tabellenbereinigung anpassen und aktivieren, ändern Sie diesen Zeitplan für die Tabellenbereinigung vorübergehend, sodass die nächste Ausführung außerhalb der Geschäftszeiten stattfindet (eine Zeit, in der das System normalerweise leichter ausgelastet ist).

Wenn es keine Ruhezeiten gibt, können einige Eigenschaften für die Tabellenbereinigungen hilfreich sein. Insbesondere glide.db.tablecleaner.chunk_delete_max_time_sput begrenzt, wie lange die Bereinigung versucht, Datensätze während einer einzelnen Ausführung im Batch-Verfahren zu löschen. Der Wert wird in Sekunden angegeben und ist standardmäßig auf 1200 festgelegt (20 Minuten). Dies bedeutet, dass im Setup des Basissystems die Tabellenbereinigung maximal 20 Minuten lang stündlich ausgeführt wird (zur Referenz: Während eines Tests konnten in 20 Minuten etwa 400.000 Interaktionen gelöscht werden, einschließlich kaskadierender Löschungen). Wenn 20 Minuten pro Stunde zu aggressiv sind, kann der Eigenschaftswert reduziert werden.