NTFS compression - Datenbank

Re(9): NTFS compression - Datenbank

mko — Mon, 06 Mar 2017 23:08:13 GMT

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

https://www.postgresql.org/docs/current/static/datatype-character.html

Re(8): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 19:33:29 GMT

ah, da greift dann TOAST oder?

Re(7): NTFS compression - Datenbank

mko — Mon, 06 Mar 2017 19:21:43 GMT

paar werte sind noch text statt sinnvoll beschränkter char längen.

Das ist bei PostgreSQL nicht notwendig.

Re(6): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 19:01:26 GMT

paar werte sind noch text statt sinnvoll beschränkter char längen. aber hauptsächlich sinds bigint bzw doubles, und fast keine null werte

Re(5): NTFS compression - Datenbank

ZombyKillah — Mon, 06 Mar 2017 18:55:59 GMT

Also wenn sich deine Datenbank so stark komprimieren lässt werden viele Werte wiederholt oder ohne Inhalt gespeichert ...

Re(4): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 14:38:54 GMT

*headbang*
offensichtlich verringert er sich aber so nicht, sondern....

Drum war ja meine Frage ob es so ist oder nicht Bin mir ja nicht sicher obs daran liegt

Edit:
OK, es liegt dran. Bin grad beim decompressen und der freie Speicher wächst stetig

bleibt nur, zu schauen, ob man die Daten an sich reduzieren kann (BLOBs),

Nicht wirklich

Ich miet mir jetzt mal ne HDD dazu und schieb den Tablespace rüber um zu sehen wie die Performance unkomprimiert, dafür auf HDD ist, wenn das langt dann bin ich auch ausm Schneider (die 2*2TB Enterprise SAS kostet das selbe wie die derzeitigen 2*240GB SSD)

Re(4): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 14:38:54 GMT

*headbang*
offensichtlich verringert er sich aber so nicht, sondern....

Drum war ja meine Frage ob es so ist oder nicht Bin mir ja nicht sicher obs daran liegt

bleibt nur, zu schauen, ob man die Daten an sich reduzieren kann (BLOBs),

Re(4): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 14:38:54 GMT

*headbang*
offensichtlich verringert er sich aber so nicht, sondern....

Drum war ja meine Frage ob es so ist oder nicht

bleibt nur, zu schauen, ob man die Daten an sich reduzieren kann (BLOBs),

Re(3): NTFS compression - Datenbank

user86060 — Mon, 06 Mar 2017 14:36:29 GMT

Was spricht dagegen, die DB NICHT komprimiert abzulegen?

Der Speicherbedarf

*headbang*

offensichtlich verringert er sich aber so nicht, sondern....

bleibt nur, zu schauen, ob man die Daten an sich reduzieren kann (BLOBs), Tuningmaßnahmen die das beobachtete Verhalten reduzieren oder ob Postgres unter einem anderen OS/Filesystem sich anders verhält... Leistung gibt es bei DB halt nicht umsonst.

Re(2): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 13:58:30 GMT

Was spricht dagegen, die DB NICHT komprimiert abzulegen?

Der Speicherbedarf

Na, bin eh schon am Überlegen, eine HDD dazuzumieten und die Daten zu partitionieren, allerdings sind das natürlich wieder monatliche Kosten (no na). Ist ein bislang defizitäres Freizeitprojekt (abgesehen davon dass ich dabei sehr viel lerne, was mein Hauptziel bei dem Ganzen ist)

Re(2): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 13:58:30 GMT

Was spricht dagegen, die DB NICHT komprimiert abzulegen?

Der Speicherbedarf

Na, bin eh schon am Überlegen, eine SSD dazuzumieten und die Daten zu partitionieren, allerdings sind das natürlich wieder monatliche Kosten (no na). Ist ein bislang defizitäres Freizeitprojekt

Re(2): NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 13:58:30 GMT

Was spricht dagegen, die DB NICHT komprimiert abzulegen?

Re: NTFS compression - Datenbank

user86060 — Mon, 06 Mar 2017 13:56:04 GMT

AFAIR arbeitet die NTFS-Kompression blockbasiert = wenn von 16 Blöcken mindestens einer eingespart wird, dann wird das auch gemacht.
File-basiert ... daß sich Kompression gerade bei großen Dateien rentieren wird, ist denen auch klar, daß sich da jedes System mittelfristig aufhängen würde, von der nochmals ausufernden Fragmentierung ganz abgesehen.

Ich find aber nirgends nennenswerte temporäre Dateien.

ich tippe mal, daß da transparent alternate streams oder anderweitig unsichtbare Bereiche reserviert werden, sobald rw-Zugriff darauf geöffnet wird, anstelle von Tempfiles - gibt (Cmdline-)Tools, die die anzeigen -> bissel suchen.

Was spricht dagegen, die DB NICHT komprimiert abzulegen?

NTFS compression - Datenbank

zeddicus — Mon, 06 Mar 2017 12:39:43 GMT

Mahlzeit,

mal eine Frage. Wenn ich jetzt Beispielsweise eine Postgresql Datenbank in ein NTFS komprimiertes Directory lege, wird dann bei jedem einzelnen read/write transparent die (de)komprimierung ausgeführt, oder würde sich Windows die Datenbank generell temporär entpacken und damit arbeiten?

Ich frag deshalb, weil ich das gemacht hab, und jetzt ein gewisses Verhalten meines Servers nicht nachvollziehen kann:
- Wenn ich ihn neu starte dann hab ich ca. 110GB frei. Sobald er ein wenig läuft (inklusive Postgres DB + IIS) sind nur mehr 16GB frei. Ich find aber nirgends nennenswerte temporäre Dateien. Das einzige wie ich es mir erklären könnte wär eben das entpacken der DB (106GB, 46 on disk), und von ein paar anderen komprimierten Ordnern...