![]() |
Re: Datei > 500mb vollständig in RAM laden
Jo stimmt. Ich hab mich nicht lange genug mit den verschienden DBMS System auseinander gesetzt.
Wieviele davon gibt es? Und wieviel zeit bräucht ich um mich mit gründlich einzuarbeiten? Um dann auch noch das Beste für mich herraus zussuchen. Ich werde Deine Hinweise berücksichtigen und schaue ob ich mit Firebird besseres Ergebnisse erziele. Die potenzierung erfogt natürlich geteilt. zB auf 1 GB pro Datei. [AM_RANDE] Bei 1 TB local zu Verfügung könnte ich auch einiges aufnehmen. Desweiten habe 2 Gb drinne, noch eine Bank frei, und noch aufrüstbar dank 64MB Grafik (muss aber erst warten wegen dem neuen DualChanel fähigen Bord) Falls das jemand wissen mag. :mrgreen: [/AM_RANDE] Sicherlich wird es nur ein kläglicher Versuch bleiben wenn ich es gegen ein "ordentliches" DBMS vergleiche. Ist auch ehr nur der als Station auf dem Weg zu der Erfahrung gedacht, von der Du sprichst. |
Re: Datei > 500mb vollständig in RAM laden
Selbst wenn man auf ein DBMS verzichten will, würde ich nie auf die Idee kommen, die komplette "Datenbank" im Speicher zu halten. in diesem Fall würde ich nur den Index (als Binärbaum o.ä.) im Speicher halten, welcher dann auf die Recordnummern in der Datei verweist. Diese würden sequentiell geschrieben und ein Ordnung nur per Index erreicht, welcher zusätzlich zum Speicher spätestens beim beenden des Programmes auf Platte gesichert werden sollte.
Aber ich sehe es wie Elvis: Ein solche Lösung würde viel mehr Arbeit als die Einarbeitung in ein DBMS bedeuten und wohl nicht ansatzweise an die Performance herankommen. |
Re: Datei > 500mb vollständig in RAM laden
Ist meine Idee im Hinterkopf. :zwinker:
nur ist mir noch nicht ganz klar wie ich so einen Index machen könnte. Muss ja am Ende auf eine mathematische Formel beruhen.... und wenn die dann halbwegs funzen sollte. werde ich die Dateien sicher nicht mehr im Ram halten. Wo sie ohne hin nur geladen werden wenn Sie gebraucht würden. |
Re: Datei > 500mb vollständig in RAM laden
Als Index würde sich ein Binärbaum eigenen (dieses Problem hat wohl fast jeder hier in der Schule/Uni usw schon mal Lösen dürfen)
|
Re: Datei > 500mb vollständig in RAM laden
Dann sollte sich da ja was finden lassen (läuft ja auch grad noch ein Thread zu dem Thema)
|
Re: Datei > 500mb vollständig in RAM laden
Zitat:
Ein DBS macht aber eine ganze Menge mehr, da gibt es gleich einen Cache mit Datensätzen, auf die (vermutlich) demnächst zugegriffen wird. Das heißt, dass nicht die ganze Datei, aber relevante Teile schon im RAM landen. Die benötigte Verdrängungsstrategie, die Datensicherheit, Transaktionen uvm. bringen die meisten (zumindestens die bekannten) dann auch gleich mit. Da kann auf DB2, Oracle, PostgreSql, MySql, MsSql und natürlich Firebird verwiesen werden. Die dürften alle besser skalieren, schneller/effizienter arbeiten, mehr Konsistenz und Sicherheit garantieren als es eine eigene Lösung tut! Da arbeiten einfach viele Leute seit einem Weilchen dran, allein die Nebenläufigkeit dürfte schon ein hartes Stück Arbeit für eine Person sein! Es macht einfach keinen Sinn auf diese (guten!) Lösungen zu gunsten einer eigenen zu verzichten (und sorry, schon gar nicht wenn man dazu einfach versucht alles im Speicher zu halten!). |
Re: Datei > 500mb vollständig in RAM laden
Ich geb Dir durchweg Recht, Du angeblich Unwissender :lol:
|
Re: Datei > 500mb vollständig in RAM laden
Zitat:
|
Re: Datei > 500mb vollständig in RAM laden
Zitat:
Klar, ein DBS lädt eben nicht nur den Index in den Speicher, sondern hält auch einzelne Seiten vor, aber das ist ja nicht gerade ein Nachteil. Anders gesagt, wenn man die Funktionalität eines DBS benötigt/nutzen will (und so habe ich Harry M. verstanden), dann ist es manchmal das klügste zu einem DBS zu greifen :wink: |
Re: Datei > 500mb vollständig in RAM laden
Zitat:
![]() Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:42 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz