Derzeit entwickeln wir so etwas wie einen Artikelposting-Service als Portfolioerstellung. Als eine der Funktionen haben wir eine Funktion zum Anzeigen von Rankings wie Tag / Woche / Monat auf dem Bildschirm erstellt (im Folgenden als Ranking-Anzeigefunktion bezeichnet). Es gibt. In diesem Artikel wird der Inhalt des Tabellendesigns + α beschrieben, mit dem die Funktion zur Anzeige der Rangfolge erstellt wurde.
Ich habe diesen Artikel geschrieben, um den Denkprozess zu dokumentieren, und dachte, dass es in Zukunft für mich selbst sein könnte, wer in Zukunft die Möglichkeit haben wird, ähnliche Funktionen zu entwickeln, oder für diejenigen, die in Zukunft ähnliche Funktionen schaffen werden. ing.
Als Voraussetzung muss die Ranglistenanzeigefunktion die Rangfolge von 5 Elementen täglich / wöchentlich / monatlich / allgemein / Trend anzeigen. Jede Rangfolge wird wie folgt bestimmt.
Art | Evaluationskriterien |
---|---|
Tägliches Ranking | Gesamtzahl der Likes pro Tag |
Wöchentliches Ranking | 1 Woche(7 Tage)Insgesamt "Likes" |
Monatliches Ranking | 1 Monat(30 Tage)Insgesamt "Likes" |
Gesamtrangliste | Gesamtzahl der Likes für den gesamten Zeitraum |
Trendranking | Ergebnisse der Bewertung nach "Anzahl der Likes" pro Tag und "Anzahl der Zugriffe" pro Tag |
Da davon ausgegangen wird, dass nicht immer der neueste Status des Rankings angezeigt werden muss, ist es möglich, die Aggregation einmal in einem bestimmten Zeitraum durchzuführen.
In diesem Kapitel beschreiben wir den Denkprozess des Tabellendesigns für die Ranking-Anzeigefunktion. Im Folgenden werden die "Anzahl der Likes" und "Anzahl der Zugriffe" zusammen als "Zähldaten" bezeichnet.
Wenn Sie sich von Anfang an für Leistung interessieren, wird Ihr Denken kompliziert, denken Sie also nicht darüber nach. Wenn alles einfach ist, ist es besser als das, also habe ich mich zuerst gefragt, ob ich den Tisch einfach machen könnte.
Was ich darüber nachdachte, war, dass die folgenden Kandidaten aus der Funktionsübersicht in der Tabelle enthalten sind, aber ist es wirklich notwendig, dass für jede Zählung Daten für 1 Woche / 1 Monat / ganze Periode vorliegen? ・ Tägliche Zähldaten ・ Wöchentliche Zähldaten ・ Monatliche Zähldaten ・ Zählen Sie die Daten für den gesamten Zeitraum
Die minimale Dateneinheit, die erforderlich ist, um die Zähldaten für eine Woche / einen Monat / einen gesamten Zeitraum zu aggregieren, sind die täglichen Zähldaten. Daher ist es dem Programm möglich, die Zähldaten für jede Periode zu erhalten, solange die Zähldaten für jeden Tag aufgezeichnet werden. Basierend auf dieser Idee kann die Funktion selbst mit der folgenden Tabelle realisiert werden.
Abbildung 1. Artikeltabelle
Die Daten in der Tabelle in 1 sind in die folgenden zwei stark unabhängigen Anwendungsfälle unterteilt.
Datentypen | Datenverarbeitungsphase | Erneuerungsmöglichkeit |
---|---|---|
(Daten zählen) | Ranking anzeigen | Drücken Sie die Like-Taste/Beim Zugriff auf die Artikelseite |
Andere als die oben genannten | Zeigen Sie die Artikelseite an | Artikelerstellung/Beim Bearbeiten |
Im Fall der Tabelle in 1 können andere Daten als die Zähldaten während der Aktualisierung der Zähldaten nicht zusammen aktualisiert werden. Daher können durch Teilen der Tabelle in 1 wie folgt beide gleichzeitig aktualisiert werden.
Abbildung 2. Tabelle nach Aufteilung der Zähldaten
Danach fahren wir mit der Leistungsprüfung anhand der Tabelle in Abb. 2 fort. Die Tabelle in Abbildung 2 weist immer noch Leistungsprobleme auf (ganz zu schweigen). In Anbetracht der Tatsache, dass es zwei Hauptprobleme gibt, haben wir ein Design in Betracht gezogen, um jedes Problem zu lösen.
** (Problem 1) Ranking-Aggregation jedes Mal, wenn die Seite angezeigt wird = Die Berechnungszeit für die Ranking-Aggregation ist groß ** ** (Problem 2) Tägliche Zähldaten speichern = Leistungseinbußen aufgrund einer erhöhten Anzahl von Datensätzen **
Wenn Sie die Zähldaten für jeden Tag haben, können Sie die Zählung für eine Woche / einen Monat / einen ganzen Zeitraum berechnen. Wenn Sie sie jedoch umdrehen, werden die Zähldaten für jeden Zeitraum jedes Mal aggregiert, wenn der Benutzer auf die Seite zugreift, auf der das Ranking angezeigt wird. Muss.
Um dieses Problem zu lösen, ist es erforderlich, das aggregierte Ergebnis der Zähldaten für 1 Tag / 1 Woche / 1 Monat / alle Zeiträume in einer separaten Tabelle zu speichern und bei der Anzeige des Rankings auf diese Tabelle zu verweisen. Ich fand es gut (die Aggregation erfolgt in regelmäßigen Abständen durch regelmäßige Ausführungsverarbeitung).
Abbildung 3. Nach dem Hinzufügen der Kategoriedatenaggregationstabelle zur Tabelle in Abbildung 2.
Auf diese Weise ist es nicht erforderlich, jedes Mal zu aggregieren, und die Bewertungstabelle fügt tägliche Zähldaten hinzu / aktualisiert sie, und die Tabelle aggreagate_points bezieht sich auf die Zähldaten (bei der Anzeige des Rankings). Kann gemacht werden.
In der Tabelle von 1 nimmt die Anzahl der Datensätze exponentiell zu, da die Anzahl der veröffentlichten Artikel und die Anzahl der Arbeitstage zunimmt, da die Zähldaten für jeden Tag für jeden Artikel gespeichert sind. Infolgedessen wird die Kapazität der Datenbank verringert und die Datensuchgeschwindigkeit wird verringert. Daher haben wir zwei Maßnahmen in Betracht gezogen, um die Anzahl der Datensätze zu verringern.
** (Maßnahmen 1) Aufzeichnungen im Wert von bis zu 30 Tagen pro Artikel ** Die Zähldaten für den gesamten Zeitraum können durch weiteres Hinzufügen der täglichen Zähldaten auf dem neuesten Stand gehalten werden, sodass auch dann kein Problem besteht, wenn die Zähldaten für die letzten 30 Tage reduziert werden (die Zähldaten für den gesamten Zeitraum sind in Abb. 2 dargestellt). Halten Sie einen anderen Tisch).
** (Maßnahmen 2) Sammeln Sie die Daten der letzten 30 Tage in einem Datensatz ** Selbst wenn die in der Tabelle in 1 enthaltenen Daten in den letzten 30 Tagen reduziert wurden, kann nicht gesagt werden, dass die Anzahl der Datensätze abgenommen hat, da die Anzahl der Datensätze = die Gesamtzahl der veröffentlichten Artikel x 30 ist (wenn die Anzahl der veröffentlichten Artikel 10.000 beträgt, beträgt die Anzahl der Datensätze Wird 300.000 sein). Um die Gesamtzählungsdaten für einen Monat zu erhalten, müssen jedes Mal 30 Daten des Artikels mit der folgenden SQL extrahiert werden. Je mehr Daten vorhanden sind, desto länger dauert die Suche.
SELECT * FROM rating WHERE articl_id=[ID des Artikels];
In diesem Fall dachte ich, wenn die Daten für 30 Tage von Anfang an zu einem Datensatz verarbeitet würden, könnten die Probleme beim Extrahieren von 30 Daten gespeichert und die Anzahl der Datensätze = die Gesamtzahl der veröffentlichten Artikel unterdrückt werden.
Die Zähldaten des Tages werden häufig aktualisiert, aber die anderen vergangenen Zähldaten fügen nur die neuesten Daten hinzu / löschen die ältesten Daten. Wenn die letzten 30 Tage in einem Format zusammengestellt werden, mit dem diese Vorgänge auf der Programmseite problemlos ausgeführt werden können, ist dies auch dann kein Problem, wenn sie als ein Datensatz gespeichert werden.
Einige DBs können JSON- oder XML-Daten speichern (Postgresql, das dieses Mal verwendet wird, kann beide speichern). Da JSON oder XML auf der Programmseite einfacher zu handhaben sind, sind Daten im Wert von 30 Tagen JSON oder XML. Ich werde es in einem Datensatz im Format speichern. Es besteht die Sorge, dass die Leistung sinkt, wenn das Datenformat JSON oder XML ist, aber der Zeitpunkt für Änderungen an den Daten ist für die Gesamtleistung unerheblich, da sie in regelmäßigen Abständen durch regelmäßige Ausführungsverarbeitung ausgeführt werden.
Abbildung 4. Nach dem Anwenden der Maßnahmen zur Reduzierung der Datensatznummer auf die Tabelle in Abbildung 2
・ Beispiel für die Konvertierung der Zähldaten der letzten 30 Tage in das JSON-Format
{
rating_info: [
{
"favorite_count":"12"
"date":"2019-04-17"
},
{
"favorite_count":"15"
"date":"2019-04-16"
},
:(Abkürzung)
}
<rating_info>
<day_rating>
<favorite_count>12</favorite_count>
<date>2019-04-17</date>
</day_rating>
<day_rating>
<favorite_count>15</favorite_count>
<date>2019-04-16</date>
</day_rating>
</rating_info>
Die Kombination der in Abschnitt 3.2 berücksichtigten Ergebnisse ergibt die folgende Tabelle.
Abbildung 5. Final Table
Infolgedessen war es möglich, die Tabellen, auf die Benutzeroperationen zugreifen sollen, wie folgt zu trennen. Wenn Sie also einen Index für jede Tabelle mit der ID als Schlüssel erstellen, können Sie die Leistung auch dann beibehalten, wenn in der Tabelle viele Daten gespeichert sind. ..
Tabelle | Rolle | Tabellenreferenzmöglichkeit | Gelegenheit zur Tabellenaktualisierung | Referenzfrequenz | Aktualisierungsfrequenz |
---|---|---|---|---|---|
daily_rating | Tageszählung | Periodische Ausführungsverarbeitung | Bei der Anzeige der Artikelseite/Drücken Sie die Like-Taste | Einmal am Tag (*1) |
Hoch (*2) |
history_rating | Verlaufsspeicherung für die letzten 30 Tage | Periodische Ausführungsverarbeitung | Periodische Ausführungsverarbeitung | Einmal am Tag (*1) |
Einmal am Tag (*1) |
aggregate_points | wöchentlich/Monatlich/Umfassende Aufbewahrung von Zähldaten | Wenn die Ranglistenseite angezeigt wird | Periodische Ausführungsverarbeitung | Hoch | Einmal am Tag (*1) |
(* 1) Bei periodischer Ausführung einmal alle 24 Stunden (* 2) Das Hinzufügen / Löschen von Datensätzen hängt vom Hinzufügen / Löschen von Artikeln ab
Es tut mir leid, die Programmierelemente zu erwähnen. Dieses Mal werden wir Java + Spring Framework verwenden, aber da Spring Framework eine Funktion hat, die Aufgaben regelmäßig ausführen kann, werden wir diese verwenden.
@Scheduled(cron = "0 0 0 * * *", zone = "Asia/Tokyo")
public void updateAggregateData() {
//...
}
Von links nach rechts umfassen die Cron-Optionen Sekunden (0-59), Minuten (0-59), Stunden (0-23), Tage (1-31), Monate (1-12), Tage (0: Tage, 1: Mo, 2: Di, 3: Mi, 4: Do, 5: Fr, 6: Sa, 7: So). Wenn Sie also die oben genannte Quelle verwenden, kann sie jeden Tag regelmäßig um 0:00:00 Uhr ausgeführt werden. Wird sein.
Schreibe es richtig mit dem zerquetschten Text am Ende.
Während ich schrieb, dachte ich, dass die Zähldaten wie 1 Woche / 1 Monat zu Beginn nicht notwendig sind, da sie aus den Daten für jeden Tag erhalten werden. Ich dachte, ich hätte es entfernt, aber angesichts der Leistung dachte ich, dass es doch notwendig war, und ich drehte meine Hand und schuf ein Eintauchelement. Die Lehre ist, dass Zähldaten wie 1 Woche / 1 Monat vorerst in die Tabelle aufgenommen werden sollten, damit kein Verlust entsteht.
Der Inhalt, den ich dieses Mal schrieb, wurde auch für den persönlichen Zweck geschrieben, den Inhalt, den der überwiegend sinnliche Mitwirkende in seinem Kopf mit Sensation und Bild dachte, richtig zu dokumentieren. Ich überprüfte, ob ich einen schrecklichen Fehler gemacht hatte, aber ich brauchte weniger als 24 Stunden, um dies zu schreiben, und bestätigte erneut, dass ich nicht gut darin war, Dokumente zu schreiben (3 Jahre lang jede Woche, als ich Student war). Früher habe ich 6-8 Seiten dieses Materials in Artikelgröße in Word erstellt, aber ich habe erneut bestätigt, dass es seit der Blütezeit zu lange her ist und ich nicht das Gefühl dieser Zeit habe. Ausgabe ist ein Problem.
Es ist keine Übertreibung zu sagen, dass Sie ein Anfänger im Bereich Tischdesign und DB sind. Ich denke, Sie können viele Dinge lernen, indem Sie die Literatur lesen, wie z. B. gründliche Anleitungen zum DB-Design und SQL-Anti-Patterns. Erwerben Sie also praktische Fähigkeiten durch die Entwicklung des Artikelveröffentlichungsdienstes, der als Material für diesen Artikel verwendet wurde, und die Entwicklung des Dienstes mit einer großen Anzahl von Tabellen / Spalten, die als nächstes geplant sind, und geben Sie manchmal auch hier Lernergebnisse aus. Ich denke.
das ist alles
(2) So führen Sie Aufgaben regelmäßig mit Spring Boot aus
(3) WWW SQL Designer * Zum Erstellen von ER-Diagrammen
Recommended Posts