Thread View: pl.comp.bazy-danych
30 messages
30 total messages
Started by Alsor ZL
Fri, 18 Feb 2022 16:28
jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Fri, 18 Feb 2022 16:28
Date: Fri, 18 Feb 2022 16:28
14 lines
1802 bytes
1802 bytes
W dużych firmach jest sporo danych, które należy zabezpieczyć przed utratą. Przykładowo mamy bazę 20 albo i 200GB, i to codziennie rośnie... zmienia się, więc trzeba to chyba archiwizować na bieżąco - codziennie. Baza jest nieustannie modyfikowana: 24h / dobę przez wielu zdalnych pracowników, rozsianych nawet po całej Polsce, albo i dalej... Zatem nie można tego zablokować np. na godzinę i sobie kopiować całość... do odtworzenia na wypadek awarii. Jak to jest realizowane w praktyce?
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Sat, 19 Feb 2022 10:03
Date: Sat, 19 Feb 2022 10:03
32 lines
2125 bytes
2125 bytes
Dnia Fri, 18 Feb 2022 08:28:23 -0800 (PST), Alsor ZL napisał(a): > W dużych firmach jest sporo danych, > które należy zabezpieczyć przed utratą. > > Przykładowo mamy bazę 20 albo i 200GB, > i to codziennie rośnie... zmienia się, > więc trzeba to chyba archiwizować na bieżąco - codziennie. > > Baza jest nieustannie modyfikowana: 24h / dobę > przez wielu zdalnych pracowników, rozsianych nawet po całej Polsce, > albo i dalej... > > Zatem nie można tego zablokować np. na godzinę i sobie kopiować całość... do odtworzenia na wypadek awarii. > > Jak to jest realizowane w praktyce? Przecież bazy SQL (bo w zasadzie już tylko takie są używane) archiwizuje się podczas normalnej pracy, użytkownicy nawet tego nie widzą. Bazy te mają dużo "powietrza", więc można je skutecznie kompresować. Nawet MS-SQL umie zrobić BACKUP DATABASE TO DISK WITH COMPRESSION. W większych środowiskach stosuje się serwery backupowe. A ponadto są mechanizmy backupu różnicowego i przyrostowego, znane od prehistorii. W windowsach jest shadow-copy, który też nie wymaga przerwania pracy. W środowisku wirtualnym są migawki. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Sun, 20 Feb 2022 22:40
Date: Sun, 20 Feb 2022 22:40
16 lines
2216 bytes
2216 bytes
sobota, 19 lutego 2022 o 11:03:14 UTC+1 Adam napisał(a): > Przecież bazy SQL (bo w zasadzie już tylko takie są używane) archiwizuje > się podczas normalnej pracy, użytkownicy nawet tego nie widzą. > Bazy te mają dużo "powietrza", więc można je skutecznie kompresować. Nawet > MS-SQL umie zrobić BACKUP DATABASE TO DISK WITH COMPRESSION. W większych > środowiskach stosuje się serwery backupowe. > > A ponadto są mechanizmy backupu różnicowego i przyrostowego, znane od > prehistorii. W windowsach jest shadow-copy, który też nie wymaga przerwania > pracy. W środowisku wirtualnym są migawki. Chyba mówisz o malutkich bazach... Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, które mają tysiące punktów obsługi - w każdej mieścinie.
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Mon, 21 Feb 2022 15:23
Date: Mon, 21 Feb 2022 15:23
28 lines
1999 bytes
1999 bytes
Dnia Sun, 20 Feb 2022 14:40:15 -0800 (PST), Alsor ZL napisał(a): > sobota, 19 lutego 2022 o 11:03:14 UTC+1 Adam napisał(a): > >> Przecież bazy SQL (bo w zasadzie już tylko takie są używane) archiwizuje >> się podczas normalnej pracy, użytkownicy nawet tego nie widzą. >> Bazy te mają dużo "powietrza", więc można je skutecznie kompresować. Nawet >> MS-SQL umie zrobić BACKUP DATABASE TO DISK WITH COMPRESSION. W większych >> środowiskach stosuje się serwery backupowe. >> >> A ponadto są mechanizmy backupu różnicowego i przyrostowego, znane od >> prehistorii. W windowsach jest shadow-copy, który też nie wymaga przerwania >> pracy. W środowisku wirtualnym są migawki. > > Chyba mówisz o malutkich bazach... > > Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, > które mają tysiące punktów obsługi - w każdej mieścinie. Akurat banki i poczty mają stosunkowo małe bazy danych. Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest traktowane jako "duża" baza. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Mon, 21 Feb 2022 18:18
Date: Mon, 21 Feb 2022 18:18
23 lines
2663 bytes
2663 bytes
poniedziałek, 21 lutego 2022 o 16:23:23 UTC+1 Adam napisał(a): > > Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, > > które mają tysiące punktów obsługi - w każdej mieścinie. > Akurat banki i poczty mają stosunkowo małe bazy danych. > Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest > traktowane jako "duża" baza. dla mnie 100M czy 10000TB bez różnicy... pytanie było: jak to jest zabezpieczane przed utratą. Dla małych możesz sobie kopiować co 5 minut, bo to trwałoby kilka sekund. A dla dużych, wielkich, i rozproszonych, no to ja tego w ogóle nie widzę. Pewnie tego w ogóle się nie zabezpiecza - jazda na żywioł. Pomijam jakieś tam lokalne kopie z automatu, co jest trzymane w tym samym miejscu - i najpewniej na tym samym dysku... a przynajmniej: w jednym komputerze to siedzi; bo po co nam kupować dwa? Awaria, pożar, spięcie, ktoś ukradnie... no to pójdzie wsio w kosmos - wraz z tym zapasem.
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Cezary Grądys
Date: Mon, 21 Feb 2022 20:30
Date: Mon, 21 Feb 2022 20:30
19 lines
1770 bytes
1770 bytes
W dniu 21.02.2022 o 16:23, Adam pisze: > > Akurat banki i poczty mają stosunkowo małe bazy danych. > Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest > traktowane jako "duża" baza. > > Chyba coś ok 10 lat temu spotkałem się z opinią, że duza baza to taka co milion wierszy dziennie przybywa ;) -- Cezary Grądys czarekgr@wa.onet.pl
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Andrzej Stróżyński
Date: Mon, 21 Feb 2022 21:38
Date: Mon, 21 Feb 2022 21:38
33 lines
2769 bytes
2769 bytes
W dniu 2022-02-21 o 19:18, Alsor ZL pisze: > poniedziałek, 21 lutego 2022 o 16:23:23 UTC+1 Adam napisał(a): > >>> Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, >>> które mają tysiące punktów obsługi - w każdej mieścinie. >> Akurat banki i poczty mają stosunkowo małe bazy danych. >> Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest >> traktowane jako "duża" baza. > > dla mnie 100M czy 10000TB bez różnicy... Dla mnie to spora różnica > pytanie było: jak to jest zabezpieczane przed utratą. To zależy. Ważne, żeby skutecznie. > Dla małych możesz sobie kopiować co 5 minut, bo to trwałoby kilka sekund. > > A dla dużych, wielkich, i rozproszonych, no to ja tego w ogóle nie widzę. > > Pewnie tego w ogóle się nie zabezpiecza - jazda na żywioł. No jasne. > Pomijam jakieś tam lokalne kopie z automatu, co jest trzymane w tym samym miejscu - > i najpewniej na tym samym dysku... a przynajmniej: w jednym komputerze to siedzi; > bo po co nam kupować dwa? > > Awaria, pożar, spięcie, ktoś ukradnie... no to pójdzie wsio w kosmos - wraz z tym zapasem. Pierdolisz. -- pozdrawiam AS
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Mon, 21 Feb 2022 22:01
Date: Mon, 21 Feb 2022 22:01
25 lines
1834 bytes
1834 bytes
Dnia Mon, 21 Feb 2022 21:30:28 +0100, Cezary Grądys napisał(a): > W dniu 21.02.2022 o 16:23, Adam pisze: > >> >> Akurat banki i poczty mają stosunkowo małe bazy danych. >> Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest >> traktowane jako "duża" baza. >> > > Chyba coś ok 10 lat temu spotkałem się z opinią, że duza baza to taka co > milion wierszy dziennie przybywa ;) Ale teraz już jest nieco inaczej. Mam firmę, w której dziennie może przybyć tylko kilkaset wierszy, ale za to do bazy pompowane są binaria: fotki towarów, instrukcje, katalogi. Są to dane konieczne do prowadzenia sprzedaży internetowej. Taka baza może w kilka godzin przegonić bazę księgową z dziesięcioletnim stażem. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Tue, 22 Feb 2022 16:37
Date: Tue, 22 Feb 2022 16:37
40 lines
3371 bytes
3371 bytes
poniedziałek, 21 lutego 2022 o 22:39:02 UTC+1 Andrzej Stróżyński napisał(a): > W dniu 2022-02-21 o 19:18, Alsor ZL pisze: > > poniedziałek, 21 lutego 2022 o 16:23:23 UTC+1 Adam napisał(a): > > > >>> Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, > >>> które mają tysiące punktów obsługi - w każdej mieścinie. > >> Akurat banki i poczty mają stosunkowo małe bazy danych. > >> Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest > >> traktowane jako "duża" baza. > > > > dla mnie 100M czy 10000TB bez różnicy... > Dla mnie to spora różnica > > pytanie było: jak to jest zabezpieczane przed utratą. > To zależy. Ważne, żeby skutecznie. > > Dla małych możesz sobie kopiować co 5 minut, bo to trwałoby kilka sekund. > > > > A dla dużych, wielkich, i rozproszonych, no to ja tego w ogóle nie widzę. > > > > Pewnie tego w ogóle się nie zabezpiecza - jazda na żywioł. > No jasne. > > Pomijam jakieś tam lokalne kopie z automatu, co jest trzymane w tym samym miejscu - > > i najpewniej na tym samym dysku... a przynajmniej: w jednym komputerze to siedzi; > > bo po co nam kupować dwa? > > > > Awaria, pożar, spięcie, ktoś ukradnie... no to pójdzie wsio w kosmos - wraz z tym zapasem. > Pierdolisz. Dobrze wiemy jak to działa w praktyce: po awarii systemu... nie ma zapasu danych (bo niby po co to robić... to kosztuje!), który należało zabezpieczyć, więc co wtedy się dzieje? Wiadomo co: szefostwo tłumaczy się: mieliśmy zmasowany atak hakerów rosyjskich! No i szydło wyszło z wora: teraz już wiemy na czym polega ta... nowoczesna wojna cybernetyczna... :)
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Andrzej Stróżyński
Date: Wed, 23 Feb 2022 05:30
Date: Wed, 23 Feb 2022 05:30
48 lines
3605 bytes
3605 bytes
W dniu 2022-02-22 o 17:37, Alsor ZL pisze: > poniedziałek, 21 lutego 2022 o 22:39:02 UTC+1 Andrzej Stróżyński napisał(a): >> W dniu 2022-02-21 o 19:18, Alsor ZL pisze: >>> poniedziałek, 21 lutego 2022 o 16:23:23 UTC+1 Adam napisał(a): >>> >>>>> Pytam o te wielkie, np. urzędowe, albo firm typu bank, albo poczta, >>>>> które mają tysiące punktów obsługi - w każdej mieścinie. >>>> Akurat banki i poczty mają stosunkowo małe bazy danych. >>>> Cyba, że porównujemy z bazami danych jakiegoś sklepu, gdzie 20GB już jest >>>> traktowane jako "duża" baza. >>> >>> dla mnie 100M czy 10000TB bez różnicy... >> Dla mnie to spora różnica >>> pytanie było: jak to jest zabezpieczane przed utratą. >> To zależy. Ważne, żeby skutecznie. >>> Dla małych możesz sobie kopiować co 5 minut, bo to trwałoby kilka sekund. >>> >>> A dla dużych, wielkich, i rozproszonych, no to ja tego w ogóle nie widzę. >>> >>> Pewnie tego w ogóle się nie zabezpiecza - jazda na żywioł. >> No jasne. >>> Pomijam jakieś tam lokalne kopie z automatu, co jest trzymane w tym samym miejscu - >>> i najpewniej na tym samym dysku... a przynajmniej: w jednym komputerze to siedzi; >>> bo po co nam kupować dwa? >>> >>> Awaria, pożar, spięcie, ktoś ukradnie... no to pójdzie wsio w kosmos - wraz z tym zapasem. >> Pierdolisz. > > Dobrze wiemy jak to działa w praktyce: > po awarii systemu... nie ma zapasu danych (bo niby po co to robić... to kosztuje!), Piszesz z autopsji? Jeśli tak, to co tam jeszcze robisz? (no chyba, że to Twoja firma) > który należało zabezpieczyć, więc co wtedy się dzieje? > > Wiadomo co: > szefostwo tłumaczy się: mieliśmy zmasowany atak hakerów rosyjskich! jw > No i szydło wyszło z wora: > teraz już wiemy na czym polega ta... nowoczesna wojna cybernetyczna... :) -- pozdrawiam AS
Re: jak wygląda proces archiwizacji dużej bazy?
Author: geos
Date: Wed, 23 Feb 2022 22:31
Date: Wed, 23 Feb 2022 22:31
25 lines
2082 bytes
2082 bytes
On 18.02.2022 17:28, Alsor ZL wrote: > W dużych firmach jest sporo danych, > które należy zabezpieczyć przed utratą. > > Przykładowo mamy bazę 20 albo i 200GB, > i to codziennie rośnie... zmienia się, > więc trzeba to chyba archiwizować na bieżąco - codziennie. > > Baza jest nieustannie modyfikowana: 24h / dobę > przez wielu zdalnych pracowników, rozsianych nawet po całej Polsce, > albo i dalej... > > Zatem nie można tego zablokować np. na godzinę i sobie kopiować całość... do odtworzenia na wypadek awarii. > > Jak to jest realizowane w praktyce? u nas w firmie w weekend idzie backup, do którego wyłączają dostęp do bazy na niecałą godzinę. normalnie podczas pracy operacje są zapisywane w redo logach. nie siedzę w tym dokładnie ale w przypadku padu odtwarza się z ostatniego backupu a później z redo logów do momentu padu. pozdrawiam geos
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Thu, 24 Feb 2022 15:39
Date: Thu, 24 Feb 2022 15:39
39 lines
2303 bytes
2303 bytes
Dnia Wed, 23 Feb 2022 23:31:54 +0100, geos napisał(a): > On 18.02.2022 17:28, Alsor ZL wrote: >> W dużych firmach jest sporo danych, >> które należy zabezpieczyć przed utratą. >> >> Przykładowo mamy bazę 20 albo i 200GB, >> i to codziennie rośnie... zmienia się, >> więc trzeba to chyba archiwizować na bieżąco - codziennie. >> >> Baza jest nieustannie modyfikowana: 24h / dobę >> przez wielu zdalnych pracowników, rozsianych nawet po całej Polsce, >> albo i dalej... >> >> Zatem nie można tego zablokować np. na godzinę i sobie kopiować całość... do odtworzenia na wypadek awarii. >> >> Jak to jest realizowane w praktyce? > > u nas w firmie w weekend idzie backup, do którego wyłączają dostęp do > bazy na niecałą godzinę. > > normalnie podczas pracy operacje są zapisywane w redo logach. nie siedzę > w tym dokładnie ale w przypadku padu odtwarza się z ostatniego backupu a > później z redo logów do momentu padu. > Bardzo mnie ciekawi, dlaczego jest wyłączany dostęp do bazy na czas backupu. W windowsach "od zawsze" nie potrzeba zatrzymywać bazy danych SQL (a przynajmniej MS-SQL) do backupu. Chyba, że to jeszcze coś w rodzaju Pervasive, albo bazy siedzą na Netware 5.0 ;) W Windowsach daje się robić backup w locie od jakiejś wersji 2003, a w linuksach też "od zawsze" jest rsync i inne narzędzia, nie wymagające zatrzymania plików. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: geos
Date: Thu, 24 Feb 2022 22:29
Date: Thu, 24 Feb 2022 22:29
8 lines
1464 bytes
1464 bytes
On 24.02.2022 16:39, Adam wrote: > Bardzo mnie ciekawi, dlaczego jest wyłączany dostęp do bazy na czas > backupu. odpowiedź jest prosta: bo tak wolą robić backupy. robią tzw. zimny backup. pozdrawiam geos
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Cezary Grądys
Date: Sat, 26 Feb 2022 11:50
Date: Sat, 26 Feb 2022 11:50
15 lines
1482 bytes
1482 bytes
W dniu 24.02.2022 o 23:29, geos pisze: > odpowiedź jest prosta: bo tak wolą robić backupy. robią tzw. zimny backup. > > pozdrawiam > geos No i pewnie jest taka możliwość, że może ta baza być niedostępna. -- Cezary Grądys czarekgr@wa.onet.pl
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Sun, 27 Feb 2022 14:52
Date: Sun, 27 Feb 2022 14:52
31 lines
2604 bytes
2604 bytes
środa, 23 lutego 2022 o 23:31:57 UTC+1 geos napisał(a): > On 18.02.2022 17:28, Alsor ZL wrote: > > W dużych firmach jest sporo danych, > > które należy zabezpieczyć przed utratą. > > > > Przykładowo mamy bazę 20 albo i 200GB, > > i to codziennie rośnie... zmienia się, > > więc trzeba to chyba archiwizować na bieżąco - codziennie. > > > > Baza jest nieustannie modyfikowana: 24h / dobę > > przez wielu zdalnych pracowników, rozsianych nawet po całej Polsce, > > albo i dalej... > > > > Zatem nie można tego zablokować np. na godzinę i sobie kopiować całość... do odtworzenia na wypadek awarii. > > > > Jak to jest realizowane w praktyce? > u nas w firmie w weekend idzie backup, do którego wyłączają dostęp do > bazy na niecałą godzinę. > > normalnie podczas pracy operacje są zapisywane w redo logach. nie siedzę > w tym dokładnie ale w przypadku padu odtwarza się z ostatniego backupu a > później z redo logów do momentu padu. > > pozdrawiam > geos A jaki ma rozmiar ta baza? dla kopiowania na bele jakim SSD: 100 MB/s minimum. 3600s x 100 MB/s = 360000 MB = 360 GB.
Re: jak wygląda proces archiwizacji dużej bazy?
Author: geos
Date: Sun, 27 Feb 2022 19:17
Date: Sun, 27 Feb 2022 19:17
7 lines
1394 bytes
1394 bytes
On 27.02.2022 15:52, Alsor ZL wrote: > A jaki ma rozmiar ta baza? ok. 21TB pozdrawiam geos
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Tue, 01 Mar 2022 02:38
Date: Tue, 01 Mar 2022 02:38
19 lines
2181 bytes
2181 bytes
niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > On 27.02.2022 15:52, Alsor ZL wrote: > > A jaki ma rozmiar ta baza? > ok. 21TB > > pozdrawiam > geos chyba pomyliłeś literki: 21GB. dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. zresztą nie macie takich dysków... aby to pomieścić. szybkość waszych kopiarek: 21/360 x 100 = 6 MB/s i tak nieźle... jak na pendrive z 1 generacji. :) Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: G, T, a może masz Peta w mordzie, co?
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Tue, 01 Mar 2022 09:33
Date: Tue, 01 Mar 2022 09:33
31 lines
1800 bytes
1800 bytes
Dnia Mon, 28 Feb 2022 18:38:02 -0800 (PST), Alsor ZL napisał(a): > niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >> On 27.02.2022 15:52, Alsor ZL wrote: >>> A jaki ma rozmiar ta baza? >> ok. 21TB >> >> pozdrawiam >> geos > > chyba pomyliłeś literki: 21GB. > > dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > zresztą nie macie takich dysków... aby to pomieścić. > > szybkość waszych kopiarek: > 21/360 x 100 = 6 MB/s > i tak nieźle... jak na pendrive z 1 generacji. :) > > Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > G, T, a może masz Peta w mordzie, co? Mój pierwszy pendrive - 16 MB. Jaki on wtedy był duży :) Całe pudełko dyskietek w jednym "gwizdku". -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: geos
Date: Tue, 01 Mar 2022 09:38
Date: Tue, 01 Mar 2022 09:38
28 lines
2117 bytes
2117 bytes
On 01.03.2022 03:38, Alsor ZL wrote: > niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >> On 27.02.2022 15:52, Alsor ZL wrote: >>> A jaki ma rozmiar ta baza? >> ok. 21TB >> >> pozdrawiam >> geos > > chyba pomyliłeś literki: 21GB. > > dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > zresztą nie macie takich dysków... aby to pomieścić. > > szybkość waszych kopiarek: > 21/360 x 100 = 6 MB/s > i tak nieźle... jak na pendrive z 1 generacji. :) > > Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > G, T, a może masz Peta w mordzie, co? nie pomyliłem jednostek. daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim świecie żyję. geos
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Tue, 01 Mar 2022 21:21
Date: Tue, 01 Mar 2022 21:21
41 lines
2269 bytes
2269 bytes
Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): > On 01.03.2022 03:38, Alsor ZL wrote: >> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >>> On 27.02.2022 15:52, Alsor ZL wrote: >>>> A jaki ma rozmiar ta baza? >>> ok. 21TB >>> >>> pozdrawiam >>> geos >> >> chyba pomyliłeś literki: 21GB. >> >> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. >> zresztą nie macie takich dysków... aby to pomieścić. >> >> szybkość waszych kopiarek: >> 21/360 x 100 = 6 MB/s >> i tak nieźle... jak na pendrive z 1 generacji. :) >> >> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: >> G, T, a może masz Peta w mordzie, co? > > nie pomyliłem jednostek. > > daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > świecie żyję. > U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma jednostkami bezdyskowymi i z macierzami SAN. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Tue, 01 Mar 2022 22:35
Date: Tue, 01 Mar 2022 22:35
36 lines
2907 bytes
2907 bytes
wtorek, 1 marca 2022 o 10:38:16 UTC+1 geos napisał(a): > On 01.03.2022 03:38, Alsor ZL wrote: > > niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > >> On 27.02.2022 15:52, Alsor ZL wrote: > >>> A jaki ma rozmiar ta baza? > >> ok. 21TB > >> > >> pozdrawiam > >> geos > > > > chyba pomyliłeś literki: 21GB. > > > > dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > > zresztą nie macie takich dysków... aby to pomieścić. > > > > szybkość waszych kopiarek: > > 21/360 x 100 = 6 MB/s > > i tak nieźle... jak na pendrive z 1 generacji. :) > > > > Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > > G, T, a może masz Peta w mordzie, co? > nie pomyliłem jednostek. > > daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > świecie żyję. > > geos Jasne... a po kompresji zipem jest tego raptem... z 600MB, czyli klasyczny krążek CD. hihi! dużo powierza trzymacie.. chyba wam tam strasznie duszno jest - co? haha! a te hurtowe loginy robocze zajmują... z 3TB ... z 1 dnia pracy - zgadłem? ale tego nie archiwizujesz... chyba, co?
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Tue, 01 Mar 2022 22:39
Date: Tue, 01 Mar 2022 22:39
50 lines
3235 bytes
3235 bytes
wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): > Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): > > > On 01.03.2022 03:38, Alsor ZL wrote: > >> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > >>> On 27.02.2022 15:52, Alsor ZL wrote: > >>>> A jaki ma rozmiar ta baza? > >>> ok. 21TB > >>> > >>> pozdrawiam > >>> geos > >> > >> chyba pomyliłeś literki: 21GB. > >> > >> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > >> zresztą nie macie takich dysków... aby to pomieścić. > >> > >> szybkość waszych kopiarek: > >> 21/360 x 100 = 6 MB/s > >> i tak nieźle... jak na pendrive z 1 generacji. :) > >> > >> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > >> G, T, a może masz Peta w mordzie, co? > > > > nie pomyliłem jednostek. > > > > daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > > raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > > świecie żyję. > > > U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. > Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. > > Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma > jednostkami bezdyskowymi i z macierzami SAN. > > > -- > Pozdrawiam. > > Adam z pewnością... tylko skąd tyle tych danych weźmiesz? aha... z biblioteki publiczne - z UJ? 1 książka = 1MB zapisz sobie milion książek a otrzymasz... raptem 1TB,! Luuuuuuuudzie, o czym wy gadacie!
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Wed, 02 Mar 2022 09:56
Date: Wed, 02 Mar 2022 09:56
78 lines
4030 bytes
4030 bytes
Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): > wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): >> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): >> >>> On 01.03.2022 03:38, Alsor ZL wrote: >>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >>>>> On 27.02.2022 15:52, Alsor ZL wrote: >>>>>> A jaki ma rozmiar ta baza? >>>>> ok. 21TB >>>>> >>>>> pozdrawiam >>>>> geos >>>> >>>> chyba pomyliłeś literki: 21GB. >>>> >>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. >>>> zresztą nie macie takich dysków... aby to pomieścić. >>>> >>>> szybkość waszych kopiarek: >>>> 21/360 x 100 = 6 MB/s >>>> i tak nieźle... jak na pendrive z 1 generacji. :) >>>> >>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: >>>> G, T, a może masz Peta w mordzie, co? >>> >>> nie pomyliłem jednostek. >>> >>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to >>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim >>> świecie żyję. >>> >> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. >> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. >> >> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma >> jednostkami bezdyskowymi i z macierzami SAN. >> >> -- >> Pozdrawiam. >> >> Adam > > z pewnością... > tylko skąd tyle tych danych weźmiesz? > aha... z biblioteki publiczne - z UJ? > > 1 książka = 1MB > zapisz sobie milion książek a otrzymasz... raptem 1TB,! > > Luuuuuuuudzie, o czym wy gadacie! O czym Ty gadasz? Jedno fotka to czasem kilka MB. Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. A na hostingu siedzi kilkadziesiąt takich witryn. A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często zajmują kolejne dziesiątki MB. Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy kilkaset faktur, to dziennie mogą przybywać duże gigabajty. Same serwery pocztowe zajmują wiele TB. Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko pilkaset GB, a mieć alokację jeszcze większą. Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się każdy bajt w polu. Serwery teraz to nie tylko prosty program w Clipperze. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Tomek
Date: Wed, 02 Mar 2022 11:55
Date: Wed, 02 Mar 2022 11:55
12 lines
2008 bytes
2008 bytes
W dniu 01.03.2022 o 23:35, Alsor ZL pisze: > wtorek, 1 marca 2022 o 10:38:16 UTC+1 geos napisał(a): > Jasne... > a po kompresji zipem jest tego raptem... z 600MB, czyli klasyczny krążek CD. hihi! > > dużo powierza trzymacie.. chyba wam tam strasznie duszno jest - co? haha! > To skompresuj obrazek JPG i zobacz ile powietrza z niego ujdzie. Ale trzymanie takich blobów (obrazki) w bazie, jak dla mnie, to słaby pomysł - więcej wad niż zalet.
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor ZL
Date: Wed, 02 Mar 2022 14:49
Date: Wed, 02 Mar 2022 14:49
92 lines
5433 bytes
5433 bytes
środa, 2 marca 2022 o 10:56:36 UTC+1 Adam napisał(a): > Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): > > > wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): > >> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): > >> > >>> On 01.03.2022 03:38, Alsor ZL wrote: > >>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > >>>>> On 27.02.2022 15:52, Alsor ZL wrote: > >>>>>> A jaki ma rozmiar ta baza? > >>>>> ok. 21TB > >>>>> > >>>>> pozdrawiam > >>>>> geos > >>>> > >>>> chyba pomyliłeś literki: 21GB. > >>>> > >>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > >>>> zresztą nie macie takich dysków... aby to pomieścić. > >>>> > >>>> szybkość waszych kopiarek: > >>>> 21/360 x 100 = 6 MB/s > >>>> i tak nieźle... jak na pendrive z 1 generacji. :) > >>>> > >>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > >>>> G, T, a może masz Peta w mordzie, co? > >>> > >>> nie pomyliłem jednostek. > >>> > >>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > >>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > >>> świecie żyję. > >>> > >> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. > >> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. > >> > >> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma > >> jednostkami bezdyskowymi i z macierzami SAN. > >> > >> -- > >> Pozdrawiam. > >> > >> Adam > > > > z pewnością... > > tylko skąd tyle tych danych weźmiesz? > > aha... z biblioteki publiczne - z UJ? > > > > 1 książka = 1MB > > zapisz sobie milion książek a otrzymasz... raptem 1TB,! > > > > Luuuuuuuudzie, o czym wy gadacie! > O czym Ty gadasz? > Jedno fotka to czasem kilka MB. > Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. > A na hostingu siedzi kilkadziesiąt takich witryn. > A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są > dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi > nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często > zajmują kolejne dziesiątki MB. > Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów > przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo > do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla > większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy > kilkaset faktur, to dziennie mogą przybywać duże gigabajty. > Same serwery pocztowe zajmują wiele TB. > Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko > pilkaset GB, a mieć alokację jeszcze większą. > > Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się > każdy bajt w polu. > Serwery teraz to nie tylko prosty program w Clipperze. > > > -- > Pozdrawiam. > > Adam wiem że robicie to na 'wariata' - obrazki zamiast to przetworzyć na tekst, kontury, itd. Epoka Big Data polega właśnie na gromadzeniu śmieci... a dlaczego? bo sprzęt urósł, więc pozwala na takie... kretyńskie praktyki! Potem ktoś twierdzi że ma potężne bazy - w TB, albo w Petach! Bzdura! Wym siedzi zaledwie kilkaset MB zazwyczaj, bo redundancja wynosi = 99.99999999%. Filmy: 2 godziny x 24 fps x obrazek 1000 x 1000 x rgb = ? gdyby to tak wprost zapisywać, wtedy jeden film zajmowałby ... cały ten wasz serwerek by nie wyrobił!
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Wed, 02 Mar 2022 18:15
Date: Wed, 02 Mar 2022 18:15
110 lines
6188 bytes
6188 bytes
Dnia Wed, 2 Mar 2022 06:49:13 -0800 (PST), Alsor ZL napisał(a): > środa, 2 marca 2022 o 10:56:36 UTC+1 Adam napisał(a): >> Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): >> >>> wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): >>>> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): >>>> >>>>> On 01.03.2022 03:38, Alsor ZL wrote: >>>>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >>>>>>> On 27.02.2022 15:52, Alsor ZL wrote: >>>>>>>> A jaki ma rozmiar ta baza? >>>>>>> ok. 21TB >>>>>>> >>>>>>> pozdrawiam >>>>>>> geos >>>>>> >>>>>> chyba pomyliłeś literki: 21GB. >>>>>> >>>>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. >>>>>> zresztą nie macie takich dysków... aby to pomieścić. >>>>>> >>>>>> szybkość waszych kopiarek: >>>>>> 21/360 x 100 = 6 MB/s >>>>>> i tak nieźle... jak na pendrive z 1 generacji. :) >>>>>> >>>>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: >>>>>> G, T, a może masz Peta w mordzie, co? >>>>> >>>>> nie pomyliłem jednostek. >>>>> >>>>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to >>>>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim >>>>> świecie żyję. >>>>> >>>> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. >>>> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. >>>> >>>> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma >>>> jednostkami bezdyskowymi i z macierzami SAN. >>>> >>>> -- >>>> Pozdrawiam. >>>> >>>> Adam >>> >>> z pewnością... >>> tylko skąd tyle tych danych weźmiesz? >>> aha... z biblioteki publiczne - z UJ? >>> >>> 1 książka = 1MB >>> zapisz sobie milion książek a otrzymasz... raptem 1TB,! >>> >>> Luuuuuuuudzie, o czym wy gadacie! >> O czym Ty gadasz? >> Jedno fotka to czasem kilka MB. >> Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. >> A na hostingu siedzi kilkadziesiąt takich witryn. >> A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są >> dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi >> nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często >> zajmują kolejne dziesiątki MB. >> Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów >> przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo >> do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla >> większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy >> kilkaset faktur, to dziennie mogą przybywać duże gigabajty. >> Same serwery pocztowe zajmują wiele TB. >> Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko >> pilkaset GB, a mieć alokację jeszcze większą. >> >> Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się >> każdy bajt w polu. >> Serwery teraz to nie tylko prosty program w Clipperze. >> >> -- >> Pozdrawiam. >> >> Adam > > wiem że robicie to na 'wariata' - obrazki zamiast to przetworzyć na tekst, kontury, itd. > Jeżeli masz na myśli OCR faktur, to chyba nie wiesz, o czym rozmawiasz. Owszem, nie ma potrzeby już od roku 2014 podpisywać faktur, nie ma pieczątek. Ale są inne przepisy, nie tylko w ustawie o rachunkowości, ale też i w kodeksie cywilnym. Nie każda firma korzysta z ECOD/EDI, gdzie już od wielu lat niczego się nie drukuje, a cała wymiana różnych dokumentów jest wyłącznie eketroniczna. Są więc jeszcze w tym roku faktury papierowe, choćby na stacjach paliw. Stertę tych faktur wrzuca się do podajnika skanera, skaner to wysyła do systemu OCR i owszem, faktura jest czytana przez dość inteligentny system, mający całą masę algorytmów, aby na różnych fakturach różnie drukowanych znaleźć m.in. datę dostawy/wykonania usługi, datę sprzedaży (albo tylko miesiąc dla usług ciągłych), odróżnić nabywcę od odbiorcy, wyłuskać, czy faktura jest od netto czy brutto, odróżnić kod EAN od kodu produktu, odróżnić VAT od rabatu, odróżnić nazwę towaru od jego cech zwłaszcza przy pozycjach wielolinijkowych itd itp. Ale też ze względu na inne przepisy niż rozporządzenie w sprawie faktur, należy przechowywać albo fakturę papierową albo jej obraz, nie zmodyfikowany i nie zmieniony. Ponadto obraz ten jest przydatny do weryfikacji rej. vat w księgowości, gdy algorytm OCR zgłosi nieprawidłowość, albo faktura jest "bardziej" księgowana, np. przez krąg kosztów. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: DarekPn
Date: Wed, 02 Mar 2022 19:14
Date: Wed, 02 Mar 2022 19:14
20 lines
2416 bytes
2416 bytes
W dniu 02.03.2022 o 12:55, Tomek pisze: > W dniu 01.03.2022 o 23:35, Alsor ZL pisze: >> wtorek, 1 marca 2022 o 10:38:16 UTC+1 geos napisał(a): >> Jasne... >> a po kompresji zipem jest tego raptem... z 600MB, czyli klasyczny >> krążek CD. hihi! >> >> dużo powierza trzymacie.. chyba wam tam strasznie duszno jest - co? haha! >> > > To skompresuj obrazek JPG i zobacz ile powietrza z niego ujdzie. > > Ale trzymanie takich blobów (obrazki) w bazie, jak dla mnie, to słaby > pomysł - więcej wad niż zalet. Szkoda czasu na karmienie trolla. Chyba go pamiętam... -- Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast. https://www.avast.com/antivirus
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor
Date: Wed, 02 Mar 2022 21:44
Date: Wed, 02 Mar 2022 21:44
133 lines
7422 bytes
7422 bytes
środa, 2 marca 2022 o 19:15:24 UTC+1 Adam napisał(a): > Dnia Wed, 2 Mar 2022 06:49:13 -0800 (PST), Alsor ZL napisał(a): > > > środa, 2 marca 2022 o 10:56:36 UTC+1 Adam napisał(a): > >> Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): > >> > >>> wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): > >>>> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): > >>>> > >>>>> On 01.03.2022 03:38, Alsor ZL wrote: > >>>>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > >>>>>>> On 27.02.2022 15:52, Alsor ZL wrote: > >>>>>>>> A jaki ma rozmiar ta baza? > >>>>>>> ok. 21TB > >>>>>>> > >>>>>>> pozdrawiam > >>>>>>> geos > >>>>>> > >>>>>> chyba pomyliłeś literki: 21GB. > >>>>>> > >>>>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > >>>>>> zresztą nie macie takich dysków... aby to pomieścić. > >>>>>> > >>>>>> szybkość waszych kopiarek: > >>>>>> 21/360 x 100 = 6 MB/s > >>>>>> i tak nieźle... jak na pendrive z 1 generacji. :) > >>>>>> > >>>>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > >>>>>> G, T, a może masz Peta w mordzie, co? > >>>>> > >>>>> nie pomyliłem jednostek. > >>>>> > >>>>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > >>>>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > >>>>> świecie żyję. > >>>>> > >>>> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. > >>>> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. > >>>> > >>>> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma > >>>> jednostkami bezdyskowymi i z macierzami SAN. > >>>> > >>>> -- > >>>> Pozdrawiam. > >>>> > >>>> Adam > >>> > >>> z pewnością... > >>> tylko skąd tyle tych danych weźmiesz? > >>> aha... z biblioteki publiczne - z UJ? > >>> > >>> 1 książka = 1MB > >>> zapisz sobie milion książek a otrzymasz... raptem 1TB,! > >>> > >>> Luuuuuuuudzie, o czym wy gadacie! > >> O czym Ty gadasz? > >> Jedno fotka to czasem kilka MB. > >> Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. > >> A na hostingu siedzi kilkadziesiąt takich witryn. > >> A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są > >> dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi > >> nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często > >> zajmują kolejne dziesiątki MB. > >> Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów > >> przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo > >> do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla > >> większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy > >> kilkaset faktur, to dziennie mogą przybywać duże gigabajty. > >> Same serwery pocztowe zajmują wiele TB. > >> Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko > >> pilkaset GB, a mieć alokację jeszcze większą. > >> > >> Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się > >> każdy bajt w polu. > >> Serwery teraz to nie tylko prosty program w Clipperze. > >> > >> -- > >> Pozdrawiam. > >> > >> Adam > > > > wiem że robicie to na 'wariata' - obrazki zamiast to przetworzyć na tekst, kontury, itd. > > > Jeżeli masz na myśli OCR faktur, to chyba nie wiesz, o czym rozmawiasz. > Owszem, nie ma potrzeby już od roku 2014 podpisywać faktur, nie ma > pieczątek. Ale są inne przepisy, nie tylko w ustawie o rachunkowości, ale > też i w kodeksie cywilnym. > Nie każda firma korzysta z ECOD/EDI, gdzie już od wielu lat niczego się nie > drukuje, a cała wymiana różnych dokumentów jest wyłącznie eketroniczna. Są > więc jeszcze w tym roku faktury papierowe, choćby na stacjach paliw. > Stertę tych faktur wrzuca się do podajnika skanera, skaner to wysyła do > systemu OCR i owszem, faktura jest czytana przez dość inteligentny system, > mający całą masę algorytmów, aby na różnych fakturach różnie drukowanych > znaleźć m.in. datę dostawy/wykonania usługi, datę sprzedaży (albo tylko > miesiąc dla usług ciągłych), odróżnić nabywcę od odbiorcy, wyłuskać, czy > faktura jest od netto czy brutto, odróżnić kod EAN od kodu produktu, > odróżnić VAT od rabatu, odróżnić nazwę towaru od jego cech zwłaszcza przy > pozycjach wielolinijkowych itd itp. > Ale też ze względu na inne przepisy niż rozporządzenie w sprawie faktur, > należy przechowywać albo fakturę papierową albo jej obraz, nie > zmodyfikowany i nie zmieniony. > Ponadto obraz ten jest przydatny do weryfikacji rej. vat w księgowości, gdy > algorytm OCR zgłosi nieprawidłowość, albo faktura jest "bardziej" > księgowana, np. przez krąg kosztów. > > > -- > Pozdrawiam. > > Adam Bzdury opowiadasz. pamiętam starego kumpla... sprzed 25 lat ! On mówił wtedy tak (ignorant z informatyki!): - po co mi te faktury drukują! - niech mi to prześlą prosto do mojej bazy - programu księgowego, itd. śmiałem się wtedy z jego pomysłów, bo wiedziałem że to nie ta... epoka. no ale miał rację, niestety... a ta epoka już dawno nastała! Teraz już możesz wysyłać... dokładnie jak on to mówił. Ale wy tego nadal nie robicie... dlaczego? bo jesteście zacofani - żyjecie ciągle w czasach 1990r. Powodzenia w przeszłości.
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Adam
Date: Wed, 02 Mar 2022 22:07
Date: Wed, 02 Mar 2022 22:07
159 lines
8134 bytes
8134 bytes
Dnia Wed, 2 Mar 2022 13:44:45 -0800 (PST), Alsor napisał(a): > środa, 2 marca 2022 o 19:15:24 UTC+1 Adam napisał(a): >> Dnia Wed, 2 Mar 2022 06:49:13 -0800 (PST), Alsor ZL napisał(a): >> >>> środa, 2 marca 2022 o 10:56:36 UTC+1 Adam napisał(a): >>>> Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): >>>> >>>>> wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): >>>>>> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): >>>>>> >>>>>>> On 01.03.2022 03:38, Alsor ZL wrote: >>>>>>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): >>>>>>>>> On 27.02.2022 15:52, Alsor ZL wrote: >>>>>>>>>> A jaki ma rozmiar ta baza? >>>>>>>>> ok. 21TB >>>>>>>>> >>>>>>>>> pozdrawiam >>>>>>>>> geos >>>>>>>> >>>>>>>> chyba pomyliłeś literki: 21GB. >>>>>>>> >>>>>>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. >>>>>>>> zresztą nie macie takich dysków... aby to pomieścić. >>>>>>>> >>>>>>>> szybkość waszych kopiarek: >>>>>>>> 21/360 x 100 = 6 MB/s >>>>>>>> i tak nieźle... jak na pendrive z 1 generacji. :) >>>>>>>> >>>>>>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: >>>>>>>> G, T, a może masz Peta w mordzie, co? >>>>>>> >>>>>>> nie pomyliłem jednostek. >>>>>>> >>>>>>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to >>>>>>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim >>>>>>> świecie żyję. >>>>>>> >>>>>> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. >>>>>> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. >>>>>> >>>>>> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma >>>>>> jednostkami bezdyskowymi i z macierzami SAN. >>>>>> >>>>>> -- >>>>>> Pozdrawiam. >>>>>> >>>>>> Adam >>>>> >>>>> z pewnością... >>>>> tylko skąd tyle tych danych weźmiesz? >>>>> aha... z biblioteki publiczne - z UJ? >>>>> >>>>> 1 książka = 1MB >>>>> zapisz sobie milion książek a otrzymasz... raptem 1TB,! >>>>> >>>>> Luuuuuuuudzie, o czym wy gadacie! >>>> O czym Ty gadasz? >>>> Jedno fotka to czasem kilka MB. >>>> Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. >>>> A na hostingu siedzi kilkadziesiąt takich witryn. >>>> A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są >>>> dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi >>>> nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często >>>> zajmują kolejne dziesiątki MB. >>>> Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów >>>> przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo >>>> do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla >>>> większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy >>>> kilkaset faktur, to dziennie mogą przybywać duże gigabajty. >>>> Same serwery pocztowe zajmują wiele TB. >>>> Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko >>>> pilkaset GB, a mieć alokację jeszcze większą. >>>> >>>> Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się >>>> każdy bajt w polu. >>>> Serwery teraz to nie tylko prosty program w Clipperze. >>>> >>>> -- >>>> Pozdrawiam. >>>> >>>> Adam >>> >>> wiem że robicie to na 'wariata' - obrazki zamiast to przetworzyć na tekst, kontury, itd. >>> >> Jeżeli masz na myśli OCR faktur, to chyba nie wiesz, o czym rozmawiasz. >> Owszem, nie ma potrzeby już od roku 2014 podpisywać faktur, nie ma >> pieczątek. Ale są inne przepisy, nie tylko w ustawie o rachunkowości, ale >> też i w kodeksie cywilnym. >> Nie każda firma korzysta z ECOD/EDI, gdzie już od wielu lat niczego się nie >> drukuje, a cała wymiana różnych dokumentów jest wyłącznie eketroniczna. Są >> więc jeszcze w tym roku faktury papierowe, choćby na stacjach paliw. >> Stertę tych faktur wrzuca się do podajnika skanera, skaner to wysyła do >> systemu OCR i owszem, faktura jest czytana przez dość inteligentny system, >> mający całą masę algorytmów, aby na różnych fakturach różnie drukowanych >> znaleźć m.in. datę dostawy/wykonania usługi, datę sprzedaży (albo tylko >> miesiąc dla usług ciągłych), odróżnić nabywcę od odbiorcy, wyłuskać, czy >> faktura jest od netto czy brutto, odróżnić kod EAN od kodu produktu, >> odróżnić VAT od rabatu, odróżnić nazwę towaru od jego cech zwłaszcza przy >> pozycjach wielolinijkowych itd itp. >> Ale też ze względu na inne przepisy niż rozporządzenie w sprawie faktur, >> należy przechowywać albo fakturę papierową albo jej obraz, nie >> zmodyfikowany i nie zmieniony. >> Ponadto obraz ten jest przydatny do weryfikacji rej. vat w księgowości, gdy >> algorytm OCR zgłosi nieprawidłowość, albo faktura jest "bardziej" >> księgowana, np. przez krąg kosztów. >> >> -- >> Pozdrawiam. >> >> Adam > > Bzdury opowiadasz. > > pamiętam starego kumpla... sprzed 25 lat ! > > On mówił wtedy tak (ignorant z informatyki!): > > - po co mi te faktury drukują! > - niech mi to prześlą prosto do mojej bazy - programu księgowego, itd. > > śmiałem się wtedy z jego pomysłów, bo wiedziałem że to nie ta... epoka. > > no ale miał rację, niestety... > > a ta epoka już dawno nastała! > > Teraz już możesz wysyłać... dokładnie jak on to mówił. > > Ale wy tego nadal nie robicie... > dlaczego? > bo jesteście zacofani - żyjecie ciągle w czasach 1990r. > > Powodzenia w przeszłości. Ale masz coś konstruktywnego do powiedzenia? Pierwsze transmisje na modemach 2400 i 9600 ustawiałem w sklepach samochodowych gdzieś na przełomie lat 80/90-tych. Było to połączenie do FSO albo FSM. Już wtedy były transmitowane dokumenty, głównie zamówienia. Standard EDI/ECOD ma już sporo ponad 20 lat, jest jednolity w wielu krajach Europy. W roku bieżącym fakultatywnie są e-faktury, od roku 2023 mają być obligatoryjnie. Natomiast niektóre banki czy sądy do tej pory nie uznają maili. Ja pierwszego maila miałem gdzieś końcem lat 80-tych, bodajże w sieci fido. Wtedy mało kto jeszcze słyszał o BBS-ach, internet zaczął wchodzić kilka lat później. Nie wiem, o co Ci chodzi, ale widzę, że dyskusja z Tobą to chyba marnowanie czasu. -- Pozdrawiam. Adam
Re: jak wygląda proces archiwizacji dużej bazy?
Author: Alsor
Date: Thu, 03 Mar 2022 18:57
Date: Thu, 03 Mar 2022 18:57
164 lines
9386 bytes
9386 bytes
środa, 2 marca 2022 o 23:07:57 UTC+1 Adam napisał(a): > Dnia Wed, 2 Mar 2022 13:44:45 -0800 (PST), Alsor napisał(a): > > > środa, 2 marca 2022 o 19:15:24 UTC+1 Adam napisał(a): > >> Dnia Wed, 2 Mar 2022 06:49:13 -0800 (PST), Alsor ZL napisał(a): > >> > >>> środa, 2 marca 2022 o 10:56:36 UTC+1 Adam napisał(a): > >>>> Dnia Tue, 1 Mar 2022 14:39:07 -0800 (PST), Alsor ZL napisał(a): > >>>> > >>>>> wtorek, 1 marca 2022 o 22:21:57 UTC+1 Adam napisał(a): > >>>>>> Dnia Tue, 1 Mar 2022 10:38:12 +0100, geos napisał(a): > >>>>>> > >>>>>>> On 01.03.2022 03:38, Alsor ZL wrote: > >>>>>>>> niedziela, 27 lutego 2022 o 20:17:27 UTC+1 geos napisał(a): > >>>>>>>>> On 27.02.2022 15:52, Alsor ZL wrote: > >>>>>>>>>> A jaki ma rozmiar ta baza? > >>>>>>>>> ok. 21TB > >>>>>>>>> > >>>>>>>>> pozdrawiam > >>>>>>>>> geos > >>>>>>>> > >>>>>>>> chyba pomyliłeś literki: 21GB. > >>>>>>>> > >>>>>>>> dla 21TB nie skopiowałbyś tego na żadnym sprzęcie w rozsądny, czasie. > >>>>>>>> zresztą nie macie takich dysków... aby to pomieścić. > >>>>>>>> > >>>>>>>> szybkość waszych kopiarek: > >>>>>>>> 21/360 x 100 = 6 MB/s > >>>>>>>> i tak nieźle... jak na pendrive z 1 generacji. :) > >>>>>>>> > >>>>>>>> Luuuuuuuuuuudie. wy nie macie pojęcia w jakim świecie żyjecie: > >>>>>>>> G, T, a może masz Peta w mordzie, co? > >>>>>>> > >>>>>>> nie pomyliłem jednostek. > >>>>>>> > >>>>>>> daruj sobie takie dalsze teksty. to nie ta grupa. nie ruszają mnie, to > >>>>>>> raz, a dwa to raczej ty nie masz pojęcia zielonego o tej bazie i w jakim > >>>>>>> świecie żyję. > >>>>>>> > >>>>>> U mnie w firmie podobne wielkości mają niektóre z maszyn wirtualnych. > >>>>>> Jakoś się kopiują i miejsca na backupy w innej lokalizacji starcza. > >>>>>> > >>>>>> Serwery to nie tylko jakaś jedna maszyna, teraz to może być szafa z kilkoma > >>>>>> jednostkami bezdyskowymi i z macierzami SAN. > >>>>>> > >>>>>> -- > >>>>>> Pozdrawiam. > >>>>>> > >>>>>> Adam > >>>>> > >>>>> z pewnością... > >>>>> tylko skąd tyle tych danych weźmiesz? > >>>>> aha... z biblioteki publiczne - z UJ? > >>>>> > >>>>> 1 książka = 1MB > >>>>> zapisz sobie milion książek a otrzymasz... raptem 1TB,! > >>>>> > >>>>> Luuuuuuuudzie, o czym wy gadacie! > >>>> O czym Ty gadasz? > >>>> Jedno fotka to czasem kilka MB. > >>>> Fotek kilkadziesiąt na jednej stronie, stron kilkaset na jednej witrynie. > >>>> A na hostingu siedzi kilkadziesiąt takich witryn. > >>>> A są np. jeszcze witryny techniczne, gdzie jest sporo materiałów video, są > >>>> dość opasłe instrukcje w PDF. Owszem, te instrukcje są tworzone przez ludzi > >>>> nie mających wiedzy poligraficznej, umiejętności ani narzędzi, więc często > >>>> zajmują kolejne dziesiątki MB. > >>>> Do tego bazy firmowe, gdzie normą w tej chwili jest przerzucanie dokumentów > >>>> przez OCR, celem automatycznego przetwarzania np. do rejestrów zakupu albo > >>>> do FZ. A jeśli jest to biuro rachunkowe mające ok. 300 klientów, a dla > >>>> większości z tych klientów dziennie przetwarza się po kilkadziesiąt czy > >>>> kilkaset faktur, to dziennie mogą przybywać duże gigabajty. > >>>> Same serwery pocztowe zajmują wiele TB. > >>>> Są skrzynki obsługiwane przez IMAP, gdzie jedno konto potrafi zajmować ko > >>>> pilkaset GB, a mieć alokację jeszcze większą. > >>>> > >>>> Minęły już czasy prostych relacyjnych baz danych w dBase, gdzie liczył się > >>>> każdy bajt w polu. > >>>> Serwery teraz to nie tylko prosty program w Clipperze. > >>>> > >>>> -- > >>>> Pozdrawiam. > >>>> > >>>> Adam > >>> > >>> wiem że robicie to na 'wariata' - obrazki zamiast to przetworzyć na tekst, kontury, itd. > >>> > >> Jeżeli masz na myśli OCR faktur, to chyba nie wiesz, o czym rozmawiasz. > >> Owszem, nie ma potrzeby już od roku 2014 podpisywać faktur, nie ma > >> pieczątek. Ale są inne przepisy, nie tylko w ustawie o rachunkowości, ale > >> też i w kodeksie cywilnym. > >> Nie każda firma korzysta z ECOD/EDI, gdzie już od wielu lat niczego się nie > >> drukuje, a cała wymiana różnych dokumentów jest wyłącznie eketroniczna. Są > >> więc jeszcze w tym roku faktury papierowe, choćby na stacjach paliw. > >> Stertę tych faktur wrzuca się do podajnika skanera, skaner to wysyła do > >> systemu OCR i owszem, faktura jest czytana przez dość inteligentny system, > >> mający całą masę algorytmów, aby na różnych fakturach różnie drukowanych > >> znaleźć m.in. datę dostawy/wykonania usługi, datę sprzedaży (albo tylko > >> miesiąc dla usług ciągłych), odróżnić nabywcę od odbiorcy, wyłuskać, czy > >> faktura jest od netto czy brutto, odróżnić kod EAN od kodu produktu, > >> odróżnić VAT od rabatu, odróżnić nazwę towaru od jego cech zwłaszcza przy > >> pozycjach wielolinijkowych itd itp. > >> Ale też ze względu na inne przepisy niż rozporządzenie w sprawie faktur, > >> należy przechowywać albo fakturę papierową albo jej obraz, nie > >> zmodyfikowany i nie zmieniony. > >> Ponadto obraz ten jest przydatny do weryfikacji rej. vat w księgowości, gdy > >> algorytm OCR zgłosi nieprawidłowość, albo faktura jest "bardziej" > >> księgowana, np. przez krąg kosztów. > >> > >> -- > >> Pozdrawiam. > >> > >> Adam > > > > Bzdury opowiadasz. > > > > pamiętam starego kumpla... sprzed 25 lat ! > > > > On mówił wtedy tak (ignorant z informatyki!): > > > > - po co mi te faktury drukują! > > - niech mi to prześlą prosto do mojej bazy - programu księgowego, itd. > > > > śmiałem się wtedy z jego pomysłów, bo wiedziałem że to nie ta... epoka. > > > > no ale miał rację, niestety... > > > > a ta epoka już dawno nastała! > > > > Teraz już możesz wysyłać... dokładnie jak on to mówił. > > > > Ale wy tego nadal nie robicie... > > dlaczego? > > bo jesteście zacofani - żyjecie ciągle w czasach 1990r. > > > > Powodzenia w przeszłości. > Ale masz coś konstruktywnego do powiedzenia? > > Pierwsze transmisje na modemach 2400 i 9600 ustawiałem w sklepach > samochodowych gdzieś na przełomie lat 80/90-tych. Było to połączenie do FSO > albo FSM. Już wtedy były transmitowane dokumenty, głównie zamówienia. > > Standard EDI/ECOD ma już sporo ponad 20 lat, jest jednolity w wielu krajach > Europy. > W roku bieżącym fakultatywnie są e-faktury, od roku 2023 mają być > obligatoryjnie. > > Natomiast niektóre banki czy sądy do tej pory nie uznają maili. > Ja pierwszego maila miałem gdzieś końcem lat 80-tych, bodajże w sieci fido. > Wtedy mało kto jeszcze słyszał o BBS-ach, internet zaczął wchodzić kilka > lat później. > > Nie wiem, o co Ci chodzi, ale widzę, że dyskusja z Tobą to chyba marnowanie > czasu. Generalnie pewnie masz rację. jestem zbyt dobry, za stary, za bardzo obcykany... aby pytać o cokolwiek z tej dziedziny - sam wiem z góry, lub zgadnę lepiej... niemniej trzeba jakoś edukować młodzież... z branży IT, bo to co uprawiacie to ... dziecinada. :) A nawet prozaiczna... Rozrywka polegająca na 'dyskusji' z amatorami - naiwnymi userami systemów komp.!, też ma swoją... wartość.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads