[PostgreSQL] Wydajność tabeli z bardzo dużą ilością kolumn, Pytanie WYŁĄCZNIE do doświadczonych programistów Opcje

[The Night Shadow]

Witam,

Czy bazy danych PostgreSQL dobrze sobie radzą z wydajnością w przypadku utworzenia tabeli o bardzo dużej ilości kolumn (nawet do 200-250)?

Mamy zbiór pewnych obiektów, które mają BARDZO dużo różnego rodzaju właściwości. Te właściwości mają umożliwiać szybkie filtrowanie danych. Właściwości nie dają się łączyć w pary itp. stąd konieczność korzystania z osobnych pól dla każdej z nich. Powstała teoria mówiąca, iż najlepiej jest rozdzielić takie dane do kilku tabel. W pierwszej tabeli trzymać właściwości z danej grupy właściwosci, w drugiej z drugiej grupy właściwości itd. Sęk w tym, że w momencie przeszukiwania instrukcje JOIN będą bardzo obciązały bazę.

Jestem zdania, że w sytuacji, w której mamy do czynienia z integralnymi właściwościami należy to zbudować na jednej tabeli o bardzo dużej ilości kolumn.

Uproszę. W tabeli z użytkownikami mamy imię i nazwisko oraz adres. Nie rozdzielamy tego na dwie tabele, bo w przypadku przeszukiwania takie rozwiązanie będzie stanowiło nie lada problem. Podobna sytuacja tylko na większą skalę dotyczy sytuacji wyżej opisanej tabeli.

Niech mnie ktoś poprawi jeżeli się mylę.

Pozdrawiam!

[erix]

W pierwszej tabeli trzymać właściwości z danej grupy właściwosci, w drugiej z drugiej grupy właściwości itd. Sęk w tym, że w momencie przeszukiwania instrukcje JOIN będą bardzo obciązały bazę.

Powiem to tak - wszystko naprawdę zależy od sytuacji i trzeba by było zrobić odpowiedni benchmark z uwzględnieniem indeksów i tych obu przypadków.

Powstała teoria mówiąca, iż najlepiej jest rozdzielić takie dane do kilku tabel.

Jestem zdania, że w sytuacji, w której mamy do czynienia z integralnymi właściwościami należy to zbudować na jednej tabeli o bardzo dużej ilości kolumn.

Ok, ale pozostaje jeszcze kwestia skalowalności aplikacji. Jeśli jest to oprogramowanie, które nie będzie za bardzo rozwijane i tabela jest wykorzystywana tylko w tym jednym, konkretnym celu, to wal wszystko do jednej. Ale 100% się tego potwierdzić w ciemno nie da -> benchmark to podstawa, bo każda sytuacja jest inna.

Problemy zaczynają się wtedy, gdy tymi cechami trzeba zarządzać - wtedy trzeba by było zrobić bodajże pivot (zmienić kolumny na połączenia relacyjne z obiektami). Fakt, nieco to zwolni, ale poprawi się skalowalność aplikacji oraz przenośność. Nawet patrząc z poziomu systemu plików - mniej kolumn -> głowica ma mniej przeskoków między danymi na dysku. Dodawanie/usuwanie kolejnej kolumny dla wszystkich rekordów będzie dość uciążliwe czasowo niż manipulacja rekordem będącym w relacji.

Poza tym, może wystarczyłoby po prostu odpowiednio cache'ować dane?

Może jeszcze za wiele nie widziałem, ale raczej stawia się na relacyjność w bazach niż na pakowanie wszystkiego do jednej tabeli.