mysql und "grosse" Tabellen

Hallo

Hat evtl. einer Erfahrungen wie "performat" grosse Tabellen mit mysql sind?

Also ich erwarte von der Größe her eine Tabelle die pro Jahr etwa 1 Mrd
Einträge haben wird (1xbigint, 2x float, 1x integer, 1x DateTime, 1x 16er-
VARCHAR). "Gehalten" werden sollen max. etwa 2 Jahre. Es müssen nur "selten"
wenige select-Abfragen gemacht werden; das meiste sind halt Inserts, selten
ein "expirere mit DELETE". Die Antwortzeiten bei den wenigen SELCT-Abfragen
sollte wenige sec betragen ;) Klar sinnvolle Indexe verwenden...
Was denkt Ihr ist sinnvoller/besser; eine "Monstertabelle" oder diese eine
Tabelle anhand von "groben" Kriterien (Monat, Woche etc.) z.B. in 50 kleine
aufzuteilen und diese einzeln abzufragen? Programmiertrechnisch ist natuer-
lich das erste viel einfacher "zusammengeschrieben".. da auch viel weniger
select-Abfragen (klar aber auf mehr Daten) oder halt mehr Selects auf je
weniger Datenbestand (getrennte Tabellen)....?

Derzeit habe ich ein datenfile (per C "angebautes" Programm, das mit
mmap() das jeweils in den Speicher mappt) pro Kriterium; ist halt so
einstanden (es war damals auch nur ein 20tel der heute auflaufenden
Daten). Wenn man das jetzte ueber sagen wir gleichzeitig 300 dieser
Files (kriterien) auswertet (noch ohne mysql) dautert dies
halt schon mal 30 sekunden ;(



S.

Re: mysql und "grosse" Tabellen

Am 09.03.2007 17:08 schrieb sylvio runge:
> Hallo
>
> Hat evtl. einer Erfahrungen wie "performat" grosse Tabellen mit mysql sind?
>
> Also ich erwarte von der Größe her eine Tabelle die pro Jahr etwa 1 Mrd
> Einträge haben wird (1xbigint, 2x float, 1x integer, 1x DateTime, 1x 16er-
> VARCHAR). "Gehalten" werden sollen max. etwa 2 Jahre. Es müssen nur "selten"
> wenige select-Abfragen gemacht werden; das meiste sind halt Inserts, selten
> ein "expirere mit DELETE". Die Antwortzeiten bei den wenigen SELCT-Abfragen
> sollte wenige sec betragen ;) Klar sinnvolle Indexe verwenden...
> Was denkt Ihr ist sinnvoller/besser; eine "Monstertabelle" oder diese eine
> Tabelle anhand von "groben" Kriterien (Monat, Woche etc.) z.B. in 50 kleine
> aufzuteilen und diese einzeln abzufragen? Programmiertrechnisch ist natuer-
> lich das erste viel einfacher "zusammengeschrieben".. da auch viel weniger
> select-Abfragen (klar aber auf mehr Daten) oder halt mehr Selects auf je
> weniger Datenbestand (getrennte Tabellen)....?
>

Wenn Du eine sehr neue MySQL-Version verwendest, kannst Du deren
Partitionierungsfähigkeiten benutzen. D.h. Du kannst das Zerlegen der
Tabelle in Teile nach Monate o.ä. MySQL überlassen und musst in Deiner
Anwendung keine Klimmzüge veranstalten.

Oder eben gleich z.B. Oracle verwenden, das kann das jetzt schon.
PostgreSQL auch, aber dort ist es etwas "krampfig" realisiert bislang.

Re: mysql und "grosse" Tabellen

On 09.03.2007 17:22, Christian Kirsch wrote:
> Am 09.03.2007 17:08 schrieb sylvio runge:
>> Hallo
>>
>> Hat evtl. einer Erfahrungen wie "performat" grosse Tabellen mit mysql sind?
>>
>> Also ich erwarte von der Größe her eine Tabelle die pro Jahr etwa 1 Mrd
>> Einträge haben wird (1xbigint, 2x float, 1x integer, 1x DateTime, 1x 16er-
>> VARCHAR). "Gehalten" werden sollen max. etwa 2 Jahre. Es müssen nur "selten"
>> wenige select-Abfragen gemacht werden; das meiste sind halt Inserts, selten
>> ein "expirere mit DELETE". Die Antwortzeiten bei den wenigen SELCT-Abfragen
>> sollte wenige sec betragen ;) Klar sinnvolle Indexe verwenden...
>> Was denkt Ihr ist sinnvoller/besser; eine "Monstertabelle" oder diese eine
>> Tabelle anhand von "groben" Kriterien (Monat, Woche etc.) z.B. in 50 kleine
>> aufzuteilen und diese einzeln abzufragen? Programmiertrechnisch ist natuer-
>> lich das erste viel einfacher "zusammengeschrieben".. da auch viel weniger
>> select-Abfragen (klar aber auf mehr Daten) oder halt mehr Selects auf je
>> weniger Datenbestand (getrennte Tabellen)....?
>>
>
> Wenn Du eine sehr neue MySQL-Version verwendest, kannst Du deren
> Partitionierungsfähigkeiten benutzen. D.h. Du kannst das Zerlegen der
> Tabelle in Teile nach Monate o.ä. MySQL überlassen und musst in Deiner
> Anwendung keine Klimmzüge veranstalten.
>
> Oder eben gleich z.B. Oracle verwenden, das kann das jetzt schon.
> PostgreSQL auch, aber dort ist es etwas "krampfig" realisiert bislang.

SQL Server 2005 hat auch Partitions.

Generall kann man etwas ähnliches mit allen Datenbanken erreichen, die
Views können. Man fasst einfach eine Menge von Tabellen mit dem selben
Schema per UNION ALL in einem View zusammen. Nachteil gegenüber echten
Partitionen ist, dass das Hinzufügen und Löschen einer Pseudopartition
ggf. keine Online-Operation ist (d.h. es dürfen gerade keine Abfragen
gegen den View laufen).

Ciao

robert

Re: mysql und "grosse" Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: mysql und "grosse" Tabellen

Hi.

ter Tabellentyp MERGE könnte Dir als Ersatz für Partitionierung evtl.
helfen. Bis jetzt habe ich allerdings keine Erfahrung damit.

Gruß,
Joachim