C++ Datenbank Umsetung



  • Moin Moin,
    ich wollte eine Hybride In-Memory Key/Value Datenbank entwickeln die Daten im Cache hält, zugleich aber auch auf die Festplatte auslagern kann wenn der Arbeitsspeicher bedarf zu groß wird.
    Meine Idee: Wie Prozessoren Daten in Registern halten und ändern und dann zurück in den RAM speichern. Nur das meine Register der RAM ist und mein RAM die Festplatte. Die Daten werden auch noch solange im RAM behalten bis ein Limit überschritten ist. Dann werden die weiteren Datensätze auf der Festplatte gespeichert und nur im RAM zwischengespeichert und mit zufälligen alten RAM-Datensätzen ausgetauscht (mit der Festplatte).
    An sich funktioniert auch alles perfekt.

    Nur ist meine Frage, wie speichere ich am besten Daten auf der Festplatte?
    Momentan schreibe ich für jeden Datensatz eine eigene Datei mit dem Key als Namen und den Value als Inhalt. Nur irgendwie mag ich diese Methode nicht und sie hat auch ein paar Nachteile(NTFS Limits). Nur gefällt mir der logarithmische Aufwand des NTFS Datensystems (Ist doch O(log n) oder?). In einer Datei will ich nicht alle Daten speichern, da ich dann jedesmal alles einlesen müsste und es beim verändern kompliziert wird. Jemand eine nette Idee zum abspeichern?

    Umgesetzt wird die Datenbank in C++ und als In-Memory speicher wird eine std::map verwendet.

    Lg



  • Hi Mamba,

    wenn Du mit Embarcadero(Borland)-C++Builder arbeitest schau Dir mal das TClientDataSet an. Das dürfte genau das machen wass Du willst.

    Gruß Mümmel



  • Hey muemmel,
    danke erstmal für die Antwort. Ich wollte allerdings alles in C++11 bzw. C++14 selbst schreiben um es so portable wie nur irgendwie möglich zu machen.
    Ich bin gerade nur auf der Suche nach einer netten Idee für einen Datenspeicher Struktur.

    MfG



  • Hi Mamba,

    in dem Buch
    ADO und Delphi
    https://www.amazon.de/ADO-Delphi-CD-ROM-Andreas-Kosch/dp/3935042108
    https://www.ebay-kleinanzeigen.de/s-anzeige/ado-und-delphi/783543037-76-4252
    wird auch sehr gut beschrieben, wie unter Windows über die ADO-Schnittstelle auf Datenbanken zugegriffen werden kann, und selbige auch im RAM present gehalten bzw. auf Platte geschrieben oder von dort gelesen werden können.
    Leider ist das Buch nicht ganz billig 😉 aber hat schon irgendwo seinene Grund warum für diese uralte Schwarte noch Preise von vielfach weit über 100 Euro ausgelobt werden. Aus meiner Sicht das Beste was zu haben ist.
    Die Beispiele sind sicher problemlos auf andere Programmieroberflächen zu übertragen.
    Alternativ noch ADO-Programmierung
    https://www.amazon.de/ADO-Programmierung-m-CD-ROM-David-Sceppa/dp/3860636189/ref=sr_1_1?s=books&ie=UTF8&qid=1519665235&sr=1-1
    Das ist dagegen preislich ein absolutes Schnäppchen, basiert aber auf Basic.

    Gruß Mümmel



  • Danke 🙂
    Gibt es auch irgendwie 'kostenlose' Ideen zu diesen Thema?

    Oder wie machen es denn die klassischen Datenbanken wie MySQL oder Derby?



  • Die "großen" Datenbanken werden mit memory-mapped-files arbeiten und ganze Speicherseiten ein- und ausblenden. Memory mapped files unter Windows.



  • Hi Mamba,

    Mamba schrieb:

    Gibt es auch irgendwie 'kostenlose' Ideen zu diesen Thema?

    Also wenn die 6,69 Euro für das zweite Buch das grundlegende KO-Kriterium sind, solltest Du Dich lieber auf sozialverträgliches Frühableben orientieren, den kostenlos ist in diesem Leben absolut nichts.
    Entscheidend ist meist nicht, ob was kostenlos oder billig ist, sondern ob es preiswert, also sein Geld wert ist.

    Gruß Mümmel



  • Naja, Delphi und ADO... wenn man eine portable C++ Lösung anstrebt sind das schon zwei KO Kriterien, auch wenn man vielleicht Anregungen für die Implementation drin findet.
    Es gibt reichlich Open-Source in-memory Datenbanken, vllt sollte man sich da mal Quelltext ansehen.



  • Hi DocShoe,

    DocShoe schrieb:

    Naja, Delphi und ADO... wenn man eine portable C++ Lösung anstrebt sind das schon zwei KO Kriterien, auch wenn man vielleicht Anregungen für die Implementation drin findet.

    sehe ich nicht unbedingt so, zum einen ist Delphi recht gut nach C++ zu übertragen, und zum anderen ist ADO in Verbindung mit mdb-Datenbanken erst mal die einfache kleine Lösung um sich in die Dinge einzuarbeiten.
    Wenn Schon ein Buch für 6,69 Euro das KO-Kriterium ist, dann bezweifle ich, das Mamba da an Hochleistungs-Serversystemen arbeitet. Das hört sich eher nach mal in die Problematik reinarbeiten an.
    Auch wenn viele Access-Datenbanken nicht als echte Datenbanken ansehen, aber sie haben doch ein paar gewaltige Vorteile für den der sich reinarbeiten will.
    Es ist keinerlei Serverinstallation nötig, die Unterstützung ist durchs Betriebssystem alleine ab XP gegeben. Das Erzeugen von Testdatenbanken ist selbst wenn man kein Access hat mit Excel und ähnlichem problemlos möglich.
    Man kann sich mit wenig Aufwand das Rüstzeug für spätere größere Projekte holen.
    Man steht erst mal nur vor einem Problem, nämlich wie man auf die Datenbank zugreift und wie die entsprechenden Abfragen zu gestalten sind. Es ist nicht nötig, sich auch gleichzeitig noch in die Serverproblematik einzuarbeiten.
    Wenn man damit das entsprechende Rüstzeug erarbeitet hat, dann steht einem bis dahin auch das entsprechende Wissen zur Verfügung, um eingermaßen souverän entscheiden zu können, welche Datenbank es dann im Endeffekt sein soll.

    Gruß Mümmel



  • Hi DocShoe,

    DocShoe schrieb:

    wenn man eine portable C++ Lösung anstrebt

    Ich finde, dieses Thema wird meist arg überbewertet. Für manche Zwecke ist das sicherlich zu beachten. Aber ich würde mal behaupten, dass 90-99 % aller für Windows entwickelten Programme nie auf ein anderes System übertragen werden.
    Wenn ich einen Browser oder was vergleichbares entwickle, dan ist es schon empfehlenswert am Anfang mal zu überlegen, wo der möglicherweise alles laufen könnte.
    Aber fast alles sind entweder kleine Hilfstools oder Bussines-Anwendungen, die auf dem ganz normalen Büro-PC laufen. Die werden nie was anderes als Windows sehen.
    So schön portabilität auch ist, aber sie ist nicht zum Nulltarif zu haben. Sie verursacht Kosten und Mehraufwand und schränkt das Endergebnis ein.
    Wenn ich im Interesse der Portabilität auf der Straße mit nem Geländewagen fahre, dann bin ich zwar nicht auf die Straßen beschränkt, aber dafür weniger schnell und mit höherem Dieselverbrauch unterwegs.
    Genau so ist es, wenn ich portable Programme schreiben will. Wenn ich Windows, Linux und IOx unterstützen will, dann ist das möglich, aber es wird immer ein schielen nach dem kleinsten gemeinsamen Nenner sein.
    Ebenso ist es mit dem Datenbankzugriff. Wenn abzusehen ist, dass das irgendwo beim nicht-edv-affinen 0-8-15-User laufen soll, dann ist eine lösung die ohne installieren geht (Access und ADO) schon mal im Vorteil.
    Spätzestens wenn man mal mit Nutzern zu tun hatte, bei denen man schon glücklich und zufrieden ist, wenn sie denne mal den Rechner und sogar den Netzschalter gefunden haben, und die per Fernbetreuung übers Telefon durch die Stolperfallen eine Programmdownloads und das Entpacken eines Zips lotsen muss, ist man froh und glücklich, dass man nicht erst noch eine Serverinstallation über die Bühne bringen muss.
    Mit guten Instalationsroutinen geht das zwar auch mittlerweile einfacher, aber wenn irgendwas nicht klappt, dann ist man absolut der letzteder Mohikaner. Muss man nicht unbedingt haben.
    Ein Programm ist immer dann optimal, wenn es genau das kann, was es soll, das aber dann so perfekt wie möglich (und natürlich auch so wartungsfreundlich wie möglich).

    Gruß Mümmel



  • Hey,
    danke für die ganzen Antworten 🙂
    Die Datenbank soll aus vielen Gründen in nativen C++ geschrieben werden ohne externe Bibliotheken. Zum einen soll ein Server dadurch entstehen der unter Linux und Windows als Backend dient uns sehr viele Anfragen bearbeiten können muss. Zum anderen soll es auch eine Datenbank werden intern für neue Projekte die nicht unbedingt einen Server als Backend brauchen, z.B. Client-Programme die viele Daten speichern müssen. Da ist es immer schön ne Ready to Run Datenbank da zu haben die man einfach einbinden kann.

    Achja, danke 🙂 Die memory-mapped files werde ich mir mal angucken.

    LG



  • Mamba schrieb:

    Da ist es immer schön ne Ready to Run Datenbank da zu haben die man einfach einbinden kann.

    Weswegen der Herrgott ja auch SQLite erfunden hat.
    Aber schreib ruhig selbst was. Sei bloss nicht enttäuscht wenn du nicht an die Performance und/oder Robustheit von fertigen Lösungen ran kommst.



  • oder

    http://rocksdb.org/ von Facebook

    https://github.com/google/leveldb von Google

    https://upscaledb.com/

    und natürlich auch non-key value/pair sqlite

    und,und,und

    es gibt so vieles portables an dem schon lange entwickelt wird und sehr gut ist - du kannst ja deine Anforderung (die DB ist ja nur ein Speicher) mal über die 3 mappen und dann schauen ob deinen eigenen Lösung viel performanter ist

    @muemmel

    er spricht explizit von Key/Value Pair DB - damit ist ADO egal ob portabel oder nicht doch auch schon komplett raus, oder was meinst du? wenn es portabel sein soll und nicht unbedingt Key/Value-Pair ist sqlite wohl die bessere Wahl - bei einer Inprocess DB bleibt bei ADO wohl auch nur die Compact Variante



  • und wenn du:
    nicht beurteilen kannst ob sie portabel genug sind,
    sie deine performanz-anforderungen erfüllen,
    das kompilieren, linke zu aufwendig ist

    du also kein Zeit oder Lust hast würde ich 2-3 mal darüber nachdenken einfach mal eine DB zu bauen, bin ja mal gespannt wie du dann die z.B. nicht-std-C++ konforme memorymapped file implementierung machst - damit du so wunder-portabel bist

    das ist bei den meisten der obigen DBs sauber und gut gelöst und tausendfach im Einsatz



  • Wow, that escalated quickly..

    Ich war lediglich auf Ideensuche nach ner Datenverwaltung für die Festplatte.
    Wenn ich komplett fertige Lösungen wie SQLLite nehmen will, dann würde ich doch keine Datenbank selbst entwickeln wollen. Natürlich will ich hier keine Produktiveinheit für Facebook entwickeln. Aber ich wollte 'just for fun' etwas eigenes entwickeln, welches natürlich auch eingesetzt werden soll bei anderen Projekten.
    Die memory mapped files kann ich offensichtlich wohl nicht so einfach benutzen.

    Deshalb bin ich immer noch auf Ideensuche wie man nett Dateien in einer Art Baum benutzen kann. Ich würde auch liebend gerne komplette Datenstrukturen wie Bäume selbst bauen.
    Einfach eine fertige Lösung zu benutzen, bildet jetzt auch nicht sonderlich weiter.



  • Mamba schrieb:

    Aber ich wollte 'just for fun'

    Dann schreib das nächstes mal gleich dazu.

    Mamba schrieb:

    Deshalb bin ich immer noch auf Ideensuche wie man nett Dateien in einer Art Baum benutzen kann.

    "In" einer Art Baum? Nennt sich File-System. Willst du das auch selbst programmieren?

    Mamba schrieb:

    Ich würde auch liebend gerne komplette Datenstrukturen wie Bäume selbst bauen.

    Dann mach mal.



  • ps:

    Mamba schrieb:

    Nur gefällt mir der logarithmische Aufwand des NTFS Datensystems (Ist doch O(log n) oder?). In einer Datei will ich nicht alle Daten speichern, da ich dann jedesmal alles einlesen müsste und es beim verändern kompliziert wird. Jemand eine nette Idee zum abspeichern?

    Das macht man üblicherweise mit B-Bäumen. (Gibt auch einige Derivate z.B. B+, B*.)
    https://en.wikipedia.org/wiki/B-tree