Reprezentowanie rzadkich danych w PostgreSQL

Zakładam, że myślisz o rzadkich macierzach z kontekstu matematycznego:http://en.wikipedia. org/wiki/Sparse_matrix (Opisane tam techniki przechowywania dotyczą przechowywania w pamięci (szybkie operacje arytmetyczne), a nie trwałego przechowywania (niskie zużycie dysku).

Ponieważ zazwyczaj działa się na tych macierzach po stronie klienta, a nie po stronie serwera, najlepszym wyborem jest SQL-ARRAY[]!

Pytanie jak wykorzystać rzadkość matrycy? Oto wyniki niektórych badań.

Konfiguracja:

Postgres 8.4
Macierze z 400*400 elementami o podwójnej precyzji (8 bajtów) --> 1,28 MB surowego rozmiaru na macierz
33% elementów niezerowych --> 427kiB efektywny rozmiar na macierz
uśredniona przy użyciu ~1000 różnych losowo wypełnionych macierzy

Konkurencyjne metody:

Polegaj na automatycznym kompresja po stronie serwera kolumn z opcją SET STORAGE MAIN lub EXTENDED.
Przechowuj tylko niezerowe elementy oraz bitmapę (bit varying(xx) ) opisujące, gdzie zlokalizować niezerowe elementy w macierzy. (Jedna podwójna precyzja jest 64 razy większa niż jeden bit. Teoretycznie (ignorując koszty ogólne) ta metoda powinna być ulepszeniem, jeśli <=98% jest niezerowe;-).) Kompresja po stronie serwera jest włączona.
Zamień zera w macierzy z NULL . (RDBMS są bardzo skuteczne w przechowywaniu wartości NULL.) Aktywowana jest kompresja po stronie serwera.

(Indeksowanie niezerowych elementów przy użyciu drugiej tablicy indeksowej [] nie jest zbyt obiecujące i dlatego nie zostało przetestowane.)

Wyniki:

Automatyczna kompresja
- brak dodatkowych wysiłków wdrożeniowych
- brak zmniejszonego ruchu sieciowego
- minimalne obciążenie kompresyjne
- pamięć trwała =39% nieprzetworzonego rozmiaru
Mapa bitowa
- dopuszczalny wysiłek wdrożeniowy
- ruch w sieci nieznacznie spadł; zależny od rzadkości
- Pamięć trwała =33,9% nieprzetworzonego rozmiaru
Zastąp zera wartościami NULL
- trochę wysiłku wdrożeniowego (API musi wiedzieć, gdzie i jak ustawić wartości NULL w tablicy [] podczas konstruowania zapytania INSERT)
- brak zmian w ruchu sieciowym
- Pamięć trwała =35% nieprzetworzonego rozmiaru

Wniosek:Zacznij od parametru EXTENDED/MAIN storage. Jeśli masz trochę wolnego czasu, sprawdź swoje dane i użyj mojej konfiguracji testowej z twoim poziomem rzadkości. Ale efekt może być niższy niż się spodziewasz.

Proponuję zawsze używać serializacji macierzy (np. Rząd-główny porządek) plus dwie kolumny liczb całkowitych dla wymiarów macierzy NxM. Ponieważ większość interfejsów API używa tekstowego SQL, oszczędzasz dużo ruchu sieciowego i pamięci klienta dla zagnieżdżonych „TABLICA[TABLICA[..], TABLICA[..], TABLICA[..], TABLICA[..], ..]” !!!

Teba

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)
);

Wstaw te same macierze do wszystkich tabel. Konkretne dane zależą od konkretnej tabeli. Nie zmieniaj danych po stronie serwera ze względu na nieużywane, ale przydzielone strony. Lub zrób ODKURZACZ.

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;