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

worum es hier (glaube ich) eigentlich geht

  1. Thema

Neues Thema Ansicht wechseln


  1. worum es hier (glaube ich) eigentlich geht

    Autor: tunnelblick 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: tunnelblick 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 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. VARO Energy Germany GmbH, Hamburg
  2. SIGMA-ELEKTRO GmbH, Neustadt an der Weinstraße
  3. Landestalsperrenverwaltung des Freistaates Sachsen, Eibenstock-Neidhardtsthal
  4. Bremer Spirituosen Contor GmbH, Bremen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energiewende: Schafft endlich das Brennstoffzellenauto ab!
Energiewende
Schafft endlich das Brennstoffzellenauto ab!

Sie sind teurer und leistungsschwächer als E-Autos und brauchen dreimal so viel Strom. Der Akku hat gewonnen. Wasserstoff sollte für Chemie benutzt werden.
Ein IMHO von Frank Wunderlich-Pfeiffer

  1. Hyundai Nexo Wasserdampf im Rückspiegel
  2. Brennstoffzellenauto Bayern will 100 Wasserstofftankstellen bauen
  3. Elektromobilität Daimler und Volvo wollen Brennstoffzellen für Lkw entwickeln

PC-Hardware: Das kann DDR5-Arbeitsspeicher
PC-Hardware
Das kann DDR5-Arbeitsspeicher

Vierfache Kapazität, doppelte Geschwindigkeit: Ein Überblick zum DDR5-Speicher für Server und Desktop-PCs.
Ein Bericht von Marc Sauter


    Complex Event Processing: Informationen fast in Echtzeit auswerten
    Complex Event Processing
    Informationen fast in Echtzeit auswerten

    Ob autonomes Fahren, Aktienhandel oder Onlineshopping: Soll das Ergebnis gut sein, müssen Informationen quasi in Echtzeit ausgewertet werden. Eine gute Lösung dafür: CEP.
    Von Boris Mayer

    1. Musik Software generiert Nirvana-Songtexte
    2. mmap Codeanalyse mit sechs Zeilen Bash
    3. Digitale Kultur Demoszene wird finnisches Kulturerbe