millionen von datensätzen ...

R

_Robin_

Grünschnabel
MySQL millionen von datensätzen ...

hi,

hab ein Problem - habe millionen von datensätze und muss diese innerhalb weniger sekunden nach kriterien durchlaufen und ausgeben.

unter

http://www.epackage.de/epackage/lmw...=18&LMIN=&LMAX=&VA=0&KA2=18&PMAX=&ST=0&KA3=18

gibt es ein beispiel. ich weiß, das die firma 1x am tag die daten komplett updated. mit welchem system das läuft weiß ich leider nicht.

ich soll solch ein system, genau mit den gleichen daten (also reisedaten), nachprogrammieren.

für mich sieht das so aus als ob da hinter keine datenbank liegt oder das gechached ist. aber man kann sehr viele kriterien angeben nach was der suchen soll. z.b. zimmerart, verpflegung, kinder, hotelname, anzahl der sterne, etc. was wiederum gegen ein caching spricht. bin ratlos :/

für jeden tipp bzw jede hilfe wäre ich dankbar.

Gruß seb
 
Zuletzt bearbeitet:
So was kannst du ganz bequem mit PHP und MySQL realisieren. Wenn die Tabellen gut konzipiert sind und auch die Indexe auf den richtigen Spalten liegen, kannst du ohne Problem auch schnelle Ergebnisse bekommen.

Die Datenbank in deinem Beispiel hat auch "nur" 1,5 Millonen Datensatzen. Für MySQL ist sowas ein Klacks. Vorausgesetzt natürlich, es ist gescheit programmiert.

Gruß Marian
 
Hi,

ich hab den ganzen Tag daran gesessen, dass query schnell zu bekommen. Aktuell bekomme ich mit ca. 400.000 daten das ergebniss in 1,5 Sekunden. Indexe sind angelegt und mit EXPLAIN sagt er mir, dass ich auf die index tabelle zugreife. 1,5 Sekunden sind leider viel zu viel. der müßte bei 0,05 sekunden bei 400.000 datensätze sein. ich will/muss später 10.000.000 - 20.000.000 datensätze in ~1 Sekunde erhalten.

mein query: (SEHR einfachere version)
SELECT country,place,count(*) as row,MIN(price) as price FROM kmx_allinone WHERE organiser_id IN (446,14) AND timestamp_start BETWEEN 1126044000 AND 1134684000 GROUP BY country,place

mein explain:
table type possible_keys key key_len ref rows Extra
kmx_allinone index NULL country 80 NULL 389203 Using where; Using index

meine db struktur
CREATE TABLE `kmx_allinone` (
`id` int(10) unsigned NOT NULL auto_increment,
`timestamp_start` int(10) NOT NULL default '0',
`timestamp_stop` int(10) NOT NULL default '0',
`name` varchar(40) NOT NULL default '',
`c` char(1) NOT NULL default '0',
`days` int(2) NOT NULL default '0',
`children1_year` tinyint(2) NOT NULL default '12',
`children1_price` float default NULL,
`children2_year` tinyint(2) NOT NULL default '12',
`children2_price` float default NULL,
`baby` float NOT NULL default '0',
`organiser_id` int(4) NOT NULL default '0',
`country` varchar(20) NOT NULL default '',
`place` varchar(30) NOT NULL default '',
`place2` varchar(30) NOT NULL default '',
`departure_airport` varchar(4) NOT NULL default '',
`arrival_airport` varchar(4) NOT NULL default '',
`star` float NOT NULL default '0',
`status` enum('Y','N') NOT NULL default 'Y',
`r2` varchar(5) NOT NULL default '',
`r` char(3) NOT NULL default '',
`price` double NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `country` (`country`,`place`,`organiser_id`,`star`,`price`,`status`,`timestamp_start`,`timestamp_stop`,`r2`)
) TYPE=InnoDB AUTO_INCREMENT=13649607 ;

habe mich für InnoDB aktuell entschieden da es die indexe nicht kompremiert und daher auch 0,400 sekunden schneller ist.

bin ratlos ;( habe viele unterschiedliche datenbank systeme ausprobiert - bei vielen keinen großen unterschied :/

über jeden tipp, jede hilfe bzw jede anregung wäre ich sehr dankbar.

Gruß Sebastian
 
ohne deine Datenstruktur jetzt genauer analysiert zu haben:

Setze einen Index für:
organiser_id
timestamp_start

Für timestamp-Werte solltest du kein int nehmen sondern entweder TIMESTAMP oder DATETIME

Gruß Marian
 
Hi, was mir bei deiner Tabelle aufgefallen ist:
Sie ist schlecht bis garnicht normalisiert. Unter umständen kann das auch schon was bringen.
 
Hallo,

@heddesheimer
warum meinst du soll ich noch ein weiteren index auf organiser_id und timestamp_start setzen ?

habe timestamp nun nicht mehr als int sondern als TIMESTAMP 8 stehen. hat leider nicht viel gebracht.


@niggo
ja das stimmt. jedoch wird bei dem querys, welches ich genannt habe, lediglich auf die indexe zugegriffen. bzw das problem bei der tabelle ist, das er ca. 60% aller daten wirklich braucht die in der tabelle stehe. ich denke bzw habe die erfahrung gemacht, das joins hier weniger gut bzw performat sind.

Gruß Sebastian
 
Zum Thema Normalisierung:
Normalisierung bringt viel - viel Zeitverlust.

Je nach Anwendung würd ich mir überlegen bis max. zur 2. Normalform zu gehen. Weiter nicht, vor allem nicht für eine Webanwendung. Hier ist teilweise die 2. schon zu langsam. Viele große Internetanbieter haben so gut wie nicht normalisiert - eben nur das notwendigste.

Ad 20 Mio. Datensätzen:
Da würd ich mir dann schon eine gscheite Datenbank überlegen und keine MySQL.
 
_Robin_ hat gesagt.:
@heddesheimer
warum meinst du soll ich noch ein weiteren index auf organiser_id und timestamp_start setzen ?
Gruß Sebastian
Zum Vergrößern anklicken....

Ich sag doch, ich habe die Tabelle nicht eingehend analysiert und auf den ersten Blick keinen Index auf die Felder gesehen. Was du wohl hast ist ein komposit-Index "country" der aus mehreren Spalten zusammengesetzt ist. Was du damit erreichen willst, weiß ich allerdings nicht.

Ich meinte, du solltest für die beiden Spalten einen eigenen Index setzen, dann sollte die Abfrage superschnell laufen.

Gruß Marian
 
@Norbert Eder
jo, ähnliche erfahrungen habe ich auch gemacht. welche datenbank würdest du empfehlen ? habe MSSql und postq bis dato ausprobiert.

@heddesheimer
hab mal die indexe so wie du sie wolltest geändert. dauert nun statt 1,4 Sekunden 3,8 Sekunden. Wenn ich explain mache sagt er mir auch das er im filesort sucht. wäre es eventuell sinnvoll wenn ich jedem land eine zahl zuordne und danach gruppiere und beim auslesen die zahl wieder ändere ?
 
Nimm den MS SQL Server. Sofern das Produkt erst im November released wird, kannst du auch den MS SQL Server 2005 nehmen, der ist um ne Ecke performanter.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück