Cassandra und aggregierte Daten

Question

Wir haben eine „Legacy“ SQL Server-basierte Anwendung, die OLTP-Daten (Umsatz) hält:

• OLTP-Datenstruktur ist sehr komplex
• Noch wir es als eine Quelle halten müssen Berichte
• Berichte über OLTP-Strukturen sind sehr langsam
• So bereiten wir und tatsächliche „OLAP“ -Ansichten halten, sagen wir, der Umsatz pro Tag, ist jede Ansicht eine Tabelle tatsächlich in MS SQL-Datenbank

Hauptproblem: Wenn wir eine neue Ansicht benötigen, dauert es sehr lange, alle vorhandenen OLTP-Daten zu scannen.

Jetzt wollen wir Cassandra migrieren, sollten wir denselben Ansatz verwenden gleichen Ziele achive oder:

• Mai werden wir eine bessere Nutzung Tools wie Zünd-/Kylin, können sie wie diese Dinge tun?
• Kann Ansatz irgendwie verändert werden?

Answer 1

Es könnte nicht die Antwort sein, nach der Sie suchen möchten. Ich möchte jedoch nur unsere Erfahrungen mit Cassandra und aggregierten Daten teilen. In unserem Projekt müssen wir Daten von Servern auf der ganzen Welt sammeln und die Aggregation entsprechend durchführen. Einige der Metriken sind Nachrichten pro Stunde pro Server, pro geografische Region usw. Sobald also neue Daten eintreffen, startet der Batch-Prozess automatisch, um eine Aggregation durchzuführen oder Daten in mehrere Tabellen/Ansichten einzufügen. Wir verwenden apache-spark als Verarbeitungsmodul, zusätzlich verwenden wir auch einige Konzepte in Cassandra wie materialized view, secondary index, custom trigger basierend auf bestimmten Anwendungsfall. Ein wichtiger Punkt beim Entwerfen des Datenmodells ist, NF zu vergessen, im Grunde brauchen wir das im Allgemeinen nicht in NoSQL.

Kurz gesagt kann ich sagen, dass die Migration von der traditionellen Datenbank zur NoSQL-Datenbank zunächst mühsam sein könnte. Aber das Ergebnis am Ende ist ziemlich befriedigend in Bezug auf Leistung und Verfügbarkeit.