Discussion:
Przechowywanie plikow w bazie danych
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
makil
2005-08-17 11:07:10 UTC
Permalink
Planuje zaprojektowanie bazy danych, ktora mialaby przechowywac pliki (do
ok. 10 MB - spakowane pliki, pdf-y, jpeg-i, itp.)
Baze planuje zrobic w MySQLu.
Jaki mechanizm przechowywania tych plikow byscie proponowali. Nie mam
doswiadczenia w tej kwestii, a chcialbym zeby baza dzialala w miare dobrze.
Czy polecacie np. zastosowanie pola 'blob', czy moze inny sposob.
Za wszelkie sugestie z gory dzieki.


----=== Pozdrawiam ===----
----=== makil ===----
----=== ***@poczta.onet.pl ===----
----=== GG 2156828 ===----
Mariusz Kruk
2005-08-17 11:14:17 UTC
Permalink
W dniu Wed, 17 Aug 2005 13:07:10 +0200, osoba określana zwykle jako
Post by makil
Jaki mechanizm przechowywania tych plikow byscie proponowali. Nie mam
doswiadczenia w tej kwestii, a chcialbym zeby baza dzialala w miare dobrze.
Czy polecacie np. zastosowanie pola 'blob', czy moze inny sposob.
Pliki na normalny filesystem, a do bazy tylko informację o lokalizacji
pliku (przy okazji można i inne metadane tam wsadzić).
--
Kruk@ -\ | (If you're confused by all this, try typig
}-> epsilon.eu.org | `I}' now.)(TeX)
http:// -/ |
|
Adam Glazik
2005-08-17 12:45:12 UTC
Permalink
Post by Mariusz Kruk
W dniu Wed, 17 Aug 2005 13:07:10 +0200, osoba określana zwykle jako
Post by makil
Jaki mechanizm przechowywania tych plikow byscie proponowali. Nie mam
doswiadczenia w tej kwestii, a chcialbym zeby baza dzialala w miare dobrze.
Czy polecacie np. zastosowanie pola 'blob', czy moze inny sposob.
Pliki na normalny filesystem, a do bazy tylko informację o lokalizacji
pliku (przy okazji można i inne metadane tam wsadzić).
Przecież to nie będzie działać gdy będziesz się chciał dostać się z innego
komputera.
Do tego należy synchronizować pliki z danymi w bazie, a co jeśli zaczniesz
używać transakcji?.
Generalnie to już lepiej użyć blobów.
No chyba, że bazę zawsze masz lokalnie...
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
makil
2005-08-17 13:04:02 UTC
Permalink
Post by Adam Glazik
No chyba, że bazę zawsze masz lokalnie...
wlasnie o to chodzi, ze mam zamiar zrobic dostep do tej bazy przez Internet.
Post by Adam Glazik
Generalnie to już lepiej użyć blobów.
jednak czy zastosowanie blobow nie spowolni zbytnio bazy?



----=== Pozdrawiam ===----
----=== makil ===----
----=== ***@poczta.onet.pl ===----
----=== GG 2156828 ===----
JerzyM
2005-08-17 13:15:21 UTC
Permalink
Post by Adam Glazik
Przecież to nie będzie działać gdy będziesz się chciał dostać się z innego
komputera.
hmmm a nie wynaleziono już przypadkiem rozległych file systemów, zdalnego
montowania dysków, httpa do ściągania plików i tysiąca innych rozwiązań ??

Pakowanie dużych blobów do MySQLa + dużej ich ilości nie jest zbyt rozsądne
... wydajność tak czy siak pójdzie dramatycznie w dół.
--
--------------------------------
Opinie wygłaszane na newsach są moim prywatnym
zdaniem nie mającym nic wspólnego z jakimkolwiek
byłym, obecnym lub przyszłym moim pracodawcą.
Mikolaj Rydzewski
2005-08-17 14:24:46 UTC
Permalink
Post by JerzyM
hmmm a nie wynaleziono już przypadkiem rozległych file systemów, zdalnego
montowania dysków, httpa do ściągania plików i tysiąca innych rozwiązań ??
Kazde takie rozwiazanie niesie za soba narzut w postaci koniecznosci
pisania dodatkowego kodu, konfiguracji firewalla oraz nawet konfiguracji
lokalnej stacji/serwera (w przypadku montowania filesystemow).
Post by JerzyM
Pakowanie dużych blobów do MySQLa + dużej ich ilości nie jest zbyt rozsądne
... wydajność tak czy siak pójdzie dramatycznie w dół.
W dol pojdzie. A czy dramatycznie? To trzeba by sprawdzic na konkretnym
przypadku - moze zauwazony spadek bedzie akceptowalny.
--
Mikołaj Rydzewski
Przemyslaw Popielarski
2005-08-17 22:59:16 UTC
Permalink
Post by JerzyM
Pakowanie dużych blobów do MySQLa + dużej ich ilości nie jest zbyt
rozsądne ... wydajność tak czy siak pójdzie dramatycznie w dół.
Dodatkowo dosc szybko moga sie pojawic problemy z ograniczeniem rozmiaru
pliku w filesystemie.
Zdecydowanie polecam trzymanie tylko namiarow na plik w bazie, a pliki
pozostawmy systemowi plikow, od tego jest.
--
./ premax
./ ***@hot,pl
./ koniec i bomba, a kto czytal ten traba. w.g.
Marcin Goralski
2005-08-18 09:05:41 UTC
Permalink
Post by Przemyslaw Popielarski
Dodatkowo dosc szybko moga sie pojawic problemy z ograniczeniem rozmiaru
pliku w filesystemie.
Chodzi o plik danych ? Zapewne mozna dodac kolejny ... a nawet mozna
wydzielic plik zawierajacy tablice do skladowania plikow (o ile MySQL
pozwala na takie rozdzielenie)
Post by Przemyslaw Popielarski
Zdecydowanie polecam trzymanie tylko namiarow na plik w bazie, a pliki
pozostawmy systemowi plikow, od tego jest.
Upraszcza backup/restore, oszczedza miejsce, natomiast komplikuje kod
aplikacji oraz zarzadzanie prawami dostepu. Dodatkowo, w bazie latwiej
ukryc dane przed osobami majacymi fizyczny dostep do servera, poprzez
indywidualne szyfrowanie plikow/blobow - robienie tego na poziomie
filesystemu wymaga zmapowania userow aplikacji do userow OSa/bazy.
Cholernie utrudnia kodowanie i pozniejsze utrzymanie.

marcin
Mariusz Kruk
2005-08-18 10:39:56 UTC
Permalink
W dniu Thu, 18 Aug 2005 11:05:41 +0200, osoba określana zwykle jako
Post by Marcin Goralski
Post by Przemyslaw Popielarski
Dodatkowo dosc szybko moga sie pojawic problemy z ograniczeniem rozmiaru
pliku w filesystemie.
Chodzi o plik danych ? Zapewne mozna dodac kolejny ... a nawet mozna
wydzielic plik zawierajacy tablice do skladowania plikow (o ile MySQL
pozwala na takie rozdzielenie)
Mysql akurat IIRC trzyma każdą tablicę w osobnym pliku.
Post by Marcin Goralski
Post by Przemyslaw Popielarski
Zdecydowanie polecam trzymanie tylko namiarow na plik w bazie, a pliki
pozostawmy systemowi plikow, od tego jest.
Upraszcza backup/restore, oszczedza miejsce, natomiast komplikuje kod
aplikacji oraz zarzadzanie prawami dostepu. Dodatkowo, w bazie latwiej
ukryc dane przed osobami majacymi fizyczny dostep do servera, poprzez
indywidualne szyfrowanie plikow/blobow - robienie tego na poziomie
filesystemu wymaga zmapowania userow aplikacji do userow OSa/bazy.
Szyfrowanie wymaga mapowania userów? Zarządzanie prawami dostępu per
user - owszem, ale szyfrowanie? Chyba, że nie do końca rozumiem w której
warstwie chciałbyś to zrobić.
--
[------------------------] Please don't say `\def cs{...}', say
[ ***@epsilon.eu.org ] `\def\cs{...}'.(TeX)
[ http://epsilon.eu.org/ ]
[------------------------]
Przemyslaw Popielarski
2005-08-19 00:17:07 UTC
Permalink
Post by Mariusz Kruk
Post by Marcin Goralski
Chodzi o plik danych ? Zapewne mozna dodac kolejny ... a nawet mozna
wydzielic plik zawierajacy tablice do skladowania plikow (o ile MySQL
pozwala na takie rozdzielenie)
Mysql akurat IIRC trzyma każdą tablicę w osobnym pliku.
No MyISAM tak. InnoDB moze sobie rozdzielic na pare plikow swoj space.
--
./ premax
./ ***@hot,pl
./ koniec i bomba, a kto czytal ten traba. w.g.
Mariusz Kruk
2005-08-19 08:32:10 UTC
Permalink
W dniu Fri, 19 Aug 2005 02:17:07 +0200, osoba określana zwykle jako
Post by Przemyslaw Popielarski
Post by Mariusz Kruk
Post by Marcin Goralski
Chodzi o plik danych ? Zapewne mozna dodac kolejny ... a nawet mozna
wydzielic plik zawierajacy tablice do skladowania plikow (o ile MySQL
pozwala na takie rozdzielenie)
Mysql akurat IIRC trzyma każdą tablicę w osobnym pliku.
No MyISAM tak. InnoDB moze sobie rozdzielic na pare plikow swoj space.
Znaczy - dawno się nie tykałem MySQLa :-)
--
[------------------------] Niewielu z nas może znieść dobrobyt. Innych
[ ***@epsilon.eu.org ] ludzi, rzecz jasna.
[ http://epsilon.eu.org/ ]
[------------------------]
Mariusz Kruk
2005-08-17 13:31:09 UTC
Permalink
W dniu Wed, 17 Aug 2005 12:45:12 +0000 (UTC), osoba określana zwykle jako
Post by makil
Post by Mariusz Kruk
Post by makil
Jaki mechanizm przechowywania tych plikow byscie proponowali. Nie mam
doswiadczenia w tej kwestii, a chcialbym zeby baza dzialala w miare
dobrze.
Post by Mariusz Kruk
Post by makil
Czy polecacie np. zastosowanie pola 'blob', czy moze inny sposob.
Pliki na normalny filesystem, a do bazy tylko informację o lokalizacji
pliku (przy okazji można i inne metadane tam wsadzić).
Przecież to nie będzie działać gdy będziesz się chciał dostać się z innego
komputera.
Od tego są mechanizmy zdalnego dostępu do plików. Chociażby HTTP.
Post by makil
Do tego należy synchronizować pliki z danymi w bazie, a co jeśli zaczniesz
używać transakcji?.
Trzeba by wtedy zrealizować jakiś mechanizm odpowiedzialny za to. Sorry,
TANSTAAFL.
Post by makil
Generalnie to już lepiej użyć blobów.
Generalnie, to generalizacje szkodzą :-P
Poza tym po co zaprzęgać mechanizm stworzony do czegoś zupełnie innego
do robienia czegoś, do czego on z założenia za bardzo nie służy?
Poza tym, wiesz jak będzie się zachowywać baza przy dużej rotacji takich
blobów? Zarówno w kwestii szybkości dostępu jak i rozmiarów bazy? Bo w
przypadku filesystemów można to zwykle dość dobrze określić.
--
Kruk@ -\ | A user will find any interface design intu-
}-> epsilon.eu.org | itive...with enough practice.
http:// -/ |
|
Mikolaj Rydzewski
2005-08-17 14:21:45 UTC
Permalink
Post by Mariusz Kruk
Poza tym po co zaprzęgać mechanizm stworzony do czegoś zupełnie innego
do robienia czegoś, do czego on z założenia za bardzo nie służy?
Poza tym, wiesz jak będzie się zachowywać baza przy dużej rotacji takich
blobów? Zarówno w kwestii szybkości dostępu jak i rozmiarów bazy? Bo w
przypadku filesystemów można to zwykle dość dobrze określić.
Nie wiemy jak duza bedzie rotacja danych. Obie opcje maja swoje za i
przeciw.

Zastosowanie blobow znaczaco uprosci tworzenie aplikacji, backupy,
replikacje danych, itd. Jednak wplynie negatywnie na wydajnosc. Moze
jednak zysk na wygodzie i jednolitym mechanizmie bedzie duzo wyzszy niz
spadek na wydajnosci?

To drugie zawsze mozna poprawic inwestujac w sprzet. A spaprany kod jest
trudny do naprawienia.
--
Mikołaj Rydzewski
Mariusz Kruk
2005-08-17 14:56:52 UTC
Permalink
W dniu Wed, 17 Aug 2005 16:21:45 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Poza tym po co zaprzęgać mechanizm stworzony do czegoś zupełnie innego
do robienia czegoś, do czego on z założenia za bardzo nie służy?
Poza tym, wiesz jak będzie się zachowywać baza przy dużej rotacji takich
blobów? Zarówno w kwestii szybkości dostępu jak i rozmiarów bazy? Bo w
przypadku filesystemów można to zwykle dość dobrze określić.
Nie wiemy jak duza bedzie rotacja danych. Obie opcje maja swoje za i
przeciw.
Ba. Co nie ma? ;-)
Post by Mikolaj Rydzewski
Zastosowanie blobow znaczaco uprosci tworzenie aplikacji,
Może.
Post by Mikolaj Rydzewski
backupy,
Niekoniecznie. Spróbuj odzyskać z taśmy trzy rekordy z tabeli, a spróbuj
to samo zrobić z trzema plikami z katalogu.
Post by Mikolaj Rydzewski
replikacje danych, itd. Jednak wplynie negatywnie na wydajnosc. Moze
jednak zysk na wygodzie i jednolitym mechanizmie bedzie duzo wyzszy niz
spadek na wydajnosci?
To drugie zawsze mozna poprawic inwestujac w sprzet. A spaprany kod jest
trudny do naprawienia.
Bo to pewnie i tak trzeba przeprojektować ;->
--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb Przez ciernie do gwiazd - w oczach.(Wojtek
`b ***@epsilon.eu.org d' Moszko)
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'
Paweł Matejski
2005-08-18 01:54:08 UTC
Permalink
Post by Mariusz Kruk
W dniu Wed, 17 Aug 2005 16:21:45 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Zastosowanie blobow znaczaco uprosci tworzenie aplikacji,
Może.
Post by Mikolaj Rydzewski
backupy,
Niekoniecznie. Spróbuj odzyskać z taśmy trzy rekordy z tabeli, a spróbuj
to samo zrobić z trzema plikami z katalogu.
Mówimy o backupuch, nie o odtwarzaniu a tym bardziej archiwizacji danych.
A zrobienie spójnego backupu bez zatrzymywania aplikacji nie jest proste.
--
P.M.
Mariusz Kruk
2005-08-18 08:33:04 UTC
Permalink
W dniu Thu, 18 Aug 2005 03:54:08 +0200, osoba określana zwykle jako
Post by Paweł Matejski
Post by Mariusz Kruk
Niekoniecznie. Spróbuj odzyskać z taśmy trzy rekordy z tabeli, a spróbuj
to samo zrobić z trzema plikami z katalogu.
Mówimy o backupuch, nie o odtwarzaniu a tym bardziej archiwizacji danych.
Zaraz... backup bez możliwości odtwarzania jest cokolwiek idiotycznym
pomysłem.
Post by Paweł Matejski
A zrobienie spójnego backupu bez zatrzymywania aplikacji nie jest proste.
Jak aplikacja ma na tyle zawiłe mechanizmy, że stan backupu robionego
"tradycyjnymi" metodami może być niespójny, powinna mieć mechanizmy do
zapewnienia spójności tegoż backupu.
--
/\-\/\-\/\-\/\-\/\-\/\-\/\ Anything that happens enough times to irri-
\ ***@epsilon.eu.org / tate you will happen at least once more.
/ http://epsilon.eu.org/ \
\/-/\/-/\/-/\/-/\/-/\/-/\/
Krycek
2005-08-18 09:00:32 UTC
Permalink
Post by Mariusz Kruk
Zaraz... backup bez możliwości odtwarzania jest cokolwiek idiotycznym
pomysłem.
Pewnie chodziło o odtwarzanie backupu jako całości a nie konkretnych
fragmentów.
Post by Mariusz Kruk
Jak aplikacja ma na tyle zawiłe mechanizmy, że stan backupu robionego
"tradycyjnymi" metodami może być niespójny, powinna mieć mechanizmy do
zapewnienia spójności tegoż backupu.
I właśnie takie mechanizmy + obsługa transakcji zapewniają pola typu BLOB
w bazie danych nie ma więc co wynajdować koła jeszcze raz. Moim skromnym
zdaniem oczywiście.
--
Używam programu pocztowego Opery: http://www.opera.com/mail/
Mariusz Kruk
2005-08-18 10:23:21 UTC
Permalink
W dniu Thu, 18 Aug 2005 11:00:32 +0200, osoba określana zwykle jako
Post by Krycek
Post by Mariusz Kruk
Zaraz... backup bez możliwości odtwarzania jest cokolwiek idiotycznym
pomysłem.
Pewnie chodziło o odtwarzanie backupu jako całości a nie konkretnych
fragmentów.
Ja wiem o co chodziło ;-P
Ale nie zmienia to faktu, że sytuacje typu "Panie Mariuszu, niech mi pan
znajdzie taki dokument co go trzy dni temu skasowałem" się zdarzają.
Post by Krycek
Post by Mariusz Kruk
Jak aplikacja ma na tyle zawiłe mechanizmy, że stan backupu robionego
"tradycyjnymi" metodami może być niespójny, powinna mieć mechanizmy do
zapewnienia spójności tegoż backupu.
I właśnie takie mechanizmy + obsługa transakcji zapewniają pola typu BLOB
w bazie danych nie ma więc co wynajdować koła jeszcze raz. Moim skromnym
zdaniem oczywiście.
Do pewnego stopnia - owszem, tak. Zależy od konkretnej sytuacji.
--
/\-\/\-\/\-\/\-\/\-\/\-\/\ Rzeczywiście Geant ma dosyć rozbudowany jak
\ ***@epsilon.eu.org / na spożywczaka dział komputerowy (Bart Ogry-
/ http://epsilon.eu.org/ \ czak)
\/-/\/-/\/-/\/-/\/-/\/-/\/
Mikolaj Rydzewski
2005-08-18 11:45:38 UTC
Permalink
Post by Mariusz Kruk
Ale nie zmienia to faktu, że sytuacje typu "Panie Mariuszu, niech mi pan
znajdzie taki dokument co go trzy dni temu skasowałem" się zdarzają.
Wg mnie ww przyklad przemawia tylko za wykorzystaniem bazy danych.
Tworzysz triggera zapamietujacego zmieniony/usuniety rekord w tabeli
historii i masz wszystko jak na dloni. Bez odtwarzania z backupow,
kombinowania. A jesli typ pliku pozwala, to ow trigger moglby np.
zapisywac do historii tylko diffa miedzy poszczegolnymi zmianami.

Triggery moze niekoniecznie w mysql, ale sam mechanizm mozna calkiem
latwo zakodowac nie majac ich.
--
Mikołaj Rydzewski
Mariusz Kruk
2005-08-18 14:05:40 UTC
Permalink
W dniu Thu, 18 Aug 2005 13:45:38 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Ale nie zmienia to faktu, że sytuacje typu "Panie Mariuszu, niech mi pan
znajdzie taki dokument co go trzy dni temu skasowałem" się zdarzają.
Wg mnie ww przyklad przemawia tylko za wykorzystaniem bazy danych.
Tworzysz triggera zapamietujacego zmieniony/usuniety rekord w tabeli
historii i masz wszystko jak na dloni. Bez odtwarzania z backupow,
kombinowania. A jesli typ pliku pozwala, to ow trigger moglby np.
zapisywac do historii tylko diffa miedzy poszczegolnymi zmianami.
Łomatko. Czyli zastępujemy rozwiązanie proste zawiłym?
Post by Mikolaj Rydzewski
Triggery moze niekoniecznie w mysql,
No raczej chyba mocno niekoniecznie.
Post by Mikolaj Rydzewski
ale sam mechanizm mozna calkiem
latwo zakodowac nie majac ich.
Czyli jeszcze gorzej, bo znowu komplikujesz projekt. O kodzie już nie
wspomniawszy.
--
Kruk@ -\ | Księżyc jest księżycem także bez sonaty
}-> epsilon.eu.org | (Zbigiew Herbert)
http:// -/ |
|
Mikolaj Rydzewski
2005-08-18 14:37:20 UTC
Permalink
Post by Mariusz Kruk
Łomatko. Czyli zastępujemy rozwiązanie proste zawiłym?
Uwazasz ze przechowywanie ilus tam kopii rekordow wstecz za pomoca
triggerow jest trudniejsze od kazdorazowego odtwarzania usunietych z
backupu?

To pierwsze jest robione na poziomie bazy/aplikacji, user moze zrobic
'undo' na rekordach/plikach, nawet do ilus tam wersji wstecz. A backup?
Gdy znajdzie admina, admin znajdzie tasiemke i odtworzy to minie pol
dnia... A jak tasiemki nie bedzie bo zuzyl na inny backup? ;-)
Post by Mariusz Kruk
Czyli jeszcze gorzej, bo znowu komplikujesz projekt. O kodzie już nie
wspomniawszy.
Sam go skomplikowales podsuwajac sytuacje "Panie Mariuszu, niech mi pan
znajdzie taki dokument co go trzy dni temu skasowałem".

Nie twierdze, ze trzymanie plikow w blobach jest zawsze lepsze niz
trzymanie ich na dysku. Znacznie jednak upraszcza aplikacje, niestety
kosztem wydajnosci.

Chocby zwykle usuwanie dokumentow z jakiejs kategorii. Gdy calosc jest w
bazie wystarczy jedno 'delete from ...' i to co trzeba zniknie (a moze i
zostanie zachowane w tabeli historii). A gdybys pliki mial na dysku?
Musisz wydobyc nazwy tych plikow, usunac rekordy i pliki. Pracy duzo wiecej.

Proponuje EOT, bo oba rozwiazanie sa dobre. Nie kazde nadaje sie do
wszystkich zastosowan po prostu.
--
Mikołaj Rydzewski
Mariusz Kruk
2005-08-18 17:00:01 UTC
Permalink
W dniu Thu, 18 Aug 2005 16:37:20 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Łomatko. Czyli zastępujemy rozwiązanie proste zawiłym?
Uwazasz ze przechowywanie ilus tam kopii rekordow wstecz za pomoca
triggerow jest trudniejsze od kazdorazowego odtwarzania usunietych z
backupu?
I jak chcesz ograniczyć wielkość takiej tabeli ze zmianami?
Post by Mikolaj Rydzewski
To pierwsze jest robione na poziomie bazy/aplikacji, user moze zrobic
'undo' na rekordach/plikach, nawet do ilus tam wersji wstecz. A backup?
Gdy znajdzie admina, admin znajdzie tasiemke i odtworzy to minie pol
dnia...
A jak się device zapcha? :-P
Post by Mikolaj Rydzewski
A jak tasiemki nie bedzie bo zuzyl na inny backup? ;-)
Nie ma takiej opcji. Od tego jest polityka kopii bezpieczeństwa, żeby
przed ustalonym czasem nic nie zostało skasowane.
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Post by Mariusz Kruk
Czyli jeszcze gorzej, bo znowu komplikujesz projekt. O kodzie już nie
wspomniawszy.
Sam go skomplikowales podsuwajac sytuacje "Panie Mariuszu, niech mi pan
znajdzie taki dokument co go trzy dni temu skasowałem".
Owszem. Zdarza się.
Post by Mikolaj Rydzewski
Nie twierdze, ze trzymanie plikow w blobach jest zawsze lepsze niz
trzymanie ich na dysku. Znacznie jednak upraszcza aplikacje, niestety
kosztem wydajnosci.
O. I tu się zgadzamy.
Post by Mikolaj Rydzewski
Chocby zwykle usuwanie dokumentow z jakiejs kategorii. Gdy calosc jest w
bazie wystarczy jedno 'delete from ...' i to co trzeba zniknie (a moze i
zostanie zachowane w tabeli historii). A gdybys pliki mial na dysku?
Musisz wydobyc nazwy tych plikow, usunac rekordy i pliki. Pracy duzo wiecej.
Z drugiej strony - przesuwasz do silnika bazy danych operacje, które
normalnie wykonuje system operacyjny - całą zabawę z alokacją
przestrzeni na dane, odzyskiwanie tejże itd. itp.
Post by Mikolaj Rydzewski
Proponuje EOT, bo oba rozwiazanie sa dobre. Nie kazde nadaje sie do
wszystkich zastosowan po prostu.
O. I tu się zgadzamy :-)
--
Kruk@ -\ | I am Borg of Borg: Redundancy is irrelevant.
}-> epsilon.eu.org |
http:// -/ |
|
Mikolaj Rydzewski
2005-08-19 07:28:30 UTC
Permalink
Post by Mariusz Kruk
W dniu Thu, 18 Aug 2005 16:37:20 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Uwazasz ze przechowywanie ilus tam kopii rekordow wstecz za pomoca
triggerow jest trudniejsze od kazdorazowego odtwarzania usunietych z
backupu?
I jak chcesz ograniczyć wielkość takiej tabeli ze zmianami?
Ok, wiec jeszcze raz pomimo poprzedniego EOT ;-)

Zbaczasz wg mnie z glownego tematu, zebym nie powiedzial czepiasz sie
;-) To, o co teraz pytasz to sa szczegoly implementacyjne. A mnie
chodzilo o przedstawienie alternatywnego sposobu.

Sposobow na ograniczenie rozmiarow historii jest wiele, ile sobie
projektant wymysli. Mozna trzymac n-ostatnich zmian, zmiany do n-dni
wstecz, itd, itd. Mozna okresowo usuwac starsze niz n-dni zapisy. Na tym
etapie dyskusji nie jest to istotne.
Post by Mariusz Kruk
Post by Mikolaj Rydzewski
To pierwsze jest robione na poziomie bazy/aplikacji, user moze zrobic
'undo' na rekordach/plikach, nawet do ilus tam wersji wstecz. A backup?
Gdy znajdzie admina, admin znajdzie tasiemke i odtworzy to minie pol
dnia...
A jak się device zapcha? :-P
Zapchac sie moze zawsze. Takze przy trzymaniu plikow bezposrednio na
dysku. Od tego jest odpowiednia polityka i systemy monitoringu zeby
takie sytuacje nie mialy miejsca.
Post by Mariusz Kruk
Z drugiej strony - przesuwasz do silnika bazy danych operacje, które
normalnie wykonuje system operacyjny - całą zabawę z alokacją
przestrzeni na dane, odzyskiwanie tejże itd. itp.
W zamian otrzymuje transakcje, wspomniana tabele z historia, spojny kod
aplikacji, bezproblemowy dostep wielu klientow, prawa dostepu, itd, itd.

Sa sytuacje, kiedy plusy przeslaniaja minusy.
Post by Mariusz Kruk
Post by Mikolaj Rydzewski
Proponuje EOT, bo oba rozwiazanie sa dobre. Nie kazde nadaje sie do
wszystkich zastosowan po prostu.
Ponawiam ;-)
--
Mikołaj Rydzewski
Mariusz Kruk
2005-08-19 08:31:49 UTC
Permalink
W dniu Fri, 19 Aug 2005 09:28:30 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Post by Mikolaj Rydzewski
Uwazasz ze przechowywanie ilus tam kopii rekordow wstecz za pomoca
triggerow jest trudniejsze od kazdorazowego odtwarzania usunietych z
backupu?
I jak chcesz ograniczyć wielkość takiej tabeli ze zmianami?
Ok, wiec jeszcze raz pomimo poprzedniego EOT ;-)
Zbaczasz wg mnie z glownego tematu, zebym nie powiedzial czepiasz sie
;-)
Ależ oczywiście, że się czepiam ;-)
Post by Mikolaj Rydzewski
To, o co teraz pytasz to sa szczegoly implementacyjne.
Ale wpływające na całość projektu. Pewne rzeczy trzeba przewidzieć, bo
inaczej się człowiek budzi z ręką w naczyniu nocnym. (oj, mamy taki
system, co trzyma pliki na dysku, a metadane w bazie; i byłby dobry
gdyby go nie spaprali byli ;->).
Post by Mikolaj Rydzewski
Sposobow na ograniczenie rozmiarow historii jest wiele, ile sobie
projektant wymysli. Mozna trzymac n-ostatnich zmian, zmiany do n-dni
wstecz, itd, itd. Mozna okresowo usuwac starsze niz n-dni zapisy. Na tym
etapie dyskusji nie jest to istotne.
Każde z tych rozwiązań ma swoje wady. I trzeba sobie z tego zdawać
sprawę.
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Post by Mikolaj Rydzewski
To pierwsze jest robione na poziomie bazy/aplikacji, user moze zrobic
'undo' na rekordach/plikach, nawet do ilus tam wersji wstecz. A backup?
Gdy znajdzie admina, admin znajdzie tasiemke i odtworzy to minie pol
dnia...
A jak się device zapcha? :-P
Zapchac sie moze zawsze. Takze przy trzymaniu plikow bezposrednio na
dysku. Od tego jest odpowiednia polityka i systemy monitoringu zeby
takie sytuacje nie mialy miejsca.
A jak byś zrobił migrację części rekordów na inny device? Poważnie
pytam, bo nie mam pojęcia jak to można rozwiązać. Bo w przypadku plików,
przesuwam pliki gdzie indziej, robię update w bazie i mam co chciałem.
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Z drugiej strony - przesuwasz do silnika bazy danych operacje, które
normalnie wykonuje system operacyjny - całą zabawę z alokacją
przestrzeni na dane, odzyskiwanie tejże itd. itp.
W zamian otrzymuje transakcje, wspomniana tabele z historia, spojny kod
aplikacji, bezproblemowy dostep wielu klientow, prawa dostepu, itd, itd.
Prawa dostępu i tak masz. Dostęp wielu klientów... to zależy.
Transakcje, tabela z historią - to zależy od filesystemu na którym to
posadzisz. Spójny kod - owszem.
Post by Mikolaj Rydzewski
Sa sytuacje, kiedy plusy przeslaniaja minusy.
Owszem.
Post by Mikolaj Rydzewski
Post by Mariusz Kruk
Post by Mikolaj Rydzewski
Proponuje EOT, bo oba rozwiazanie sa dobre. Nie kazde nadaje sie do
wszystkich zastosowan po prostu.
Ponawiam ;-)
No dobrze. Idźmy spać :-)
--
[------------------------] And God said, "Let Einstein be"... and all
[ ***@epsilon.eu.org ] was relative.
[ http://epsilon.eu.org/ ]
[------------------------]
Paweł Matejski
2005-08-18 01:57:00 UTC
Permalink
Post by Mariusz Kruk
W dniu Wed, 17 Aug 2005 16:21:45 +0200, osoba określana zwykle jako
Post by Mikolaj Rydzewski
Zastosowanie blobow znaczaco uprosci tworzenie aplikacji,
Może.
Post by Mikolaj Rydzewski
backupy,
Niekoniecznie. Spróbuj odzyskać z taśmy trzy rekordy z tabeli, a spróbuj
to samo zrobić z trzema plikami z katalogu.
Mówimy o backupuch, nie o odtwarzaniu a tym bardziej archiwizacji danych.
A zrobienie spójnego backupu failsystemu bez przestawienia go w tryb ro
(czyli w praktyce zatrzymania przynajmniej części aplikacji) nie jest trywialne.
--
P.M.
Loading...