Dnia środa, 8 lipca 2015 22:56:02 Piotrek 'piorek' Fiorek pisze:
On Wednesday 08 of July 2015 22:45:37 spin@hackerspace.pl wrote:
Robisz deduplikację w wyniku której usuwasz 14 plików, np. jpgów albo mp3. Każdy z nich ma taką samą treść, ale inne metadane: został pobrany z innego źródła, ma inną datę stworzenia/modyfikacji, inne rozszerzenie. Dwa z nich zawierają komentarz, cztery mają inne dane, np exif, trzy mają unikalne headery, jeden ma unikalny plaintext zaryty gdzieś w pliku, dwa otagowane są datą, jeden ma logo w prawym górnym rogu, lub jingiel/glitch. Osiem z nich część metadanych ma zapisanych w osobnym pliku tekstowym, lub są zapisane wraz z towarzyszącymi im plikami (np. html).
Chcesz zachować te dane, z zachowaniem ich relacji (tzn kiedy wystąpiły razem). deduplikując redundantną częśc/zachowując wersję preferowaną samej treści wg. określonych kryteriów, a dodatkowo móc dodawać metadane za każdym razem kiedy plik trafi do zasobu z innego źródła i ulegnie automatycznej deduplikacji.
POza tym chcesz trzymać gdzieś hashe które stosujesz do analizy komparatywnej (perceptualnej czy jak to tam się nazywa) za pomocą których robisz dedup.
What do?
Pliki trzymasz na FSie, a wszystkie inne dane o których wspomniałeś plus info o który plik chodzi w DB. Jeśli wiesz, że np. będziesz miał dużo małych plików to dobierasz FS który lepiej sobie z tym radzi, np. ReiserFS 4 świetnie sobie radził z dużymi ilościami małych plików. Wiesz, że będą duże pliki? XFS dobrze się sprawdzi plus oczywiście można jeszcze zrobić tuning każdego FSa.
Dokładnie.
Jak przewidujesz *fchuj* plików, trzymaj w bazie jako klucze sha256 zawartości pliku, a plik w strukturze: /jakiś/katalog/xx/yy/zz/xxyyzz<reszta-sha256>
Metadane (łącznie z ew. "human-readable nazwami" plików) w db.
Dnia środa, 8 lipca 2015 23:15:43 spin@hackerspace.pl pisze:
No dobra. Masz ten sam obrazek - raw, png, i jpg. Z png zachowujesz alpha channel, rawa trzymasz bo ma najlepszą rozdzialkę, a jpg jako jedyny nie ma watermarka.
Trzymać to wszystko na FSie?
Tak.