Welches ist ein Szenario, in dem du einen großen Nutzen für CDC siehst?
what's a scenario in which you see lots of value for CDC ?
1. Imagine a very large online service, e.g., Snapchat, keeping user activities in something like MongoDB.  Update rates are very high, the table size is huge, the table footprint is global.
2. You need the data in OLTP because you're trying to use the user data to target ads for them, so storing in Delta is not an option. You need an online solution. This online store maintains aggregates (e.g., clicks over the last 5 min, interest vectors, etc.). Google would use Kansas for this, Facebook uses sharded MySQL + Tao.
3. You need to use this per-user data to analyze your online advertising strategy and re-train your ML models to increase yield.
4. You cannot hit the serving DB with analytical workloads, they're not optimized for that. Many no-SQL DB's don't even allow the kinds of queries you need to run.
5. The database is very large, so taking a snapshot is expensive and slow.
6. A lot of users are inactive at any specific time of the day, so snapshotting the entire state is also inefficient.
7. I want to also know changes in the original production DB. The production DB is an OLTP store and cannot keep that much state.
CDC --- can be an effective answer for this use case.
1. Stell dir einen sehr großen Online-Dienst vor, z. B. Snapchat, der die Nutzeraktivitäten in einer Datenbank wie MongoDB speichert.  Die Aktualisierungsraten sind sehr hoch, die Tabellengröße ist riesig und der Tabellenfußabdruck ist global.
2. Du brauchst die Daten im OLTP-Verfahren, weil du versuchst, die Nutzerdaten zu nutzen, um gezielt Werbung für sie zu schalten. Du brauchst eine Online-Lösung. Dieser Online-Speicher verwaltet Aggregate (z. B. Klicks der letzten 5 Minuten, Interessenvektoren usw.). Google würde dafür Kansas verwenden, Facebook verwendet Sharded MySQL + Tao.
3. Du musst diese Daten pro Nutzer nutzen, um deine Online-Werbestrategie zu analysieren und deine ML-Modelle neu zu trainieren, um den Ertrag zu steigern.
4. Du kannst die Serving-DB nicht mit analytischen Workloads belasten, dafür sind sie nicht optimiert. Viele No-SQL-DBs erlauben nicht einmal die Art von Abfragen, die du ausführen musst.
5. Die Datenbank ist sehr groß, so dass ein Snapshot teuer und langsam ist.
6. Viele Nutzer/innen sind zu einer bestimmten Tageszeit inaktiv, daher ist es ineffizient, einen Snapshot des gesamten Zustands zu erstellen.
7. Ich möchte auch die Änderungen in der ursprünglichen Produktions-DB kennen. Die Produktions-DB ist ein OLTP-Speicher und kann nicht so viel Status behalten.
CDC --- kann eine effektive Lösung für diesen Anwendungsfall sein.
general_qa
de