Tweet
Guten Abend allerseits.
Ich habe folgendes Problem: Eine MySQL-Artikeldatenbank mit zur Zeit ca. 30 Mio Datensätzen soll a) möglichst ständig verfügbar sein und b) laufend aktualisiert werden können.
Um die Verfügbarkeit zu optimieren, habe ich im Wesentlichen zwei Volltextindizes für unterschiedliche Suchanfragen (schnell: Bezeichnung und Warengruppe, ausführlich: Bezeichnung, Warengruppe, Beschreibung, Zusatzhinweise - wobei drei VARCHAR und eines TEXT-Felder sind) sowie diverse numerische Indizes (Nummer, Zuordnungen, Werte, etc). Die Zeit zur Ermittlung der Suchergebnisse ist mit unter 1 sek. im Mittelwert auch zufriedenstellen.
CREATE TABLE `artikel` (
`pid` int(11) NOT NULL auto_increment,
`source` int(11) NOT NULL default '0',
`name1` varchar(150) NOT NULL default '',
`name2` varchar(250) NOT NULL default '',
`name3` varchar(100) NOT NULL default '',
`description` tinytext NOT NULL,
[....]
PRIMARY KEY (`pid`),
KEY `source` (`source`),
FULLTEXT KEY `simple` (`name1`,`name3`),
FULLTEXT KEY `extended` (`name1`,`name2`,`name3`,`description`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=30000000
Die Abfrage (mit Volltext) erfolgt etwa wie folgt:
SELECT SQL_CALC_FOUND_ROWS a.*, b.*
FROM artikel a, quellen b
WHERE a.source=b.sid and
MATCH (a.name1, a.name2, a.name3, a.description)
AGAINST ('suchbegriff' IN BOOLEAN MODE)";
AND [...] ORDER BY [...] LIMIT [...]
Für die Aktualisierung nehme ich eine leere Tabelle mit der gleichen Struktur, aber OHNE jegliche Volltextindizes.
In diese werden dann nacheinander alle Quelldaten eingelesen, die im Laufe des Tages reinkommen (das Einlesen findet nachts statt, um die Gesamtlast auf die Datenbank niedrig zu halten. da die Abfragen hauptsächlich während der üblichen Arbeitszeiten [von Normalmenschen, nicht meinen] stattfinden).
Sind alle Quelldaten neu eingelesen (4-5 Nächte), wird die neu befüllte Tabelle mit den Volltextindizes aufgerüstet (5 Stunden) und anschließend gegen die "alte" Tabelle ausgetauscht, welche nach erfolgreichem "Umschalten" dann gelöscht wird. Das Ganze läuft natürlich automatisiert über Cron-Jobs.
Nun möchte (muss) ich aber einen schnelleren Aktualisierungsrhythmus erreichen, im Idealfall möchte ich on-the-fly oder mit wenigstens täglicher Änderung Daten austauschen/updaten/löschen können. Bei den Tabellengrößen, mit denen ich im Normalfall zu tun habe (<500.000 Datensätze) kein Problem, aber hier:
Es gibt keine eindeutige Nummer für die verschiedenen Artikel; die kommen von verschiedenen Zulieferern und haben ihre eigene Nummernsystematik, daher kann ich nicht gezielt Datensätze prüfen und austauschen (was sonst wohl einfacher wäre, da sich an der volltextrelevanten Beschreibung nicht immer was ändert).
Aktualisiere ich die Artikelliste live - auch nur um einen einzigen Datensatz -, stört der Volltextindex, der ja jedes Mal neu aufgebaut werden muss; ohne den dauern aber die Suchvorgänge unzumutbar lange.
Eine Master/Slave-Lösung kommt z.Zt. nicht in Frage, da mir nur ein Server zur Verfügung steht.
Ein Verzicht auf die große Tabelle durch das Zusammenschalten von 3000 schnell auszuwechselnden kleinen Quell-Tabellen über die MERGE-Engine geht ebenfalls nicht, da ich dann keinen Volltext-Index über den gesamten Datenbestand mehr habe.
So, und nun weiß ich nicht mehr so richtig weiter. Was ich brauche, ist ein Denkanstoß; ich habe mich hier in eine Richtung verrannt und sehe wahrscheinlich den Wald vor Bäumen nicht mehr. Danke für Eure Geduld, dies gelesen zu haben.
Ich habe folgendes Problem: Eine MySQL-Artikeldatenbank mit zur Zeit ca. 30 Mio Datensätzen soll a) möglichst ständig verfügbar sein und b) laufend aktualisiert werden können.
Um die Verfügbarkeit zu optimieren, habe ich im Wesentlichen zwei Volltextindizes für unterschiedliche Suchanfragen (schnell: Bezeichnung und Warengruppe, ausführlich: Bezeichnung, Warengruppe, Beschreibung, Zusatzhinweise - wobei drei VARCHAR und eines TEXT-Felder sind) sowie diverse numerische Indizes (Nummer, Zuordnungen, Werte, etc). Die Zeit zur Ermittlung der Suchergebnisse ist mit unter 1 sek. im Mittelwert auch zufriedenstellen.
CREATE TABLE `artikel` (
`pid` int(11) NOT NULL auto_increment,
`source` int(11) NOT NULL default '0',
`name1` varchar(150) NOT NULL default '',
`name2` varchar(250) NOT NULL default '',
`name3` varchar(100) NOT NULL default '',
`description` tinytext NOT NULL,
[....]
PRIMARY KEY (`pid`),
KEY `source` (`source`),
FULLTEXT KEY `simple` (`name1`,`name3`),
FULLTEXT KEY `extended` (`name1`,`name2`,`name3`,`description`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 MAX_ROWS=30000000
Die Abfrage (mit Volltext) erfolgt etwa wie folgt:
SELECT SQL_CALC_FOUND_ROWS a.*, b.*
FROM artikel a, quellen b
WHERE a.source=b.sid and
MATCH (a.name1, a.name2, a.name3, a.description)
AGAINST ('suchbegriff' IN BOOLEAN MODE)";
AND [...] ORDER BY [...] LIMIT [...]
Für die Aktualisierung nehme ich eine leere Tabelle mit der gleichen Struktur, aber OHNE jegliche Volltextindizes.
In diese werden dann nacheinander alle Quelldaten eingelesen, die im Laufe des Tages reinkommen (das Einlesen findet nachts statt, um die Gesamtlast auf die Datenbank niedrig zu halten. da die Abfragen hauptsächlich während der üblichen Arbeitszeiten [von Normalmenschen, nicht meinen] stattfinden).
Sind alle Quelldaten neu eingelesen (4-5 Nächte), wird die neu befüllte Tabelle mit den Volltextindizes aufgerüstet (5 Stunden) und anschließend gegen die "alte" Tabelle ausgetauscht, welche nach erfolgreichem "Umschalten" dann gelöscht wird. Das Ganze läuft natürlich automatisiert über Cron-Jobs.
Nun möchte (muss) ich aber einen schnelleren Aktualisierungsrhythmus erreichen, im Idealfall möchte ich on-the-fly oder mit wenigstens täglicher Änderung Daten austauschen/updaten/löschen können. Bei den Tabellengrößen, mit denen ich im Normalfall zu tun habe (<500.000 Datensätze) kein Problem, aber hier:
Es gibt keine eindeutige Nummer für die verschiedenen Artikel; die kommen von verschiedenen Zulieferern und haben ihre eigene Nummernsystematik, daher kann ich nicht gezielt Datensätze prüfen und austauschen (was sonst wohl einfacher wäre, da sich an der volltextrelevanten Beschreibung nicht immer was ändert).
Aktualisiere ich die Artikelliste live - auch nur um einen einzigen Datensatz -, stört der Volltextindex, der ja jedes Mal neu aufgebaut werden muss; ohne den dauern aber die Suchvorgänge unzumutbar lange.
Eine Master/Slave-Lösung kommt z.Zt. nicht in Frage, da mir nur ein Server zur Verfügung steht.
Ein Verzicht auf die große Tabelle durch das Zusammenschalten von 3000 schnell auszuwechselnden kleinen Quell-Tabellen über die MERGE-Engine geht ebenfalls nicht, da ich dann keinen Volltext-Index über den gesamten Datenbestand mehr habe.
So, und nun weiß ich nicht mehr so richtig weiter. Was ich brauche, ist ein Denkanstoß; ich habe mich hier in eine Richtung verrannt und sehe wahrscheinlich den Wald vor Bäumen nicht mehr. Danke für Eure Geduld, dies gelesen zu haben.