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!

Joiny nie będą tak bardzo obciążały bazy jeżeli będą to odpowiednie joiny dostosowane do potrzeb (inner join np), dodatkowo odpowiednie klucze. W przypadku gdy danych będzie ogromna ilosć warto by było się zastanowić nad dobrym serwerem dedykowanym (z procesorem 4 lub więcej rdzeniowym), gdzie przy takich maszynach postgres sprawdza się lepiej.

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.



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.

Może ustalmy fakty. Danych nie będzie dużo. Zazwyczaj jest tak, że tabela zawiera kilkadziesiąt kolumn i kilka tysięcy rekordów (przy większości małych projektów). Rozmawiamy o sytuacji nieco to równoważaącej czyli kilkaset do kilku tysięcy rekordów i około 250 kolumn.

E, to na moje oko urelacjonowienie bazy będzie ledwo odczuwalne.

Kilka tysięcy rekordów, to jest nic. (oczywiście przy odpowiednio założonych indeksach)