MySQL Tabelle splitten aber wie eine abfragen?

[Thallius]

Hi,

ich brauche sowas ähnliches wie einen Join aber es ist kein Join. Ich habe keine Ahnung ob es das überhaupt gibt aber wenn wüßte ich nicht nach welchem Stichwort ich suchen sollte deshalb hier meine Frage:

Ich habe eine Tabelle, welche von meheren Applikationen genutzt wird. Diese Tabelle enthält datumbezogene Daten und jeden Tag kommen ein paar hundert neue dazu.
Da dieses Applikationen nun schon ein paar Jahre alt sind sind die Tabellen mitlerweile recht groß und damit auch langsam geworden.

Da für die eigentliche Main Applikation aber eigentlich nur die Einträge von Heute in die Zukunft interessant sind und die alten Einträge nur für speizielle Statistik-Applikationen gebraucht werden, wäre es jetzt natürlich super wenn ich die Tabelle einfach in zwei Tabellen aufteilen könnte. Also quasi eine mit den einträgen von vor 2017 und eine mit denen danach.

Allerdings möchte ich jetzt nicht bei den Abfragen in der Statistik-Applikation jedesmal aus zwei Tabellen lesen sondern einfach nur einen Query machen. Ein FULL Join würde hier zwar funktionieren aber dann hätte ich ja die doppelte Spaltenanzahl und müßte nachsehen welche Spalten befüllt waren und welche NULL sind. Keine richtig schöne Lösung.

Gibt es da etwas einfaches?

Gruß

Claus

 

[Tobse]

Kannst du die Namen der Tabellen ändern, die die anderen Applikationen benutzen?

Meines Wissens nach geht das, was du da vorhast, nicht. Fürs lesen kannst du eine View benutzen, welche die alte und die neue Tabelle mit UNION zusammenpabbt. Wenn du das machst können die Legacy-Applikationen aber keine Daten mehr schreiben weil diese View nicht schreibbar ist.

Ich denke ein bisschen drüber nach... aber aktuell komme ich immer zum selben Ergebnis: mehrere Applikationen die selbe DB nutzen zu lassen war der urpsprüngliche, schwerwiegende Fehler. Wenn du eine Schnittstelle vorne dran hättest wäre das kein großes Problem...

Dabei fällt mir ein: mit vieeeeel getrickse bekommst du das schon hin. Mehrere Schemata im DB-Server und Trigger auf INSERT- und UPDATE. Noch führe ich das aber mal nicht näher aus, denn das ist möglicherweise eine noch schlechtere Idee als mehrere Applikationen die gleiche DB nutzen zu lassen...

 

[Dukel]

Du willst die Datenbank nicht manuell aufteilen sondern SQL Features nutzen. Das ist in deinem Fall das Partitionieren.
https://dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html

 

[Thallius]

Kannst du die Namen der Tabellen ändern, die die anderen Applikationen benutzen?

Ich denke ein bisschen drüber nach... aber aktuell komme ich immer zum selben Ergebnis: mehrere Applikationen die selbe DB nutzen zu lassen war der urpsprüngliche, schwerwiegende Fehler. Wenn du eine Schnittstelle vorne dran hättest wäre das kein großes Problem...

Natürlich greifen die Apps nicht direkt auf die DB zu sondern ich habe einen PHP REST Webservice dazwischen. Das ändert aber nichts an der Sachlage. Und wie stellst du dir vor hätte ich die Datenbank trennen sollen für die verschiedenen Applikationen? Dann müßte ja die eine Applikation immer zwei Datenbanken beschreiben wenn sich was ändert damit beide Applikationen immer die aktuellen Daten haben. Das wäre sicher noch viel weniger performant. Also das halte ich definitiv nicht für einen Fehler. Ich lege ja auch nicht zwei Kundendatenbanken in einer Firma an weil ich zwei Applikationen habe die diese Benutzen oder?

Gruß

Claus

 

[Thallius]

Du willst die Datenbank nicht manuell aufteilen sondern SQL Features nutzen. Das ist in deinem Fall das Partitionieren.
https://dev.mysql.com/doc/refman/5.7/en/partitioning-overview.html

Nein das ist nicht das was ich suche. Es geht ja nicht darum die Daten physikalisch getrennt zu speichern. Das würde ja die Geschwindigkeit nicht erhöhen sondern im Gegenteil eher verringern.

Gruß

Claus

 

[Tobse]

Ja wenn du einen Service dazwischen hast, hast du ja alles richtig gemacht Ich dachte jetzt, dass die verschiedenen Applikationen sich direkt mit der DB verbinden und queries abfeuern :O

Das wäre mein Lösungsansatz in der REST Schnittstelle:

Mach dir zwei Tabellen: einmal für alles bis heute, eine für alles weitere. Inserts gehen immer in die neue. Für die lesenden Zugriffe benutzt du eine View, welche beide verbindet:

CREATE VIEW historical_data_readonly AS
SELECT * FROM historical_data_archive
UNION
SELECT * FROM historical_data

Das wirst du einem O/RM aber nicht so einfach beibringen können, weshalb du da auf CQRS wechseln musst.

 

[Thallius]

Das klingt doch ganz vielversprechend. O/RM habe ich in dem Fall sowieso nicht von daher kein Problem.

Danke

Claud

 

[Dukel]

Nein das ist nicht das was ich suche. Es geht ja nicht darum die Daten physikalisch getrennt zu speichern. Das würde ja die Geschwindigkeit nicht erhöhen sondern im Gegenteil eher verringern.

Gruß

Claus

Natürlich erhöht es die Geschwindigkeit, wenn Daten parallel gelesen werden können oder nur die Daten gelesen werden, die einen interresieren.
Das was du als erstes wolltest (Partition je Daten pro Jahr) ist das selbe wie eine Partitionierung, nur das du das manuell machen wolltest.
https://www.chrismoos.com/2010/01/31/mysql-partitioning-tables-with-millions-of-rows
http://mysql.rjweb.org/doc.php/ricksrots

PARTITIONing splits up one table into several smaller tables. But table size is rarely a performance issue. Instead, I/O time and indexes are the issues.

Perhaps the most common use case where PARTITIONing shines is the the dataset where "old" data is deleted from the table. RANGE PARTITIONing by day (or other unit of time) lets you do a nearly instantaneous DROP PARTITION plus REORGANIZE PARTITION instead of a much slower DELETE.

 

[looparda]

Ich würde auch auf jeden Fall Views verwenden. Du kannst die View-Erzeugung mit einem Trigger verbinden. Entweder erstellst du den View bspw. täglich:

CREATE EVENT event1
  ON SCHEDULE EVERY '1' DAY
  STARTS '2017-01-01 00:00:00'
DO
DROP VIEW today;
CREATE VIEW today AS...

Oder du koppelst die Erzeugung an die CREATE/UPDATE Events. Ob das sinnvoll ist hängt wohl von der Anwendung ab.
Von partitioning habe ich in mysql noch nie etwas gehört. Aber das sieht auch spannend aus!

 

[Tobse]

@looparda Wieso muss man das denn? Die View bleibt doch von sich aus aktuell... oder nicht?

 

[looparda]

@Tobse Du hast Recht, der View aktualisiert sich mit. Hatte irgendwie einen Snapshot beim Wort View vor Augen.