1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Datenbank: Query Cache…

2 Sachen fallen mir dazu ein...

  1. Thema

Neues Thema Ansicht wechseln


  1. 2 Sachen fallen mir dazu ein...

    Autor: kayozz 02.03.11 - 17:42

    1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das würde die Länge des Keys ziemlich reduzieren.

    2. Ist die direkte Integration von Memcached eine recht nette Idee. Dadurch erspart sich der Entwickler den Aufwand in der Anwendungslogik:
    a) Versuch das Ergebnis über Memcached abzurufen
    b) Kein Ergebnis? Dann über die Datenbank abrufen
    c) Wenn das Ergebnis nicht von Memcached kam, dann jetzt in Memcached speichern
    d) Nach einem Update/Insert den Eintrag aus dem Cache leeren
    Ausserdem beschleunigt sich so das Speichern der Datensätze in Memcached, da das direkt auf dem Server passiert.

    Aber: Ich sehe ein großes Problem beim aktuell halten des Caches:
    Nehmen wir mal an, ich habe einen Cache auf der Tabelle User. Jetzt wird ein User geändert und ich möchte den Cache löschen. Wie mache ich das?
    Programmierer A hat ein einer Stelle im Programm "SELECT id, name FROM users" abgefragt
    Programmierer B hat an einer anderen Stelle "SELECT id, name, email FROM users" abgefragt.
    Da habe ich doch keine Möglichkeit den Cache gezielt zu leeren, weil ich ja nicht weiß, welche Queries alle gecached wurden.

    Wenn das ganze schon natlos in die Datenbank integriert ist, dann wäre der logische Schritt, zu protokollieren, welcher Datensatz aktuell gerade in welchen Caches vorhanden ist und, bei einer Änderung, die betreffenden Caches dann zu leeren.
    Allerdings müsste bei jedem INSERT oder DELETE alle Caches, die Daten aus der betreffenden Tabelle halten ebenfalls geleert, bzw. idealerweise in einem Hintergrundthread aktualisiert werden, um die neusten Änderungen ebenfalls zu berücksichtigen.

  2. Re: 2 Sachen fallen mir dazu ein...

    Autor: scroogie 02.03.11 - 18:17

    In der Regel arbeitet man bei memcached mit Prefixen auf dem Key. Man würde also db_tablename_{$queryhash} als Schlüssel nehmen. Bei einem verändernden Query auf die Tabelle löscht man dann alle Einträge die mit db_tablename_ anfangen.

    Der Autor hat sich allerdings für Pseudo-Befehle in Kommentaren entschieden. Man schreibt z.B. /* cache:refresh */ an den Anfang eines Queries.

    Beides hat meiner Meinung nach anwendungsspezifische Vor- und Nachteile.

  3. Re: 2 Sachen fallen mir dazu ein...

    Autor: ssssssssssssssssssss 02.03.11 - 19:30

    macht das nich oracle so?
    also queries cachen und als key den hash verwenden?
    scheint ganz gut zu funktionieren vor allem mit prepared statemens :)

  4. Re: 2 Sachen fallen mir dazu ein...

    Autor: Dumpfbacke 03.03.11 - 09:05

    kayozz schrieb:
    --------------------------------------------------------------------------------
    > 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
    > würde die Länge des Keys ziemlich reduzieren.
    Ist wohl eher die Frage, wieviel Rechenleistung es kostet für jeden Querie einen Hash zu berechnen.

    > 2. Ist die direkte Integration von Memcached eine recht nette Idee. Dadurch
    > erspart sich der Entwickler den Aufwand in der Anwendungslogik:
    Für den Entwickler sollte sich gar nichts ändern.
    Wenn der Cache gut gemacht wurde, bekommt der Entwickler vom Cache selber gar nichts mit.

    > a) Versuch das Ergebnis über Memcached abzurufen
    > b) Kein Ergebnis? Dann über die Datenbank abrufen
    > c) Wenn das Ergebnis nicht von Memcached kam, dann jetzt in Memcached
    > speichern
    > d) Nach einem Update/Insert den Eintrag aus dem Cache leeren
    > Ausserdem beschleunigt sich so das Speichern der Datensätze in Memcached,
    > da das direkt auf dem Server passiert.
    Du hast eben das Prinzip eines Caches beschrieben. Diese Technik wurde bereits in DOS benutzt (Smartdrive) und wird in jeder CPU in Form des 1. und 2. Level Caches genutzt ;).

    mfg

  5. Re: 2 Sachen fallen mir dazu ein...

    Autor: VirtualInsanity 03.03.11 - 09:54

    kayozz schrieb:
    --------------------------------------------------------------------------------
    > 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
    > würde die Länge des Keys ziemlich reduzieren.
    >

    Wäre das nicht theoretisch ein Risiko?
    Stimmt der Hashwert zweier verschiedener Queries zufällig überein (auch wenns noch so unwahrscheinlich ist), dann müsste es doch zu unvorhersehbaren Fehlern kommen oder?

  6. Re: 2 Sachen fallen mir dazu ein...

    Autor: Dumpfbacke 03.03.11 - 10:05

    VirtualInsanity schrieb:
    --------------------------------------------------------------------------------
    > kayozz schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
    > > würde die Länge des Keys ziemlich reduzieren.
    > >
    >
    > Wäre das nicht theoretisch ein Risiko?
    > Stimmt der Hashwert zweier verschiedener Queries zufällig überein (auch
    > wenns noch so unwahrscheinlich ist), dann müsste es doch zu
    > unvorhersehbaren Fehlern kommen oder?
    Theoretisch ja, allerdings kannst du da auch gleich überlegen, wie oft ein Bit umfällt und das Probleme verursachen könnte ;).

    Das Ergebnis wäre in beiden Fällen nicht mehr richtig.

  7. Re: 2 Sachen fallen mir dazu ein...

    Autor: VirtualInsanity 03.03.11 - 10:21

    Dumpfbacke schrieb:
    --------------------------------------------------------------------------------
    > Das Ergebnis wäre in beiden Fällen nicht mehr richtig.

    So oft wie Fehler in meinem Code auftreten... da muss das mit den Bits schon sehr oft passieren. :-D

  8. Re: 2 Sachen fallen mir dazu ein...

    Autor: kayozz 03.03.11 - 12:23

    Rein theoretisch sind Collisions in MD5 möglich.
    D.H zu einem MD5 Hash für den String "SELECT * FROM employees" lässt sich, mit gewissen Aufwand ein weiterer String berechnen, der den selben Hash generiert. Allerdings würde dieser String dann wohl eher aus Datenmüll bestehen.

    Ich lehne mich mal aus dem Fenster, und behaupte es gibt keine 2 gültigen SQL-Statements, die den selben MD5 Hash besitzen und bleibe bei der Behauptung, bis mir jemand das Gegenteil beweist. Punkt.
    Man muss ja bedenken, dass man einen Befehl findet, der
    a) vom Parser als fehlerfreies SQL erkannt wird
    b) Tabellen/Spalten referenziert, die es auch wirklich in der Datenbank gibt

  9. Re: 2 Sachen fallen mir dazu ein...

    Autor: nil 03.03.11 - 13:35

    Das ist falsch. Es gibt logischerweise unendlich viele gültige SQL-Statements, und selbst wenn man eine Größenbeschränkung definiert (sinnvoll) trotzdem noch deutlich mehr als 2^128. Daher gibt es selbstverständlich Kollisionen.

    Beispiel:
    select *
    from table
    where columna = a
    and columnb = b
    and columnc = c
    and columnd = d;

    a,b,c,d 32 bit, d.h. es gibt bereits von dieser abfrage 2^128 mögliche Ausprägungen. Und etwa 4 Mrd. mal mehr wenn man nur eine Spalte dazu nimmt.

    Daher ist es völlig logisch dass es Kollisionen geben MUSS, die sinnvolles SQL darstellen.

    q.e.d.

  10. Re: 2 Sachen fallen mir dazu ein...

    Autor: murdog 07.03.11 - 10:23

    So ein hashzugriff gestaltet man normalerweise so:

    Die Statements werden mit ihrem Hashwert (MD5 oder ähnliches) und Query gespeichert. Dabei gibt es natürlich Kollisionen.
    Beim wieder rausfinden greift man dann zuerst mit HashWert zu und bekommt eine Liste von Treffern die dem Hash entsprechen. Diese Liste geht man nun durch und macht ein exakten Vergleich auf das Query.
    Das reduziert zwar nicht die größe der Keys, reduziert aber ganz erheblich die Zugriffszeit da nicht alle Queries exakt verglichen werden müssen, sondern über den Hash eine schnelle Vorauswahl möglich ist.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Mitarbeiter (m/w/d) Netzwerk- und Anwendungssupport
    VIVAVIS AG, Bochum
  2. Wissenschaftlicher Mitarbeiter (m/w/d)
    Hochschule Ruhr West, Mülheim an der Ruhr
  3. Leiter IT (m/w/d)
    RAU | FOOD RECRUITMENT GmbH, Oyten bei Bremen
  4. Senior IT-Systems Engineer und Project Manager (m/w/d)
    LEIFHEIT AG, Nassau an der Lahn

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Prozessoren: Intels alte Garde soll es richten
Prozessoren
Intels alte Garde soll es richten

Seit Pat Gelsinger der Intel-CEO ist, holt er viele Ehemalige zurück. Das kann nur klappen, wenn junge Talente ebenfalls davon profitieren.
Eine Analyse von Marc Sauter

  1. Halbleiterfertigung Intel könnte Globalfoundries für 30 Mrd US-Dollar kaufen
  2. Halbleiterfertigung Intel will Fabs über mehrere EU-Länder verteilen
  3. Transactional Memory Intel deaktiviert TSX in Skylake und Coffee Lake

Max Payne: Als Shooter in Zeitlupe erwachsen wurden
Max Payne
Als Shooter in Zeitlupe erwachsen wurden

Max Payne wird 20 Jahre alt! Golem.de hat den Kult-Shooter noch einmal gespielt - und war überrascht, wie gut das Actionspiel gealtert ist.
Von Benedikt Plass-Fleßenkämper


    Handheld-Konsole: Valves Steam Deck im technischen Vergleich
    Handheld-Konsole
    Valves Steam Deck im technischen Vergleich

    Der Chip im Steam Deck erinnert an die SoCs einer Xbox Series X oder Playstation 5, die Ausrichtung von Valve ist aber eine andere.
    Eine Analyse von Marc Sauter

    1. Valves Handheld Scalper verkaufen Vorbestellungen des Steam Deck
    2. Handheld-Konsole Valve-Server bekommt bei Steam-Deck-Reservierung Probleme
    3. Valve Für Scalper ist das Steam Deck eine Herausforderung

    1. Elon Musk: Tesla Model S bekommt ausschließlich Knight-Rider-Lenkrad
      Elon Musk
      Tesla Model S bekommt ausschließlich Knight-Rider-Lenkrad

      Elon Musk hat klargestellt, dass es für das Model S und das Model X kein normales Lenkrad mehr geben wird. Das D-förmige Lenkrad ist Pflicht.

    2. Förderprogramm: Bund will Fachkräfte für Akkuindustrie ausbilden lassen
      Förderprogramm
      Bund will Fachkräfte für Akkuindustrie ausbilden lassen

      Die Aus- und Weiterbildung für Fachleute im Bereich Akkuproduktion und -entwicklung wird mit 40 Millionen Euro aus der Staatskasse gefördert.

    3. Elektroauto: Mercedes EQS mit besserer Hinterachslenkung als Abo
      Elektroauto
      Mercedes EQS mit besserer Hinterachslenkung als Abo

      Den Mercedes EQS gibt es mit Hinterachslenkung mit 4,5 Grad Einschlag. Wer ein Jahresabo abschließt, bekommt sogar 10 Prozent Lenkeinschlag und damit eine bessere Lenkung.


    1. 16:00

    2. 15:00

    3. 14:15

    4. 13:21

    5. 12:30

    6. 11:20

    7. 11:05

    8. 10:51