1. Foren
  2. Kommentare
  3. Internet-Forum
  4. Alle Kommentare zum Artikel
  5. › Data Management: Wie…

worum es hier (glaube ich) eigentlich geht

  1. Thema

Neues Thema


  1. worum es hier (glaube ich) eigentlich geht

    Autor: gelöscht 15.10.14 - 13:52

    ist doch, die daten möglichst schnell zur cpu zu liefern, oder? also möglichst io-wait zu reduzieren. oder sehe ich das falsch? der text deutet zumindest stellenweise daraufhin, obwohl er manchmal (nicht böse gemeint!) ein wenig nach scigen klingt, da ich den bezug zu bspw. fpgas nicht ganz verstanden habe.
    warum mich das ganze hier überhaupt interessiert: ich war erst vor kurzem auf einer schulung bzgl. mysql und dort stellte ich die frage, ob es bei io-kritischen systemen und einer geschickten disk-strategie (vor allem für eine eher für lese-zugriffe designte datenbank, jedoch schreiben nicht ausgeschlossen) nicht sinnvoll wäre, die datenbank auf eine ramdisk zu verlagern, wobei mir da aber nicht bewusst war, dass es ja die "memory"-engine als backend bei mysql gibt.
    warum man diese allerdings überhaupt wählen sollte, wenn man bspw. eine transaktionsfähige datenbank auch in eine ramdisk packen kann, war der schulungsleiter leider nicht in der lage zu erklären.
    vielleicht kann es hier jemand?

  2. Re: worum es hier (glaube ich) eigentlich geht

    Autor: Grinskeks 15.10.14 - 14:14

    Kurz gesagt, sind bei In Memory Datenbanken bzw. Tabellen in der Regel Mechanismen integriert, die im Hintergrund für ein Logging oder Synchs sorgen und somit den Worst Case (Datenverlust) "reduzieren". Die Anpassungen sind auf die konkreten möglichen Anwendungsfälle optimiert.

    Bei einer Ramdisk ist nichts mehr da, sobald die Ramdisk nicht mehr da ist. D.h. jegliche Komponente, die ein System in eine Absturz, Reboot, Shutdown, Hardwareausfall oder Spannungsabfall versetzt, hat potentiell die ganze DB auf dem Gewissen.

    Manche dieser Fälle werden von Ramdisks bereits abgefangen (z.B. Speicher eines Images beim Herunterfahren) - allerdings ist der SQL Server in diesen Fällen effizienter, weil er durch das Logging eben genau weiss, was flüchtig ist und somit gesichert werden muss. Bei einer Ramdisk ist alles flüchtig, denn woher soll das IO System wissen, was auf ApplicationEbene passiert.

    Gruss
    Grinskeks

  3. Re: worum es hier (glaube ich) eigentlich geht

    Autor: Bautz 15.10.14 - 14:21

    Beim Ramdisk hast du dann die ganze DB auf der ramdisk, meist macht es jedoch sinn, nur die "meistgenutzten" Tabellen im RAM zu halten und den Rest auf Festplatten (bzw. SSDs).

  4. Re: worum es hier (glaube ich) eigentlich geht

    Autor: gelöscht 15.10.14 - 14:26

    Grinskeks schrieb:
    --------------------------------------------------------------------------------
    > Kurz gesagt, sind bei In Memory Datenbanken bzw. Tabellen in der Regel
    > Mechanismen integriert, die im Hintergrund für ein Logging oder Synchs
    > sorgen und somit den Worst Case (Datenverlust) "reduzieren". Die
    > Anpassungen sind auf die konkreten möglichen Anwendungsfälle optimiert.
    >
    > Bei einer Ramdisk ist nichts mehr da, sobald die Ramdisk nicht mehr da ist.
    > D.h. jegliche Komponente, die ein System in eine Absturz, Reboot, Shutdown,
    > Hardwareausfall oder Spannungsabfall versetzt, hat potentiell die ganze DB
    > auf dem Gewissen.
    >
    > Manche dieser Fälle werden von Ramdisks bereits abgefangen (z.B. Speicher
    > eines Images beim Herunterfahren) - allerdings ist der SQL Server in diesen
    > Fällen effizienter, weil er durch das Logging eben genau weiss, was
    > flüchtig ist und somit gesichert werden muss. Bei einer Ramdisk ist alles
    > flüchtig, denn woher soll das IO System wissen, was auf ApplicationEbene
    > passiert.
    >
    > Gruss
    > Grinskeks

    ah, danke. also bieten diese engines im prinzip bereits mechanismen, die ich mir ad hoc während der schulung bereits überlegt hatte (natürlich nur skizzenmäßig), um genau diese fälle dann wieder abzufangen. wenn diese natürlich bereits inhärent vorhanden sind, umso besser.
    gibt es eigentlich einschränkungen? bspw. erinnere ich mich, dass die memory-engine bspw. keine blobs speichern konnte.
    obendrein hatten wir (mir geschuldet) fast unendlich lange diskussionen über die datenbankinterne organisation der daten und wie diese "filesystem-aware" sind - bspw. kann man ja bei mysql einstellen, ob ein b-tree oder hashes verwendet werden. findet solch eine betrachtung auch bei ram statt? dort liegen daten ja ebenfalls geordnet, aber nicht wie bei einem filesystem. insbesondere ändert sich die anordnung auch noch schlimmstenfalls je nach speichertechnologie.

  5. Re: worum es hier (glaube ich) eigentlich geht

    Autor: deefens 15.10.14 - 14:58

    Tabellen für Usersessions werden normalerweise in den RAM verfrachtet, weil im Worst Case einfach die User ausgeloggt werden und sich halt einmalig neu anmelden müssen. Ein weiteres Szenario sind Readonly-Data Marts.



    1 mal bearbeitet, zuletzt am 15.10.14 15:08 durch deefens.

  6. Re: worum es hier (glaube ich) eigentlich geht

    Autor: thorben 15.10.14 - 15:11

    Ich hab mich erst vor kurzem ein weeenig mit HANA beschäftigt, weil ich es eigentlich ganz spannend finde und man im Reporting damit auch ganz interessante neue Funktionen bekommt. Um da mal beim ERP Beispiel zu bleiben.
    Wenn ich das richtig verstanden habe, dann ist auch ein sehr großer Unterschied, dass zB in HANA und auch bei DB2 die DB auf eine Spaltenorientierung umgestellt wird, während mein letzer Stand bei MySQL (+wiki überfliegen) ist, dass das rein relationell ist.

    Ich muss mal wieder mein Datenbankwissen auffrischen -.- Vom Prinzip her ein ganz spannendes Thema, auch auf der Anwendungssicht.

  7. Re: worum es hier (glaube ich) eigentlich geht

    Autor: niw8äüö 15.10.14 - 15:27

    Ergänzend zu Grinskeks:
    Wenn du sowieso vorhast, direkt in den Speicher zu schreiben, dann ist es eben auch sinnvoll, gleich mit dem Speicher zu operieren, anstatt sich wie bei einer Ramdisk auch noch den - in diesem Fall unnützen - Overhead eines Dateisystem als Zwischenschicht herumzuschlagen.

  8. Re: worum es hier (glaube ich) eigentlich geht

    Autor: Nullmodem 17.10.14 - 16:18

    Die Datenbank arbeitet nicht auf Dateien, die arbeitet immer auf Pages (Speicherstruktur).
    Die Platte ist ein Großer Hintergrundspeicher, der alle Pages hält, zum Bearbeiten und Ändern holt die DB die nötigen Pages in den RAM.
    Wenn du den Hintergrundspeicher in den RAM verlagerst, kopiert die DB einerseits sinnlos Pages im RAM hin und her, andererseits wird der nutzbare RAM auch noch kleiner. Will keiner.

    Anekdote: Windows CE hat früher mal eine RAM-Disk angelegt, um dort die Auslagerungsdatei reinzuspeichern. <facepalm>

    nm

  9. Re: worum es hier (glaube ich) eigentlich geht

    Autor: Quantium40 21.10.14 - 16:07

    Nullmodem schrieb:
    --------------------------------------------------------------------------------
    > Anekdote: Windows CE hat früher mal eine RAM-Disk angelegt, um dort die
    > Auslagerungsdatei reinzuspeichern.

    Es gibt durchaus Szenarien, in denen solch scheinbarer Blödsinn durchaus sinnvoll sein kann. Manche Applikation aus alten Tagen verlangt beispielsweise eine Auslagerungsdatei einer bestimmten Mindestgröße unabhängig vom tatsächlich verbauten RAM.
    Mit einer Auslagerungsdatei in einer RAM-Disk verliert man in so einem Szenario nur ein Minimum an RAM für die RAM-Disk-Software und die Verwaltungsstrukturen des Dateisystems der RAM-Disk, hat aber sonst für die Applikationen weitgehend genausoviel RAM zur Verfügung.
    Für die Alt-Applikationen fällt aber das vergleichsweise langsame Swappen auf den Flash-Speicher weg, weil das deutlich schneller direkt im RAM passiert.

  1. Thema

Neues Thema


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-Service Desk Manager und IT & OT -Device Administrator (m/w/d) Kennziffer 23/37 | Vollzeit
    SONAX GmbH, Neuburg an der Donau
  2. Mitarbeiter:in im Bereich Medienraumausstattung
    STRABAG BRVZ GMBH, Stuttgart, Wien, Spittal/Drau, Molzbichl, Villach (Österreich)
  3. ERP Berater Finanzen für Infor LN (m/w/d)
    Trox GmbH, Neukirchen-Vluyn
  4. Application Manager (w/m/d)
    ING Deutschland, Frankfurt am Main

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. basierend auf Verkaufszahlen
  2. 219,99€ (mit Vorbesteller-Preisgarantie)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Disney+, Netflix und Prime Video: Das goldene Streamingzeitalter wird zum silbernen
Disney+, Netflix und Prime Video
Das goldene Streamingzeitalter wird zum silbernen

Das aktuelle Jahr hat viele Umbrüche im Streamingmarkt erlebt - und nächstes Jahr geht es weiter. Das wird negative Auswirkungen für Anbieter und Kunden haben.
Eine Analyse von Ingo Pakalski

  1. Netflix-Datenschatz Serien laufen erfolgreich und werden trotzdem eingestellt
  2. Streaming Apple und Paramount könnten Streamingdienste bündeln
  3. Streamingabo Arthaus+ erstmals als App für 3,99 Euro pro Monat

Deutschland-Start vor 20 Jahren: Das Mysterium von Donnie Darko
Deutschland-Start vor 20 Jahren
Das Mysterium von Donnie Darko

Der Science-Fiction-Film Donnie Darko machte Jake Gyllenhaal zum Star. Regisseur Richard Kelly galt als Wunderkind, konnte den Erfolg aber nie wiederholen.
Von Peter Osteried

  1. Die wandernde Erde II Leb wohl, Sonnensystem!
  2. Die Wahrheit ist dort draußen Reboot von Akte X kommt
  3. Carol & the End of the World In 7 Monaten und 13 Tagen geht die Welt unter

Teil 2 unseres Tutorials: Objekte und Variablen in Powershell
Teil 2 unseres Tutorials
Objekte und Variablen in Powershell

Powershell-Tutorial
In unserer Powershell-Einführung mit Übungsblöcken und Lösungsvideos beschäftigen wir uns dieses Mal mit Objekten und Variablen.
Eine Anleitung von Holger Voges

  1. Mit praktischen Übungen und Videos Powershell für Einsteiger - Teil 1