12.04.2022, 21:41
Also ich schreib mal provozierend ob ich die Daten als Dump aus der DB sichern muss oder direkt aus dem Filesystem. Speicherplatz brauch beides. :-) Und wenn man ein Copy-On-Write Filesystem wie Btrfs benutzt kann man Snapshots recht einfach erstellen. Beim ZFS soll es bei der Anwendung unter Linux lizenzrechtliche Probleme geben.
https://de.wikipedia.org/wiki/ZFS_(Dateisystem)
Abschnitt Weiterentwicklung:
"Eine direkte Unterstützung innerhalb des Linux-Kernels ist aus Lizenzgründen problematisch,[20] daher gibt es keine in die offiziellen Kernelquellen integrierte Linux-Implementierung.[21] "
Ok, zugegebener Maßen habe ich mit Datenbanken die GB Grössen erreichen noch nichts zu tun gehabt. Messwerte die ich bisher in einer DB gespeichert habe, brauchten nicht so viel Platz. Allerdings sehe ich einen Stolperstein wenn der DB Dump nur als eine große Datei gespeichert wird. das könnte je nach Filesystem Probleme geben. Das ließe sich aber auch umgehen, wenn man den Dump Befehl mit einem Packer über eine Pipe verknüpft. Dann könnte der Dump zum Einen gleich gepackt werden. Zum Anderen könnte der Packer die gepackten Daten auf mehrere Files verteilen. Nur ein erster Gedanke, das müsste ich auch erst noch verifizieren.
Soweit erstmal die Gedankenspiele. Aber der Punkt der Deduplizierung ist nicht wegzudiskutieren. Allerdings müßte die meiner Meinung nach ohne FSAsset dann schon in der Datenbank passieren und nicht erst im Dump. Allerdings sind Gedanken in dieser Richtung mühsig. Denn im Umkehrschluss des folgenden Zitats, gibt es anscheinend in der DB genau diese Deduplizierung nicht, sonst würde das ja in Bezug auf FSAsset nicht so betont werden.
http://opensimulator.org/wiki/FSAssets_Service:
"FSAssets is intended for grids where the size of the database is expected to exceed 50GB. This option will save the assets to the file system as opposed to the default service which stores assets as blobs in the database. This option also provides deduplication abilities, each asset is hashed when it is received for storage and if the asset already exists, the asset service will link to the existing file rather than store two copies."
!!! "... This option also provides deduplication abilities, ...."
Ausserdem sehe ich an dem Wert 50GB im Zitat, das bereits das Swissgrid, wenn man meinen letzten Post heranzieht, nicht mehr als kleines Grid zu werten ist. Also du wirst schon recht haben Bart, daß die Bedingungen unter denen FSAsset seine Stärken ausspielt schnell erreicht sind. Ok, Ihr habt mich überzeugt, ein weiterer Punkt der es wert ist, ausprobiert zu werden.
https://de.wikipedia.org/wiki/ZFS_(Dateisystem)
Abschnitt Weiterentwicklung:
"Eine direkte Unterstützung innerhalb des Linux-Kernels ist aus Lizenzgründen problematisch,[20] daher gibt es keine in die offiziellen Kernelquellen integrierte Linux-Implementierung.[21] "
Ok, zugegebener Maßen habe ich mit Datenbanken die GB Grössen erreichen noch nichts zu tun gehabt. Messwerte die ich bisher in einer DB gespeichert habe, brauchten nicht so viel Platz. Allerdings sehe ich einen Stolperstein wenn der DB Dump nur als eine große Datei gespeichert wird. das könnte je nach Filesystem Probleme geben. Das ließe sich aber auch umgehen, wenn man den Dump Befehl mit einem Packer über eine Pipe verknüpft. Dann könnte der Dump zum Einen gleich gepackt werden. Zum Anderen könnte der Packer die gepackten Daten auf mehrere Files verteilen. Nur ein erster Gedanke, das müsste ich auch erst noch verifizieren.
Soweit erstmal die Gedankenspiele. Aber der Punkt der Deduplizierung ist nicht wegzudiskutieren. Allerdings müßte die meiner Meinung nach ohne FSAsset dann schon in der Datenbank passieren und nicht erst im Dump. Allerdings sind Gedanken in dieser Richtung mühsig. Denn im Umkehrschluss des folgenden Zitats, gibt es anscheinend in der DB genau diese Deduplizierung nicht, sonst würde das ja in Bezug auf FSAsset nicht so betont werden.
http://opensimulator.org/wiki/FSAssets_Service:
"FSAssets is intended for grids where the size of the database is expected to exceed 50GB. This option will save the assets to the file system as opposed to the default service which stores assets as blobs in the database. This option also provides deduplication abilities, each asset is hashed when it is received for storage and if the asset already exists, the asset service will link to the existing file rather than store two copies."
!!! "... This option also provides deduplication abilities, ...."
Ausserdem sehe ich an dem Wert 50GB im Zitat, das bereits das Swissgrid, wenn man meinen letzten Post heranzieht, nicht mehr als kleines Grid zu werten ist. Also du wirst schon recht haben Bart, daß die Bedingungen unter denen FSAsset seine Stärken ausspielt schnell erreicht sind. Ok, Ihr habt mich überzeugt, ein weiterer Punkt der es wert ist, ausprobiert zu werden.
Mein Heimatgrid: https://swissgrid.opensim.ch