On Wednesday 08 of July 2015 23:15:43 spin@hackerspace.pl wrote:
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ć.
Tak, trzymasz te wszystkie pliki na FSie i tylko metadane które Cię interesują w DB. Naprawdę nie rozumiem gdzie tu widzisz taki straszny problem. Please do explain co dokładnie jest takim FS-killerem tutaj, że jest to rozwiązanie gorsze niż trzymanie blobów w DB (które już samo w sobie AFAIK jest nie najlepszym pomysłem).
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).
No spoko, jeśli chcesz rozpakować i porównać to można, ale polecam Ci załadować do RAMu i analizować obrazki RAW 36MPx (Nikon D80X) albo 50MPx do których aparaty za chwilę będą w sprzedaży (Nikon 5Ds). Wiem, że nie wszystkie tyle mają, ale to będzie moment kiedy albo będziesz musiał mieć maszynę z pierdyliardem RAMu, albo cały Twój setup pierdolnie.