ich Sie gehe davon sind von schwach besetzte Matrizen aus mathematischen Kontext zu denken: (schnelle Rechenoperation), nicht persistenten Speicher (niedrige Festplattennutzung http://en.wikipedia.org/wiki/Sparse_matrix (Die Speicherung beschriebenen Techniken gibt es für Speicher).)
Da man diese Matrizen normalerweise auf der Clientseite und nicht auf der Serverseite bearbeitet, ist ein SQL-ARRAY [] die beste Wahl!
Die Frage ist, wie man die Sparsity der Matrix ausnutzt? Hier die Ergebnisse einiger Untersuchungen.
Setup:
- Postgres 8.4
- Matrices w/400 * 400 Elemente in doppelter Genauigkeit (8 Bytes) -> 1.28MiB Rohgröße pro Matrix
- 33% Nicht-Null-Elemente - -> 427kiB effektive Größe pro Matrix
- gemittelt unter Verwendung von ~ 1000 verschiedene zufällig besiedelten Matrizes
Konkurrierende Methoden:
- Verlass auf die automatischen Serverseite Kompression von Spalten mit SET STORAGE MAIN oder verlängert.
- Nur die Nicht-Null-Elemente plus eine Bitmap (
bit varying(xx)) speichern, die beschreibt, wo die Nicht-Null-Elemente in der Matrix zu finden sind. (Eine doppelte Genauigkeit ist 64 mal größer als ein Bit. In der Theorie (Overheads ignorierend) sollte diese Methode eine Verbesserung sein, wenn < = 98% nicht Null sind ;-).) Serverseitige Komprimierung ist aktiviert.
- Ersetzen die Nullen in der Matrix mit Null. (Die RDBMS sind sehr effektiv beim Speichern von NULL-Werten.) Serverseitige Komprimierung ist aktiviert.
(Indizierung von Nicht-Null-Elemente einen zweiten Index-ARRAY [] ist nicht sehr vielversprechend und daher nicht geprüft werden.)
Ergebnisse:
- Automatische Kompression
- keine zusätzlichen Implementierungsanstrengungen
- kein reduzierter Netzwerkverkehr
- minimal Overhead Kompression
- persistente Speicher = 39% des Ausgangsgröße
- Bitmap
- akzeptablen Implementierungsaufwand
- Netzwerkverkehr leicht verringert; abhängig von sparsity
- persistenten Speicher = 33,9% des Ausgangsgröße
- ersetzen Nullen mit NULLs
- einige Implementierungsaufwand (API wissen muss, wo und wie die NULL-Werte setzen in das ARRAY [] beim Erstellen der INSERT-Abfrage)
- keine Änderung im Netzwerkverkehr
- persistenter Speicher = 35% th e Rohgröße
Fazit: Mit dem erweiterten/MAIN Speicherparameter starten . Wenn Sie etwas Freizeit haben, untersuchen Sie Ihre Daten und verwenden Sie mein Test-Setup mit Ihrem Seltenheitswert. Aber der Effekt ist möglicherweise niedriger als erwartet.
Ich empfehle immer die Matrix-Serialisierung (z. B. Row-Dur-Reihenfolge) plus zwei ganzzahlige Spalten für die Matrix-Dimensionen NxM zu verwenden. Da die meisten APIs textuellen SQL verwenden, speichern Sie viel Netzwerkverkehr und Clientspeicher für verschachtelte "ARRAY [ARRAY [..], ARRAY [..], ARRAY [..], ARRAY [..], ..)" !!!
Tebas
CREATE TABLE _testschema.matrix_dense
(
matdata double precision[]
);
ALTER TABLE _testschema.matrix_dense ALTER COLUMN matdata SET STORAGE EXTERN;
CREATE TABLE _testschema.matrix_sparse_autocompressed
(
matdata double precision[]
);
CREATE TABLE _testschema.matrix_sparse_bitmap
(
matdata double precision[]
bitmap bit varying(8000000)
);
Legen Sie die gleichen Matrizen in allen Tabellen. Die konkreten Daten hängen von der bestimmten Tabelle ab. Ändern Sie die Daten auf der Serverseite nicht aufgrund nicht verwendeter, aber zugewiesener Seiten. Oder mach einen VACUUM.
SELECT
pg_total_relation_size('_testschema.matrix_dense') AS dense,
pg_total_relation_size('_testschema.matrix_sparse_autocompressed') AS autocompressed,
pg_total_relation_size('_testschema.matrix_sparse_bitmap') AS bitmap;
Sie könnten auch ein 'Feature' TYPE AS Feature-Name VARCHAR, Feature-Wert VARCHAR (oder was immer der Wert sein soll) erstellen und ein FEATURES-Feld des Typs Feature [] zu Ihrer Primärtabelle hinzufügen. – MkV
Warum nennst du EAV ein "Anti-Pattern"? Googeln zeigt, dass dies eine allgemeine Beschreibung von EAV ist (üblicherweise abschätzig verwendet), aber niemand scheint zu erklären, warum. Es scheint viele gültige Fälle zu geben, in denen Datenbanken spärliche Daten wie das medizinische Feld speichern müssen, wodurch EAV zu einem geeigneten "Muster" wird. – Cerin
Es beseitigt alle Vorteile der Datenbank, Zeilen-Level-Einschränkungen und referenzielle Integrität und macht es schwierig, eine einzelne Zeile für eine einzelne Entität zurückzugeben. – MkV