MySQL Optimierung: ~Wordcount

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • MySQL Optimierung: ~Wordcount

    Hi,
    ich sammle die ganzen Referer Keywords über die man zu easy-coding und meinen anderen Domains kommt.
    In letzter Zeit hatte der ganze MySQL Server öfter mal aussetzer und vielleicht ist gerade diese DB der Grund dafür.

    Quellcode

    1. CREATE TABLE `Keywords` (
    2. `id` MEDIUMINT NOT NULL auto_increment,
    3. `Domain` VARCHAR(128) NOT NULL,
    4. `Jahr` SMALLINT(4) NOT NULL,
    5. `Monat` SMALLINT(2) NOT NULL,
    6. `String` varchar(255) NOT NULL,
    7. `Count` SMALLINT(4) NOT NULL,
    8. PRIMARY KEY (`id`)
    9. )


    erhalte ich ein Keyword, wird erst geprüft ob das Keyword in der Datenbank ist
    ja -> UPDATE
    nein -> INSERT

    die datenbank hat sich auf 85.000 Einträge gesammelt

    meint ihr es wäre vielleicht schneller immer nur das Keyword hinzuzufügen und am Ende des Tages per Cronjob die Einträge mit der Anzahl der Vorkommnisse zusammenzufassen?

    Habe nicht viel Erfahrung mit Performanceausbeite bei SQL Anwendungen

    Die einzige Speicheroptimierung die mir einfallen würde, wäre den Domain-String in eine ID zu packen. Da ich die Domains aber anhands des Referers auswerten will, würde ich die ID aber nur intern verwenden können, und es würde mich eine weitere Abfrage kosten. Und da ist mir Performance wichtiger als Speicher

    Indizes machen in dem Fall auch keinen Sinn, oder?

    Danke schonmal für eure Ideen!

  • hm.. ich gaub ich entscheide mich ganz gegen eine relationale Datenbank
    Die Datenbank wird jeden tag größer und größer und dadurch langsamer und langsamer

    doch für ein simples rein- und rausspiel reichen vielleicht sogar einzelne, binäre textdateien für jeden tag

    /domain.tld/jahr/monat/tag.txt
    /domain.tld/jahr/monat.txt
    /domain.tld/jahr.txt


    ich denke bei nur 1000 schreibzugriffen am tag brauch ich nichtmehr auf stunden aufteilen
    die monatsstatistik kann ich dann im monat 1x per shellscript erstellen

    doch irgendwie mag ich keine textdateien *g*

  • Wenn der Domainname als String gespeichert ist (was ich annehme), würde ich keinen Index auf diesen legen. Indizes auf Strings brauchen längere Bearbeitungszeit als Indizes auf numerische Werte...

    vielmehr fällt mir zu dem Thema auch nicht ein.

    Die Frage ist aber ob du solch eine detaillierte Statistik brauchst, oder ob du nicht die älteren Sachen wegschmeißen könntest...

    cya

  • Servus,

    also womöglich ist es ja schon zu spät und du hast die Sache mit den Textdateien schon umgesetzt, aber naja, vielleicht hilft es ja noch:

    Wenn du glaubst mit Textdateien schneller und effizienter zu sein als eine Datenbank, dann wirst du wohl eher früher als später enttäuscht werden. Weiß nicht genau was du dir alles in den Dateien merken willst, aber wenn es irgendwann mal diese 85.000 Datensätze sein werden, wird es wohl eng werden.

    Vielleicht wäre es sinnvoller sich mit der Datenmodell zu beschäftigen. Du willst dir ja die Referer merken über die man auf deine Domains kommt und daraus dann wohl eine Statistik erstellen.

    Als Attribute wären dazu wohl Referer, Datum und Domain ausreichend. Eine künstliche ID braucht es nicht unbedingt, da man einzelne Einträge wohl nicht zu adressieren braucht. Veraltete Einträge bekommt man über das Datum.

    Quellcode

    1. CREATE TABLE referer (
    2. referer VARCHAR(255) NOT NULL,
    3. datum DATE NOT NULL,
    4. domain VARCHAR(255) NOT NULL
    5. );


    Jetzt brauchst du nur noch mit INSERT INTO jeweils einen neuen Datensatz einzufügen. Eine Datenbank sollte mit hundertausenden von Einträgen ohne Probleme klarkommen.

    Das Hauptproblem bei deiner bisherigen Lösung dürfte aber weniger das Datenmodell, sondern eher die MySQL Tabellenart gewesen sein. Standardmäßig werden MyISAM Tabellen verwendet, die nur table level locking unterstützen und so bei UPDATEs (die ja mit der Zeit fast ausschließlich stattfanden, da keine neuen referer hinzukamen) alle Anfragen seriell ausgeführt werden, also jeder Client auf den gerade UPDATEenden warten muss. InnoDB würde wohl schon was bringen, da hier row level locking möglich ist, und so mehr parallel laufen kann.

    Aber Textdateien, kann mir nur schwer vorstellen das das schneller und einfacher sein soll.

  • servus,

    danke für die ausführliche antwort!!
    hilft mir wirklich weiter.

    also aktuell hab ichs mal schnell mit textdateien umgestzt (pro Tag wird eine neue erstellt) und am ende wirds mit nem externen programm (cat *g*) alles in eine große geschrieben.

    performance sollte also "befriedigend" laufen
    aber was z.b. dieses MyISAM ist, wusste ich bis dato noch gar nicht..
    bei so vielen referern, kann man darin wohl wirklich die performancebremse ausmachen

    mit der neuen lösung könnte ich also wieder auf mysq umsteigen :)

  • Quellcode

    1. INSERT INTO `referer` (`referer`,`datum`,`domain`,`count`)
    2. VALUES ('referer',NOW(),'domain',0)
    3. ON DUPLICATE KEY UPDATE `count`=`count`+1;


    Hm, ON DUPLICATE KEY ist zwar nicht im SQL Standard, aber da es ja konkret um MySQL geht, ist das denke ich vertretbar :)

    Aber ich glaube trotzdem, dass damit das Problem nicht gelöst wird, da es ja dann wieder ein UPDATE ist und die locking-Problematik auftritt.

    Wenn ich mir das nochmal so generell anschaue, versteh ich gerade nicht wozu das Datum eigentlich gebraucht wird? Da könnte man vielleicht einfach noch Datenmengenmäßig was sparen.