On 2015-07-08 22:56, Piotrek 'piorek' Fiorek wrote:
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.
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?
Ciary mam od samego myślenia co się stanie jak będzie te dane trzeba odzyskać.
Już bardziej byłbym za tym żeby trzymać je w osobnej DB jako backup i generować z nich FS do wszystkich operacji na tych danych. Buforujesz potem wszystkie writes na tych danych, i pchasz do bazy jak masz niskie obciążenie sprzętu, i generujesz zmienione rekordy na FSie jako pliki.
A co do deduplikacji i plików minimalnie się różniących: jpg i mp3 są skompresowane więc nawet malutka różnica w treści powoduje sporą różnice w tym jak plik wygląda na dysku. Musiałbyś więc takie pliku siekać na małe kawałki i deduplikować kawałki albo robić inne dziwne rzeczy.
afaik kompresja musi być znana byś był w stanie to zdekompresować, więc jeżeli jesteś w stanie określić że dwa pliki mają taką samą treść (jesteś, są na to algorytmy), możesz przyjąć szczegółowe kryteria deduplikacji które tną określone dane (np. wiesz że masz plik 320kbps w bazie, więc tniesz wszysstko niższe niż ta wartość, jednocześnie harvestując metadane). Więc trzymasz tylko te, które są potrzebne do wygenerowania aproksymacji treści (np. ten sam bitrate i algorytm kompresji).
Inną ciekawą rzeczą którą słyszałem, że się robi to np. sklejenie wszystkich obrazków w jeden duży plik i trzymanie w DB informacji o długości i początku konkretnego obrazka w tak powstałym pliku. Taki plik trzymasz zawsze otwarty w swojej aplikacji i tylko czytasz odpowiedni fragment jak potrzebujesz.
Coś w tym stylu było chyba w tym artykule o FB który podrzuciłem, też o tym myślałem.
Tylko właśnie skłaniam się żeby w DB trzymać backup. To co antoszka podrzucił z plan9 looks like much profit.