[PostgreSQL] =?ISO-8859-2?Q?Du=BFa?= baza danych
Andrzej Nakonieczny - 10-08-2007 00:00
[PostgreSQL] =?ISO-8859-2?Q?Du=BFa?= baza danych
Witam
Zastanawiam się nad możliwościami PostgreSQL w udostępnianiu dużych
(ogromnych?) baz danych. _Pomijam_ samą sensowność wykorzystania go w
taki sposób, nie mam na to żadnego wpływu, próbuję się skupić wyłącznie
na możliwych problemach jakie mogłyby się pojawić przy próbie
uruchomienia takiej bazy.
Powiedzmy, że potrzebuję umieścić w bazie x milionów plików, każdy o
wielkości do kilku megabajtów. Jak łatwo policzyć tabela taka mogła by
osiągnąć rozmiary x terabajtów. Spoglądając na strony projektu można
przeczytać, że PostgreSQL obsługuje tabele o wielkości do 32 TB więc to
powinno być wystarczające. Wcześniejsze ograniczenie - o ile dobrze
pamiętam - wynosiło 16 TB. Czy to ograniczenie związane było (wciąż
jest związane?) z samym PostgreSQLem czy też raczej to problem
wielkości pojedynczej partycji na której znajduje się tabela?
Jeśli - przypuśćmy - sam system ograniczy możliwość stworzenia tak
dużego zasobu (powiedzmy powyżej 8 albo 16 TB) to czy jednak istnieje
możliwość obsłużenia tak dużej bazy danych? O ile w przypadku innych
baz (rozwiązania komercyjne) możliwe jest stworzenie pojedynczej bazy
na kilku przestrzeniach (w postaci partycji/plików) o tyle w PostgreSQL
chyba nie można rozłożyć tabeli na kilka tablespace'ów? A może
rozwiązaniem byłoby partycjonowanie tabel przy czym każda z takich
tabel umieszczona byłaby na osobnym tablespace'ie?
Przy okazji tak wielkich baz rodzi się od razu drugie pytanie - jak to
poprawnie backupować? Zrzucenie dumpa z takiej bazy danych odpada.
Jakieś inne rozsądne możliwości, które nie zabiją wydajności samej
bazy? Nie ukrywam, że jedyną możliwością mógłby być backup na poziomie
systemu (Linux)...
Sama baza będzie wykorzystywana wyłącznie do dodawania kolejnych
rekordów, rzadko do wyszukania po zindeksowanym unikalnym polu.
Pozdrawiam,
Andrzej
hubert depesz lubaczewski - 11-08-2007 00:02
Dnia 09.08.2007 Andrzej Nakonieczny <dzemik@pingwin.invalid> napisał/a:
> pamiętam - wynosiło 16 TB. Czy to ograniczenie związane było (wciąż
> jest związane?) z samym PostgreSQLem czy też raczej to problem
> wielkości pojedynczej partycji na której znajduje się tabela?
powiem szczerze, że nie wiem z czym związane jest to ograniczenie.
> na kilku przestrzeniach (w postaci partycji/plików) o tyle w PostgreSQL
> chyba nie można rozłożyć tabeli na kilka tablespace'ów? A może
> rozwiązaniem byłoby partycjonowanie tabel przy czym każda z takich
> tabel umieszczona byłaby na osobnym tablespace'ie?
to wydaje się być akceptowalne. tyle, że nie wiem czemu chcesz rozrzucać
dane po różnych tablespace'ach.
co chcesz przez to osiągnąć?
> Przy okazji tak wielkich baz rodzi się od razu drugie pytanie - jak to
> poprawnie backupować? Zrzucenie dumpa z takiej bazy danych odpada.
> Jakieś inne rozsądne możliwości, które nie zabiją wydajności samej
> bazy? Nie ukrywam, że jedyną możliwością mógłby być backup na poziomie
> systemu (Linux)...
możesz robić backupy metodą archiwizowania logów wal.
szczegóły:
http://www.postgresql.org/docs/curre...archiving.html
narzut na wydajność systemu praktycznie zerowy.
> Sama baza będzie wykorzystywana wyłącznie do dodawania kolejnych
> rekordów, rzadko do wyszukania po zindeksowanym unikalnym polu.
masz świadomość, że trzymanie plików binarnych w bazie jest takim sobie
pomysłem? (zazwyczaj)
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Andrzej Nakonieczny - 11-08-2007 00:02
hubert depesz lubaczewski wrote:
>> może rozwiązaniem byłoby partycjonowanie tabel przy czym każda z
>> takich tabel umieszczona byłaby na osobnym tablespace'ie?
>
> to wydaje się być akceptowalne. tyle, że nie wiem czemu chcesz
> rozrzucać dane po różnych tablespace'ach.
> co chcesz przez to osiągnąć?
W przypadku gdyby sam system operacyjny ograniczył mi maksymalną
wielkość partycji (ograniczenia związane z typem fs, wielkością bloku
itd) a tabela byłaby większa to chyba jedyne rozwiązanie? A może się
mylę?
> możesz robić backupy metodą archiwizowania logów wal.
> szczegóły:
>
http://www.postgresql.org/docs/curre...archiving.html
> narzut na wydajność systemu praktycznie zerowy.
OK, zaraz to przeglądnę dokładnie. Dzięki za sugestię.
>> Sama baza będzie wykorzystywana wyłącznie do dodawania kolejnych
>> rekordów, rzadko do wyszukania po zindeksowanym unikalnym polu.
>
> masz świadomość, że trzymanie plików binarnych w bazie jest takim
> sobie pomysłem? (zazwyczaj)
Ja? Tak. :) Pisałem o tym w drugim zdaniu, na samym początku, nawet
podkreśliłem słowo "pomijam". ;)
Niestety, jak to w życiu bywa, nie zawsze ma się wpływ na drugą stronę
(tu aplikację).
Pozdrawiam,
Andrzej
hubert depesz lubaczewski - 11-08-2007 00:02
Dnia 10.08.2007 Andrzej Nakonieczny <dzemik@pingwin.invalid> napisał/a:
> W przypadku gdyby sam system operacyjny ograniczył mi maksymalną
> wielkość partycji (ograniczenia związane z typem fs, wielkością bloku
> itd) a tabela byłaby większa to chyba jedyne rozwiązanie? A może się
> mylę?
zakładając, że korzystasz z systemu 64 bitowego, to maksymalna wielkość
partycji ext3 to 32tb - zakładając największą (choć nie wiem jaką)
wielkość bloku.
dla bazy danych duże bloki nie powinny być problemem, czyli wydaje mi
się, że nie powinno to przeszkadzać.
jak przekroczysz 32tera to wtedy faktycznie pozostaje partycjonowanie,
albo system plików który nie ma takich ograniczeń.
w szczególności - już teraz masz dostępny (od linuxa 2.6.19) ext4 który
ma max wielkość 1024petabajtów.
z innych opcji:
jfs: 32peta
xfs: 8exa
zfs: 2^18exa
> Ja? Tak. :) Pisałem o tym w drugim zdaniu, na samym początku, nawet
> podkreśliłem słowo "pomijam". ;)
> Niestety, jak to w życiu bywa, nie zawsze ma się wpływ na drugą stronę
> (tu aplikację).
wiesz, aplikacji tak naprawdę to nawet nie musi boleć.
wystarczy, że zapis obrazków zrobisz jakąś funkcją (coś jak
lo*interface), które to funkcje będą trzymały pliki poza bazą.
ale to taka luźna idea, nie przemyslana, i nie wiem nawet czy na 100%
słuszna.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Andrzej Nakonieczny - 11-08-2007 00:02
hubert depesz lubaczewski wrote:
> zakładając, że korzystasz z systemu 64 bitowego, to maksymalna
> wielkość partycji ext3 to 32tb - zakładając największą (choć nie wiem
[...]
Zgadza się. Pytanie urodziło się gdyż jakiś czas temu miałem problemy z
partycjami kilku terabajtowymi, nie pamiętam jednak jaki dokładnie tam
był system ani jaki filesystem. Nie ważne. Myślę, że
obecnie "ograniczenia" zarówno PostgreSQL jak i fs są wystarczające. :)
> wiesz, aplikacji tak naprawdę to nawet nie musi boleć.
Niestety nie zawsze ma się dostęp do źródeł aplikacji.
Pozdrawiam,
Andrzej
Jakub Wartak - 11-08-2007 00:02
Andrzej Nakonieczny wrote:
> Witam
>
> Zastanawiam się nad możliwościami PostgreSQL w udostępnianiu
> dużych
> (ogromnych?) baz danych. _Pomijam_ samą sensowność wykorzystania go w
> taki sposób, nie mam na to żadnego wpływu, próbuję się skupić wyłącznie
> na możliwych problemach jakie mogłyby się pojawić przy próbie
> uruchomienia takiej bazy.
>
> Powiedzmy, że potrzebuję umieścić w bazie x milionów plików, każdy o
> wielkości do kilku megabajtów. Jak łatwo policzyć tabela taka mogła by
> osiągnąć rozmiary x terabajtów. Spoglądając na strony projektu można
> przeczytać, że PostgreSQL obsługuje tabele o wielkości do 32 TB więc to
> powinno być wystarczające. Wcześniejsze ograniczenie - o ile dobrze
> pamiętam - wynosiło 16 TB. Czy to ograniczenie związane było (wciąż
> jest związane?) z samym PostgreSQLem czy też raczej to problem
> wielkości pojedynczej partycji na której znajduje się tabela?
>
> Jeśli - przypuśćmy - sam system ograniczy możliwość stworzenia tak
> dużego zasobu (powiedzmy powyżej 8 albo 16 TB) to czy jednak istnieje
> możliwość obsłużenia tak dużej bazy danych? O ile w przypadku innych
> baz (rozwiązania komercyjne) możliwe jest stworzenie pojedynczej bazy
> na kilku przestrzeniach (w postaci partycji/plików) o tyle w PostgreSQL
> chyba nie można rozłożyć tabeli na kilka tablespace'ów? A może
> rozwiązaniem byłoby partycjonowanie tabel przy czym każda z takich
> tabel umieszczona byłaby na osobnym tablespace'ie?
>
> Przy okazji tak wielkich baz rodzi się od razu drugie pytanie - jak to
> poprawnie backupować? Zrzucenie dumpa z takiej bazy danych odpada.
> Jakieś inne rozsądne możliwości, które nie zabiją wydajności samej
> bazy? Nie ukrywam, że jedyną możliwością mógłby być backup na poziomie
> systemu (Linux)...
Moze snapshoty filesystemu (LVM) i ich dump na inna maszyne ? (z kompresja w
locie, na maszynie gdzie masz wiecej mocy obliczeniowej, tzn. kompresja na
maszynie do backupow zazwyczaj).
Jeszcze zastanow sie czy chcesz robic np RAID1 czy RAID5 i co bedzie w
przypadku jesli tego nie zrobisz a poleci jeden z dyskow (=> poleci 1 duzy
plik na filesystemie, nie wspominajac o czestotliwosci wykonywania backupow
i utracie danych w przypadku gdy logi tez poleca ;) )
Moze te linki beda choc troche przydatne:
http://images.omniti.net/omniti.com/...BBPostgres.pdf
http://www.lethargy.org/~jesus/archi...ver-Linux.html
--
Jakub Wartak
http://vnull.pcnet.com.pl
Andrzej Nakonieczny - 11-08-2007 00:02
Jakub Wartak wrote:
> Moze snapshoty filesystemu (LVM) i ich dump na inna maszyne ? (z
Snapshot na poziomie samego FS nie jest wskazany gdyż nie zna stanu w
jakim znajduje się sam PostgreSQL. Hubert zwrócił już uwagę na jedno
rozwiązanie, któremu się przyglądnę.
> Jeszcze zastanow sie czy chcesz robic np RAID1 czy RAID5 i co bedzie w
To akurat inna sprawa ale to nie moja działka - właściwy storage będzie
udostępniony.
Pozdrawiam,
Andrzej
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
Kodowanie: z iso na utf
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Połączenie bazy danych z wykonaniem polaczenia telefonicznego
[mssql] insert do tabeli na podstawie danych z innej tabeli
[MySQL] - Wstawianie aktualnej daty do bazy danych - PHP i MySQL
zanotowane.pldoc.pisz.plpdf.pisz.plfelgiuzywane.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
