Google CloudSQL: Strukturieren von Verlaufsdaten auf cloudSQL

Question

Ich verwende Google CloudSQL für die Anwendung der erweiterten Suche nach Personendaten, um die Liste der Benutzer abzurufen. Im Datenspeicher sind dort bereits Daten mit 2 Modellen gespeichert. First wird verwendet, um aktuelle Daten von Benutzern zu verfolgen, und ein anderes Modell wird verwendet, um historische Zeitachsen zu verfolgen. Die aktuellen Daten werden auf Google CloudSQL gespeichert sind mehr als Millionen Zeilen für alle Benutzer. Jetzt möchte ich die erweiterte Suche nach historischen Daten, einschließlich zwischen Daten, implementieren, indem ich alle Verlaufsdaten zur Cloud hinzufüge.

Wenn jemand die bessere Struktur für dieses historische Modell vorschlagen kann, wie ich durch viele der Links und Artikel gegangen bin. Aber ich kann keine richtige Lösung finden, da ich mich um die Leistung für die Suche kümmern muss (In der aktuellen Suche dauert das Abrufen des Ergebnisses normal, aber wenn der Verlauf abgerufen wird, durchsucht es alle Datensätze, was eine Verlangsamung der Abfragen verursacht komplexe JOINs nach Bedarf). Die Abfrage, die zum Abrufen der Daten aus CloudSQL verwendet wird, wird dynamisch basierend auf den Anforderungen der Benutzer erstellt. Beispiel: Ein Benutzer möchte die Liste der Mitarbeiter, deren Manager"xyz.123@abc.in" ist, mithilfe von Python-Code wird die Abfrage entsprechend aufgebaut. Jetzt möchte ein Benutzer Benutzer finden, deren Manager WAS "xyz.123@abc.in" mit wirksamem Vom 2016-05-02 bis 2017-01-01.

Wie ich habe wie unten einige der usecases für Struktur finden:

1) Das gleiche Modell wie aktuelle Struktur mit neuen Spalte Flag für isCurrentData (Stand der Daten, ob es Geschichte oder aktiv)

disadv .: - Abfragen Verlangsamung während Abrufen von Daten, wie es alle Datensätze scannen. Die Duplizierung von Daten kann zunehmen.

Diese alle disadv. wird die Leistung der erweiterten Suche beeinflussen, indem die Zeit erhöht wird. Lösung für dieses Problem ist die gesamte Tabelle in diff-Tabellen zu partitionieren.

2) Partition basierend auf Jahr. Mit der Zeit werden dadurch zu viele Tabellen generiert.

3) 2 Tabellen können gepflegt werden. 1. für aktuelle Daten und zweitens für die Geschichte. Wenn der Benutzer jedoch Daten in beiden Modellen suchen möchte, wird die Komplexität der Build-Abfrage erzeugt.

Also brauchen Sie Vorschläge für die Strukturierung historischer Zeitleiste mit verbesserter Leistung und effektiver Datenverarbeitung.

Vielen Dank im Voraus.

Answer 1

Je nachdem, wie oft Sie Live-Abfragen im Vergleich zu historischen Abfragen und der Größe Ihres Datensatzes durchführen möchten, sollten Sie in Erwägung ziehen, die historischen Daten an anderer Stelle zu platzieren. Wenn Sie z. B. schnelle Abfragen für Live-Daten benötigen und viele davon ausführen möchten, aber Abfragen mit höherer Latenz verarbeiten und diese nur gelegentlich ausführen können, sollten Sie in Betracht ziehen, regelmäßig Daten nach Google BigQuery zu exportieren. BigQuery kann für die Suche in einem großen Korpus von Daten nützlich sein, hat aber eine viel höhere Latenzzeit und kein drahtloses Protokoll, das MySQL-kompatibel ist (obwohl die Abfragesprache denen bekannt vorkommt, die SQL kennen). Während Sie bei Cloud SQL für die Datenspeicherung und die Zeit, die Ihre Datenbank benötigt, zahlen, bezahlen Sie bei BigQuery hauptsächlich für die Datenspeicherung und die Menge der Daten, die während der Ausführung Ihrer Abfragen gescannt werden.Daher, wenn Sie viele dieser historischen Abfragen ausführen möchten, kann es ein wenig teuer werden.

Wenn Sie nicht über einen sehr großen Datensatz verfügen, ist BigQuery möglicherweise ein wenig übertrieben. Wie groß ist Ihr "Live" -Datensatz und wie groß erwarten Sie, dass Ihr "historischer" Datensatz im Laufe der Zeit wächst? Ist es möglich, die Größe der Cloud SQL-Instanz zu erhöhen, wenn die Verlaufsdaten anwachsen, bis zu dem Punkt, an dem es sinnvoll ist, mit dem Export in Big Query zu beginnen?

Answer 2

@Kevin Malachowski: Danke, dass du mich mit deinen Infos und Fragen geführt hast. Das hat mir neue Denkweisen gegeben.

Historische Datensätze werden mehr als 0,3-0,5 Millionen (Maximum) betragen. Jetzt verwende ich BigQuery für die historische Suche im Voraus.

Für Live-Daten-wird CloudSQL verwendet werden, da wir uns auf die Leistung für abgerufene Daten konzentrieren müssen.

Einige Performance-Probleme sind für die historische Suche vorhanden, wenn ein Benutzer sowohl Ergebnisse aus Live- als auch aus historischen Daten abrufen möchte. (BigQuery benötigt für den schlimmsten Fall Zeit von ca. 5-6 Sekunden [oder mehr]). Es wird jedoch nach Daten und Struktur des Modells optimiert.