Temat: PostgreSQL i duża baza danych

Wygląda to na dość dużą bazę. Duża baza = duża kasa. Może stać was na Oracle?
220 milionów wierszy na rok to nie tragedia. Należałoby określić przeznaczenie bazy oraz oczekiwany czas odpowiedzi (czyli jak długo może się mielić SELECT).
Co do insertów - będą to pojedyncze inserty czy operacje typu BULK? 220M oddzielnych sesji czy coś bardziej optymalnego?
Jaki jest oczekiwany poziom niezawodności systemu?
Jak długo mają być trzymane dane?
Jesteś pewien, że wystarczy kategoria na produkt? Zastanów się czy produkt nie może należeć do kilku kategorii jednocześnie - późneij może być za późno na zmianę.
Wyszukiwanie danych i ten "swoisty cache"... czy baza nie powinna robić tego sama? Wynajdowanie koła od nowa mija się z celem.
Partycjonowanie (ACCESS predicate oraz klucz do archiwizacji) wydaje się być kluczowym elementem schematu. Oczywiście nie chcesz niczego udziwnionego (jak np. indeksy bitmapowe w Oracle...) a ilość operacji UPDATE należy zminimalizować (jeśli ich nie będzie to super). DELETE też nie wchodzi w grę - logi bazy byłyby zabójcze.
Napisz coś więcej o bazie i jej przeznaczeniu. Jeśli to miałoby być coś w rodzaju wielkiej wspólnej bazy produktów/zakupów na np. allegro - ryzyko utraty danych wydaje się duże a koszt napraw bazy gdy coś padnie też nieprzyjemny.
Czy postgres da radę? Prawie na pewno. Pytanie tylko czy nie lepiej zainwestować w coś co jakby nie patrzeć nadaje się lepiej dla takiej bazy - w drogiego Oracle.

W moim odczuciu "bazy danych" nie zostały zaprojektowane jako najszybsza metoda dostępu do danych - raczej jako elastyczna metoda oferująca łatwy i optymalny dostęp do nich. Od wydajności bazy mamy horyzontalne skalowanie (klastry), macierze raid i inne wynalazki. Ja bym chyba silnie naciskał na Oracle.

Temat: PostgreSQL i duża baza danych

Serdecznie dziękuję wszystkim za odpowiedzi.

Z tego co się orientuję do Klient posiada wsparcie administratora więc od tej strony byłbym raczej spokojny. Sam schemat bazy jest raczej dobrze przemyślany, nie ma żadnej redundancji danych, schemat bazy jest znormalizowany. Indeksy pozakładane, ale tylko te, które faktycznie będę konieczne. Wiem, że ich nadmiar może przynieść skutek odwrotny do zamierzonego.

Jeżeli chodzi o pytania Macieja Wakuli:
1. INSERTy lecą w paczkach - nie są to pojedyncze kwerendy.
2. Dane raczej będą trzymane przez dłuższy okres czasu.
3. Produkt może należeć do kilku kategorii (stąd dodatkowe pole w tabeli pivotu, określające poziom zagłębienia kategorii do budowy ścieżki kategorii).
4. Jeżeli chodzi o Oracle to raczej nie wchodzi to w grę. Z tego co się orientuję to jest to dość droga "zabawka", a wydawanie sporej gotówki na samym początku mogłoby być problemem...

Jeszcze raz wszystkim serdecznie dziękuję za udział w dyskusji.

Temat: PostgreSQL i duża baza danych

Maciej W.:
Wygląda to na dość dużą bazę. Duża baza = duża kasa. Może stać was na Oracle?

Czy postgres da radę? Prawie na pewno. Pytanie tylko czy nie lepiej zainwestować w coś co jakby nie patrzeć nadaje się lepiej dla takiej bazy - w drogiego Oracle.

Ja bym chyba silnie naciskał na Oracle.

Czegoś nie łapię. Czemu uważasz, że Oracle lepiej się nadaje dla takiej bazy, jakieś argumenty masz czy to tylko był taki fajny tekst marketingowy? Z tego co napisałeś wynika, że Oracla znasz, a Postgresa nie, może dlatego piszesz takie głupoty. No ale czekam na argumenty czemu ten Oracle się nadaje lepiej, a Postgres nie.

Temat: PostgreSQL i duża baza danych

A jak ma wyglądać to przedsięwzięcie od strony zapytań ? Bo jeśli chodzi o same inserty itp - no to da radę, czemu nie ... Pliki tekstowe też dadzą radę ;) Ale te dane mają być zbierane do czegoś, a nie tylko do przechowywania ? Mają być na nich potem robione jakieś złożone raporty ? Będą replikowane do osobnych baz raportowych, żeby nie mieszać raportowania z bazą transakcyjną ?
Wydaje mi się, że tego typu kwestie przesądzają o tym, 'czy postgres wystarczy'.
Zerknij na stronkę:
http://wiki.postgresql.org/wiki/Replication,_Clusterin...
i powiedz może, co tam tak naprawdę jeszcze, poza samym Core postgresa możesz potrzebować. Wtedy będzie łatwiej odpowiedzieć.