Potrzebny komponent do kompresji obsługujący dużą liczbę plików

Generalnie jak w temacie.

Wbudowana w Delphi XE2 klasa TZipFile ma jakieś dziwne ograniczenie do 2710 plików, a ja jednorazowo w paczce potrzebuję umieścić od kilkuset tysięcy do kilku milionów plików.

Archiwum stworzone przez TZipFile zawiera owszem wszystkie pliki i można je normalnie przeglądać niezależnymi narzędziami (np. Total Commander widzi wszystko), ale wygląda tak, jakby nagłówek miał jakieś ograniczenie i nie potrafił przyjąć więcej danych.

Pytanie czy ktoś się spotkał z tym problemem i go jakoś rozwiązał, albo - czy znacie jakiś komponent, który potrafi sobie poradzić z bardzo dużą liczbą plików.

Nie używałem ani nic, ale sprawdzałeś co to jest np:
TZipMaster
ZipForge
ZipTV

Wież że ogólnie zip ma ograniczenie do ilości spakowanych plików?

Okej. Przepraszam wszystkich za zamieszanie. Rozwiązałem problem inaczej.

napisz jak rozwiązałeś problem. Nienawidzę w google szukać czegoś i trafiać na wątek sprzed 10 lat lub jakiś sprzed tygodnia i autor porusza dany problem, później odpisuje "już rozwiązałem problem, nara!" i tyle! wtedy taki temat jest śmietnikiem i tylko wkurza, a wkurza tym bardziej, jeśli trafi się na np. 5 takich topiców w necie i w każdym ktoś rozwiązał problem sam, ale nie podzielił się rozwiązaniem przez co osoba szukająca rozwiązania musi szukać dalej lub zakładać identyczne tematy na forum.

Szczerze to nie wiem jak i czy mogę o tym napisać. Bo jeżeli napiszę jak rozwiązałem - zaraz trafi się frustrat z małym pitakiem, który będzie budował swoje ego twierdząc, że rozwiązanie jest beznadziejne, skrótowe, banalne, idiotyczne i jeszcze pewnie znajdzie się kilkadziesiąt epitetów.

A jak nie da się przyczepić do samego rozwiązania - to przynajmniej do sposobu wykonania - bo takiemu nie pasuje mój styl kodowania. Nie ma oczywiście nic do powiedzenia w sprawie, ale tak dwie krople żółci musi wyrzygać.

Irytuje mnie, że na tym forum jak się człowiek chce czegoś dowiedzieć i pyta jak człowiek to od razu dostaje w pierwszym poście w ryja, bo się jednemu z drugim coś nie podoba w sposobie przedstawienia problemu, albo w ogóle całokształt.

Nie rozumiem. Jak nie mam nic sensownego do powiedzenia to się nie odzywam. Morda w ciup i dłubię swoje. A tutaj ? Co byś kurka nie zrobił - zawsze znajdzie się frustrat, któremu coś nie pasuje.

Okej. Chcesz rozwiązania ? użyłem SQLite. Zamiast z jednej bazy wyciągać dane, których w niej nie chcę, pakować do plików i kompresować - przerzucam je do zewnętrznej bazy - w tym konkretnym przypadku rozwiązanie ma prawie same zalety i niewiele minusów.

Jeśli są to bardzo małe pliki to rozmiar zip'a wzrośnie przez niepotrzebne nagłówki do niemal pustych plików. To, że plik np. zajmuje 1 bajt to niestety nie oznacza, że system plików nie musi gromadzić dodatkowych danych o nim jak prawa dostępu, daty utworzenia, nazwa itp.
Problemem, który opisałeś w temacie było wpakowanie większej ilości plików w zip'a a nie znalezienie zamiennika dla archiwum - pisanie w takim przypadku o rozwiązaniu problemu jest mylące i sugeruje, że jednak ci się to udało, ale nie powiesz jak.
Jednak baza danych to prawdopodobnie najlepszy sposób do przechowywania takich danych jak określiłeś czyli małych, w dużej ilości. Oczywiście nie podałeś też informacji jak często będziesz zapisywał to do bazy - czy jest to tylko jednorazowy backup czy jednak "żywa" baza z ciągłymi modyfikacjami.

Poza tym I co z tego, że ludzie wtrącają się, dopytują i odbiegają od tematu taka idea forum - często problem jest gdzieś indziej np. autor jest przekonany, że to co wymyślił jest najbardziej optymalne, i jego sposób jest najlepszy podczas gdy często tak nie jest. Do tego nagminne jest nie podawanie informacji o błędzie który wystąpił, kompilatorze czy wręcz języku, brak kodu źródłowego, opis problemu z d**y wzięty, sepleni jak by pisało posta jakieś dziecko a ty się później domyślaj choćbyś chciał pomóc to się nie da.

szopenfx napisał(a):

Jeśli są to bardzo małe pliki to rozmiar zip'a wzrośnie przez niepotrzebne nagłówki do niemal pustych plików. To, że plik np. zajmuje 1 bajt to niestety nie oznacza, że system plików nie musi gromadzić dodatkowych danych o nim jak prawa dostępu, daty utworzenia, nazwa itp.
Problemem, który opisałeś w temacie było wpakowanie większej ilości plików w zip'a a nie znalezienie zamiennika dla archiwum - pisanie w takim przypadku o rozwiązaniu problemu jest mylące i sugeruje, że jednak ci się to udało, ale nie powiesz jak.
Jednak baza danych to prawdopodobnie najlepszy sposób do przechowywania takich danych jak określiłeś czyli małych, w dużej ilości. Oczywiście nie podałeś też informacji jak często będziesz zapisywał to do bazy - czy jest to tylko jednorazowy backup czy jednak "żywa" baza z ciągłymi modyfikacjami.
Oczywiście - w ogólnym ujęciu masz rację.

W pierwszym podejściu zasugerowałem się rozwiązaniem, które funkcjonuje w oprogramowaniu konkurencyjnym do tego, dla którego piszę swoją nakładkę (żaden z programów "bazowych" nie jest mojej produkcji - zajmuję się tylko ich serwisowaniem) - tam tworzone jest milion plików ZIP przechowujących dokładnie po jednym pliku XML o rozmiarze 2 kB. W rozwiązaniu konkurencyjnym zysk z tego jest taki, że archiwum jest zahasłowane, ponieważ plik XML zawiera dane wrażliwe.

Ja chciałem napisać podobną funkcjonalność, ale przechowywać wszystkie pliki XML w jednej paczce, ponieważ moja nakładka może równocześnie obsługiwać wiele baz danych, więc pasowało mi, żeby zawartość paczek dawała się łatwo identyfikować. W tym celu oprócz samych plików XML w paczce zip lądował zawsze plik header.xml z informacjami kogo dotyczy dana paczka.

Porządkowanie odbywa się raz dziennie dla każdej bazy danych i polega na tym, że te dane, które aktualnie nie są wykorzystywane przez aplikację macierzystą, a zapychają potężnie bazę danych - lądują w archiwum, a drugim etapie baza napełniana jest danymi z archiwum, co do których zaszła potrzeba wykorzystania.

Oczywiście - całość jest sporo bardziej skomplikowana, ale generalnie całość działała poprawnie na plikach ZIP do czasu aż ze skali mikro (kilkaset testowych rekordów) przeszedłem do skali makro z kilkuset tysiącami plików - ogólna wydajność jest zadowalająca i nie mam co do niej zastrzeżeń.

Oczywiście tak jak piszesz - to nie jest rozwiązanie problemu z plikami ZIP, tylko zmiana sposobu myślenia i tylko pod tym kątem pisałem, że "rozwiązałem problem inaczej".

Owszem przepompowywanie danych z jednej bazy do drugiej ma swoje minusy, ale ma wiele plusów - włącznie z tym, że mogę stosować indeksy, przechowywać wiele plików XML w jednej bazie - rozróżniając je odpowiednimi identyfikatorami pochodzenia i po prostu stosować banalne zapytania SQL w celu wyłuskania niezbędnych danych potrzebnych do zwrotnego przepompowania danych do baz macierzystych.

Skoro tobie to wystarczy to ok ale mam pytanie - ile zajmuje czasu taki dump z 24h i ile waży?

Zależy jak duża baza. Niektóre codziennie generują 2000 plików po 1-2 kB (to zależy czy zapisywany jest cały plik XML, czy tylko najistotniejszy fragment) - inne nawet 50 000. Łatwo obliczyć jak dużo danych trzeba przetworzyć codziennie.

Zrzut bazy, w której do przerzucenia do archiwum jest ok 130000 plików XML trwa ok 5 min - wliczając w to pobranie z BD kompletnego datasetu, dodanie wszystkich plików do archiwum, zrobienie UPDATE na zmodyfikowanych rekordach oraz VACUUM FULL na modyfikowanej tabeli. W tym przypadku spakowana paczka zajmuje ok 16 MB.

Wszystko odbywa się w cyklu automatycznym - aplikacja konfiguruje dla siebie zaplanowane zadanie w systemie windows i odpala się w trybie automatycznym raz dziennie. Wykonuje proces synchronizacji bazy danych z systemem zewnętrznym po SOAPie (co jest najdłuższym fragmentem całego procesu). Po tym następuje porządkowanie bazy danych. Kilka minut względem nawet kilu godzin potrzebnych na synchronizację jest czasem wystarczającym.

Aplikacja działa w trybie nienadzorowanym - to znaczy - żaden użytkownik nie siedzi i nie ślepi w monitor w czasie pracy programu. Współpracuje z serwerem powiadomień, z którym wymienia komunikaty o stanie pracy poprzez pliki XML przesyłane pocztą elektroniczną. Serwer powiadomień (który funkcjonuje na zewnątrz sieci wszystkich klientów i ma na celu monitorowanie poprawności wykonywania automatycznych synchronizacji) dostaje informacje o każdym rozpoczęciu i zakończeniu procesu synchronizacji oraz zmianach w konfiguracji zaplanowanego zadania (po to, żeby wiedzieć kiedy reagować, gdy proces synchronizacji miał się wykonać, ale z jakichś powodów nie wykonał się - np. brak połączenia internetowego, nie włączony komputer lub inny przypadek losowy)