On Wed, 8 Jul 2015, spin@hackerspace.pl wrote:
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.
Czy Ty tak naprawdę nie chcesz "rozpakować" plików z ich ojczystych formatów i trzymać "surowe dane" - nie wiem - gołe piksele, cosinusy DCT, albo opisy krzywych bezierowskich dla wektorów? Oddzielnie I-ramki wideo, oddzielnie inkrementalne? Czy też malutkie obrazeczki 8x8?
I na tym dopiero właściwe metadane spinające to wszystko razem?
Może to by się nadawało do jakiejś analityki (Content ID - szukanie takich samych rzeczy zapisanych na inne sposoby), ale zebranie takiego pliku z powrotem do postaci strawnej dla eyeballsów to może sporo potrwać?
Facebook optymizował pod kątem wykonania jednego przesuwu głowicy na plik...
Dla lepszego zrozumienia przestudiuj historię "systemów plików" na mainframe'ach (pod MVS): tam na przykład trzeba było podać wprost, że chcesz "zapisać" plik do katalogu (spisu plików), w zasadzie i tak operujesz na gołych cylindrach.
IBM przez lata ewoluował tzw. access methods - zestaw podprogramów do dostępu do danych na różne sposoby.
https://en.wikipedia.org/wiki/Access_method#Storage_access_methods
To że widzisz tam ISAM - to nie przypadek - stąd się wzięły formaty zapisu w MySQLa. Czyli na mainframe nie masz "bazy danych" - masz tylko różne metody indeksowania danych rozłożonych w blokach dysków. W AS/400 z kolei podobnie - do tego system daje Ci interfejs bazodanowy do systemu plików, możesz zrobić "SELECT * FROM katalog.pliktekstowy" i dostajesz po wierszu na linijkę tekstu w pliku, w dodatkowym polu numer wiersza...
Aby to sobie postudiować polecam Herculesa i MVS3.8j, jest za free a ma nawet chyba VSAM, najbardziej zaawansowaną metodę przechowywania danych (coś trochę jak stronicowanie pamięci w dzisiejszych kernelach).
IBM miał dyski, które miały na stałe ileś tam głowic na zewnętrznej części dysku i reszta głowic ruchomych latała po reszcie dysku - te stałe głowic`e trzymały metadane. Identyfikator rekordu w bazie przekładał się 1:1 na odnalezienie głowicy i sektorów danej ścieżki. W rezerwacjach lotniczych kod typu ZZH65Y przekłada(ł) się kiedyś dokładnie na położenie rekordu pasażera w bazie.
Zadaj sobie pytanie, czym jest dla Ciebie "rekord". Bazy SQL były pisane pod mniej więcej równe rekordy o podobnych rozmiarach. Indeks w postaci najczęściej drzewa pozwala na redukcję czasu dostępu do liniowego. Podejrzewam, że Twoje metadane specjalnie relacyjne nie są, tylko pewnie hierarchiczne i dużo jest rzeczy opcjonalnych (taki np. EXIF).
Policz, czy w Twojej strukturze czas dostępu będzie liniowy, czy może jednak wykładniczy... Do tego liczy się surowa przepustowość rury - jakoś nie wierzę, że biblioteka klienta MySQL będzie lepsza od maszyny wirtualnej systemu, pompująca informację na poziomie strony procesora.
Jak chcesz bardzo mielić dużo bajtów i to kompresować, deduplikować, rozrzucać po dyskach i robić backup na żywo do pipe'u to powinienieć obczaić ZFS.
~Saper