[DB] Performance (viele Tabellen o. viele Tabelleneinträge?)

R

resoucer

Gesperrt
ID: 77379
L
20 April 2006
2.846
109
Hi, ich wollte mal die Performancespzialisten fragen was schneller und besser ist bei folgendes Vorhaben:

Statistik von Bannerviews / Klicks
in einer DB schreiben.

Entweder jede KW eine neue Tabelle erstellen
oder doch jeden Monat erst eine neue Tabelle erstellen?

Einträge sind ca. (views) 500.000 stk je Kalenderwoche (steigend)

Abgerufen wird die Statistik ca. 2000 mal am Tag (steigend)

Und halt mehrere Inserts inner Sek.

Aktuell wird halt per Kalenderwoche gespeichert, aber da hat man nach 5 Monaten sehr viele Tabellen. Aber wenn ichs per Monat mache dann habe ich sehr viele Einträge in einer Tabelle (dafür weniger Tabellen)

mhh, was würdet Ihr mir empfehlen ?
 
Huhu,
wie sind denn die Anforderungen an die Statistik? Gibt es viele Auswertungen über größere Zeiträume?

Nutzt du MySQL? (Ich Frage, weil andere DBMS mit partitionierten Tabellen deine manuelle Partitionierung überflüssig machen würden.)

Aus dem Bauch raus: Auch bei 2 Mio. Einträgen pro Monat würde ich noch keine neue Tabelle erstellen. Da unterschätzt du deine Datenbank. Aber das ist natürlich sehr abhängig von dem Server, auf dem die Datenbank läuft und letztenendes von der Optimierung. ;)

Gruß, Zera
 
ja ich nutze mysql
abgefragt werden ca. alle Datensätze innerhalb von 7 Tagen
Server ist ein 4ghz pentium mit 2gb ram (root)
 
Jup, schade, dass Partitionierung erst mit PHP5.1 kommt, das würde alles so simpel machen :(
Ich würde an deiner Stelle so rechnen, dass in der Tabelle so 3-4 mio Einträge sind, bei mehr ist es anhand der (partiellen) Indexe nur festzustellen, wieviel mehr verkraftet wird, da es dann auf die Genauigkeit der Schlüssel ankommt wieviele Datensätze auf ein Schlüssel(paar) zutreffen

Edit: Meine natürlich MySQL5.1 ^^
 
Zuletzt bearbeitet:
ice-breaker schrieb:
Jup, schade, dass Partitionierung erst mit PHP5.1 kommt, das würde alles so simpel machen :(
Ich würde an deiner Stelle so rechnen, dass in der Tabelle so 3-4 mio Einträge sind, bei mehr ist es anhand der (partiellen) Indexe nur festzustellen, wieviel mehr verkraftet wird, da es dann auf die Genauigkeit der Schlüssel ankommt wieviele Datensätze auf ein Schlüssel(paar) zutreffen
Zum Vergrößern anklicken....

also folgende php version ist drauf:

PHP Version 5.2.0
 
Hattest du es schon mit größeren Tabellen probiert? Oder von Anfang an per Woche unterteilt?

Wenn du die Nutzung der Statistiken so gut vorhersagen kannst, dann bietet sich doch ein Index auf das Datum, vielleicht auf die Kalenderwoche an. Und damit sollten auch mehrere Mio. Einträge für MySQL kein Problem sein. (Vermute ich. Habe schon länger nichts mehr mit MySQL als DBMS gemacht.)

Aber grundsätzlich zu deiner Frage:

Mehr Einträge bedeutet höhere kosten beim Lesen. Fürs Schreiben ist die Anzahl der Einträge nur relevant, wenn Indices aktualisiert werden müssen. Die Kosten beim Lesen kannst du senken, indem du mit Indices Hilfestellungen bietest.

Mehr Tabellen bedeutet, dass du schon vor Abfrage der DB eine Logik implementieren musst, die dir eine Vorauswahl der zu lesenden Tabellen erstellt. Du übernimmst hier also die Aufgabe eines Index.

Ich persönlich würde immer versuchen möglichst viel auf der DB zu lösen. :)

Gruß, Zera
 
ja die DB ist akt. in Wochen unterteilt

hatte vor den DB aufbau so in etwa zu machen:

PHP: 
CREATE TABLE `log_click_k44` (
  `uid` int(6) NOT NULL default '0',
  `aid` int(5) NOT NULL default '0',
  `kid` int(7) NOT NULL default '0',
  `ip` varchar(15) NOT NULL,
  `host` varchar(255) NOT NULL,
  `referer` text NOT NULL,
  `type` varchar(10) NOT NULL,
  `time` int(11) NOT NULL,
  `datum` varchar(10) NOT NULL,
  KEY `uid` (`uid`),
  KEY `aid` (`aid`),
  KEY `kid` (`kid`),
  KEY `datum` (`datum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
habe mal bei wikipedia bezüglich der (hash etc.) Partitionierung gelesen.

kann da nur nicht ganz durchsteigen wie das genau funzt bzw. was das genau bringt. Sind ja leider nur Beispiele mit sehr wenig Text da
 
nur nen Tip, deine Indices bringen rein gar nix ;)
dieser Irrglaube man müsse einfach wild Indices setzen.
Pro Mysq-Abfrage kann nur EIN Index genutzt werden, du kannst aber mittels partiellen indexen mehrere zugleich zum genauer selektieren nutzen.

Also deine gesammte Tabelle ist auch totaler Mist. falsche Datentypen etc etc
Also mit der Tabelle wirst du nicht mal 1mio Einträge verkraften.
 
@ice-breaker: Ich bin der Meinung gelesen zu haben, dass man einen Index über alle Felder setzen soll, die im WHERE-Teil der MySQL-Abfrage vorkommen. So hab ich das mal in einer Dokumentation drüber gelesen. :-?

EDIT: Allerdings, da du auch sehr viele INSERTs machst, würd ich die Indexe ganz sein lassen. Denn ob der Ersparnis beim SELECT den erhöhten Aufwand beim INSERT ausgleicht, halte ich für fraglich.
 
tobias1985 schrieb:
@ice-breaker: Ich bin der Meinung gelesen zu haben, dass man einen Index über alle Felder setzen soll, die im WHERE-Teil der MySQL-Abfrage vorkommen. So hab ich das mal in einer Dokumentation drüber gelesen. :-?
Zum Vergrößern anklicken....

und das sind die falsch aussagen, die man immerwieder zu hören bekommt, totaler Mist einfach nur. Es kann nur ein Index pro Query genutzt werden, das ist wie mit einem Telefonbuch, kannst du zugleich nach Namen und Ort suchen wenn diese voneinander getrennt sind? Nein!
Das klappt nur wenn die Namen in die Orte eingeteilt wurden, dann schaust du erst nach dem richtigen Ort und dann dem Namen :arrow: partielle Indices

sind alles so Dinge, die man bei der DB-Optimierung lernt ;)
 
mal ne kurze frage zwischendurch

phpMyAdmin - 2.11.2
* MySQL-Client-Version: 5.0.37
* Verwandte php-Erweiterungen: mysql

PHP Version 5.2.1
PHP: 
CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH(store_id)
PARTITIONS 4;

warum klappt da nicht diese SQL

PHP: 
 MySQL meldet: Dokumentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PARTITION BY HASH(store_id)
PARTITIONS 4' at line 10
 
weil Partitionierung erst mit MySQL5.1 geht, sollte denke ich doch logisch sein, dass PHP damit nix zu tun hat, oder? :LOL: (hatte mich verschrieben)
 
tobias1985 schrieb:
Allerdings, da du auch sehr viele INSERTs machst, würd ich die Indexe ganz sein lassen. Denn ob der Ersparnis beim SELECT den erhöhten Aufwand beim INSERT ausgleicht, halte ich für fraglich.
Zum Vergrößern anklicken....

Klar, wenn man den Server lahmlegen will ist das genau das was man bei großen Tabellen tun sollte. :LOL:

Zum eigentlichen Thema. Vielleicht wäre es bei weitem sinnvoller keine Realtime-Statistiken aus der Tabelle zu erzeugen. Entweder man erzeugt die Statistik immer nur aller x Stunden, oder wenns Realtime sein soll kann man die Daten beim schreiben gleichzeitig aufbereitet in einer anderen Tabelle hinterlegen.

PS: mysql hält ein klitze klein mehr als 500.000 Datensätze aus... :roll: Und wenn man die Tabelle ordnetlich gestalltet hält die DB sogar noch mehr aus...

Aber kleiner tipp... es bringt null Punkte irgendwelchen Müll zu speichern.
 
500000 ?
Also ich hatte schon RealWorld-Datenbanken "unter Kontrolle" bei der Tabellen 5-6mio Einträge hatten und es lief alles wie geschmiert, natürlich sollte man Tabellen dann auch intelligent aufbauen.
 
Ja entschuldigung ich hab da nen Wort und die ironie Tags vergessen :ugly:

korrigierte Version: "PS: mysql hält ein [ironie]klitze klein wenig[/ironie] mehr als 500.000 Datensätze aus... :roll:"
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben