in b4 na longbloby jest baza danych i nazywa się filesystem - tak wiem o tym.
Mimo to chciałem pobawić się pakowaniem danych binarnych w DB, bo ma to parę zalet. Jakie są good practices trzymania i adresowania longblobów w MySQL (poza 'don't fuckin' do it')?
Wiem że Microsoft coś kombinował z wydajnością tego, i InnoDB coś tam miało swojego, a Oracle zostawał w tyle... Dorobili się czegoś, jest coś w planach, są obejścia/hax, czy zlać MySQLa i pójść gdzie indziej?
Jak trzymać w bazie dane dłuższe niż 4gb? Concat z kilku regionów? Jak adresować longbloby typu video, które mogą być streamowane i mają czas trwania, więc wywołąnie może być fragmentaryczne? Ew. inne ciekawe case'y, dawajcie mi, ponieważ mój mózg om nom nom je z chęcią.
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
On Tue, Jul 7, 2015 at 9:44 PM spin@hackerspace.pl wrote:
in b4 na longbloby jest baza danych i nazywa się filesystem - tak wiem o tym.
Mimo to chciałem pobawić się pakowaniem danych binarnych w DB, bo ma to parę zalet. Jakie są good practices trzymania i adresowania longblobów w MySQL (poza 'don't fuckin' do it')?
Wiem że Microsoft coś kombinował z wydajnością tego, i InnoDB coś tam miało swojego, a Oracle zostawał w tyle... Dorobili się czegoś, jest coś w planach, są obejścia/hax, czy zlać MySQLa i pójść gdzie indziej?
Jak trzymać w bazie dane dłuższe niż 4gb? Concat z kilku regionów? Jak adresować longbloby typu video, które mogą być streamowane i mają czas trwania, więc wywołąnie może być fragmentaryczne? Ew. inne ciekawe case'y, dawajcie mi, ponieważ mój mózg om nom nom je z chęcią.
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
Ej, a jakie właściwie są te zalety, które byś chciał wykorzystać?
On 2015-07-08 10:29, Tomasz Dubrownik wrote:
On Tue, Jul 7, 2015 at 9:44 PM spin@hackerspace.pl wrote:
in b4 na longbloby jest baza danych i nazywa się filesystem - tak wiem o tym.
Mimo to chciałem pobawić się pakowaniem danych binarnych w DB, bo ma to parę zalet. Jakie są good practices trzymania i adresowania longblobów w MySQL (poza 'don't fuckin' do it')?
Wiem że Microsoft coś kombinował z wydajnością tego, i InnoDB coś tam miało swojego, a Oracle zostawał w tyle... Dorobili się czegoś, jest coś w planach, są obejścia/hax, czy zlać MySQLa i pójść gdzie indziej?
Jak trzymać w bazie dane dłuższe niż 4gb? Concat z kilku regionów? Jak adresować longbloby typu video, które mogą być streamowane i mają czas trwania, więc wywołąnie może być fragmentaryczne? Ew. inne ciekawe case'y, dawajcie mi, ponieważ mój mózg om nom nom je z chęcią.
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
Ej, a jakie właściwie są te zalety, które byś chciał wykorzystać?
Backupy, kontrola wersji, metadane, szybkie calle do małych datasetów na których FS daje dupy, selekcja zakresów danych pod narzędzia typu grep (generujesz bufor, grepujesz, przetwarzasz output, pchasz do bazy jako atrybuty do rekordów, zabijasz bufor), prostota callowania danych w db z kodu, dynamiczne generowanie stuffu... Jak pisałem, zabawa. Dobra zabawa :3
Wsio na localhoście.
Trochę inspirowane tym: https://www.youtube.com/watch?v=1-dUkyn_fZA
On Wed, Jul 8, 2015 at 6:07 PM spin@hackerspace.pl wrote:
On 2015-07-08 10:29, Tomasz Dubrownik wrote:
On Tue, Jul 7, 2015 at 9:44 PM spin@hackerspace.pl wrote:
in b4 na longbloby jest baza danych i nazywa się filesystem - tak wiem o tym.
Mimo to chciałem pobawić się pakowaniem danych binarnych w DB, bo ma to parę zalet. Jakie są good practices trzymania i adresowania longblobów w MySQL (poza 'don't fuckin' do it')?
Wiem że Microsoft coś kombinował z wydajnością tego, i InnoDB coś tam miało swojego, a Oracle zostawał w tyle... Dorobili się czegoś, jest coś w planach, są obejścia/hax, czy zlać MySQLa i pójść gdzie indziej?
Jak trzymać w bazie dane dłuższe niż 4gb? Concat z kilku regionów? Jak adresować longbloby typu video, które mogą być streamowane i mają czas trwania, więc wywołąnie może być fragmentaryczne? Ew. inne ciekawe case'y, dawajcie mi, ponieważ mój mózg om nom nom je z chęcią.
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
Ej, a jakie właściwie są te zalety, które byś chciał wykorzystać?
Backupy, kontrola wersji, metadane, szybkie calle do małych datasetów na których FS daje dupy, selekcja zakresów danych pod narzędzia typu grep (generujesz bufor, grepujesz, przetwarzasz output, pchasz do bazy jako atrybuty do rekordów, zabijasz bufor), prostota callowania danych w db z kodu, dynamiczne generowanie stuffu... Jak pisałem, zabawa. Dobra zabawa :3
Wsio na localhoście.
Trochę inspirowane tym: https://www.youtube.com/watch?v=1-dUkyn_fZA
No nie, muszę zapytać: Metadane? Kontrola wersji? Backupy? to są chyba rzeczy z wyższej warstwy niż zarówno DB, jak FS? Selekcja zakresów danych pod narzędzia typu grep - nie kumam :( Prostota callowania danych w db z kodu - as opposed to? Jak dla mnie IPC jest znacznie bardziej skomplikowane niż dostęp do systemu plików. Dynamiczne generowanie stuffu - też nie kumam :(
A przez szybkie calle do małych datasetów masz na myśli małe latency przy czytaniu małych blobów? No, to może być prawda. Ale nie wiem jakie chcesz latency, ile tych blobów i czy mówimy o RO, czy RW. Nie spodziewałbym się, że baza robiąc ACID będzie miała choćby w przybliżeniu podobną ilość ops/s co goły system plików z całym dobrem, który system operacyjny na to nakłada…
Widełko niestety ma 21minut, więc TL; DWatch :(
On 2015-07-08 19:14, Tomasz Dubrownik wrote:
On Wed, Jul 8, 2015 at 6:07 PM spin@hackerspace.pl wrote:
On 2015-07-08 10:29, Tomasz Dubrownik wrote:
On Tue, Jul 7, 2015 at 9:44 PM spin@hackerspace.pl wrote:
in b4 na longbloby jest baza danych i nazywa się filesystem -
tak
wiem o tym.
Mimo to chciałem pobawić się pakowaniem danych binarnych w
DB,
bo ma to parę zalet. Jakie są good practices trzymania i adresowania longblobów w MySQL (poza 'don't fuckin' do it')?
Wiem że Microsoft coś kombinował z wydajnością tego, i
InnoDB
coś tam miało swojego, a Oracle zostawał w tyle... Dorobili się
czegoś,
jest coś w planach, są obejścia/hax, czy zlać MySQLa i pójść gdzie indziej?
Jak trzymać w bazie dane dłuższe niż 4gb? Concat z kilku regionów? Jak adresować longbloby typu video, które mogą być streamowane i mają czas trwania, więc wywołąnie może być fragmentaryczne? Ew. inne ciekawe case'y, dawajcie mi, ponieważ mój mózg om nom nom je z
chęcią.
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
Ej, a jakie właściwie są te zalety, które byś chciał wykorzystać?
Backupy, kontrola wersji, metadane, szybkie calle do małych datasetów na których FS daje dupy, selekcja zakresów danych pod narzędzia typu grep (generujesz bufor, grepujesz, przetwarzasz output, pchasz do bazy jako atrybuty do rekordów, zabijasz bufor), prostota callowania danych w db z kodu, dynamiczne generowanie stuffu... Jak pisałem, zabawa. Dobra zabawa :3
Wsio na localhoście.
Trochę inspirowane tym: https://www.youtube.com/watch?v=1-dUkyn_fZA [1]
No nie, muszę zapytać: Metadane? Kontrola wersji? Backupy? to są chyba rzeczy z wyższej warstwy niż zarówno DB, jak FS?
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?
Selekcja zakresów danych pod narzędzia typu grep - nie kumam :( Prostota callowania danych w db z kodu - as opposed to? Jak dla mnie IPC jest znacznie bardziej skomplikowane niż dostęp do systemu plików.
Zależy na którym etapie calla mówimy o skomplikowaniu. Trudniej wywołać się do bazy, ale jeżeli robisz calla po kryteriach, to w filesystemie bez bazy relacji co Ci pozostaje? regexpy? tu rzucasz kryteria, wyciągasz z tego dane, możesz je przepuścić przez usera lub dodatkowe kryteria jeśli zwrócony dataset jest zbyt duży/mały/dziwny...
Dynamiczne generowanie stuffu - też nie kumam :(
case: Masz 2^8 blobów, każdy z nich możesz zapisać do pliku na fsie. Directory i filename są generowane z atrybutów, albo skryptem, albo fazą księżyca.
A przez szybkie calle do małych datasetów masz na myśli małe latency przy czytaniu małych blobów? No, to może być prawda. Ale
Może być. Dla tego może właśnie piszę tutaj. w artykule M$ z 2006 czytałem że ichniejsza baza potrafiła IO jak NTFS do binarek wielkości ok. 1MB (mniejsze - szybciej). Ale bardzo cierpiała przez brak narzędzi do defragu, i szybko performance leciał na ryj.
http://research-srv.microsoft.com/pubs/64525/tr-2006-45.pdf - link do artykułu
http://perspectives.mvdirona.com/2008/06/facebook-needle-in-a-haystack-effic... - a tak fejzbuń dane trzyma.
nie wiem jakie chcesz latency, ile tych blobów i czy mówimy o RO, czy RW. Nie spodziewałbym się, że baza robiąc ACID będzie miała choćby w przybliżeniu podobną ilość ops/s co goły system plików z całym dobrem, który system operacyjny na to nakłada…
Nie musi, szybkość tutaj jest drugorzędna. Chociaż też się o nią pytam właśnie - jak te bloby trzymać? Jak adresować dane wewnątrz bloba?
Widełko niestety ma 21minut, więc TL; DWatch :(
Będziesz miał chwilę to ogarnij, gościu opisuje jak zachować 'interaktywne' badania i opracowania naukowe wraz z całymi zależnościami, executable code itp stosując iPython notebook i Orgmode.
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.
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.
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.
W dniu 8 lipca 2015 22:56 użytkownik Piotrek 'piorek' Fiorek piorek@hackerspace.pl napisał:
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.
Tak robi(ła) nasza-klasa.pl
On Wed, Jul 8, 2015 at 10:01 PM Jarosław Górny jaroslaw.gorny@gmail.com wrote:
W dniu 8 lipca 2015 22:56 użytkownik Piotrek 'piorek' Fiorek piorek@hackerspace.pl napisał:
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.
Tak robi(ła) nasza-klasa.pl
-- Jarosław Górny
A ja będę dalej wredny i zapytam po co oni tak robili? Pod HTTP tak się robi, bo pipelining obsysa. Ale chciałbym zobaczyć jakieś liczby, które pokazują kiedy takie sztuczki zaczynają się opłacać bardziej niż jechanie na najprostszej technologicznie opcji (FS+DB jeśli chcesz metadane). I mean, jeśli to jest coś, co się mieści w RAMie, to indeks też się mieści w RAMie, więc po cholerę baza danych? A jeśli cały storage składa się z takich plików, to w zasadzie po co w ogóle system plików? DBMSy umieją chyba przejmować całe block devices, nie? Pewnie jest taki moment w życiu produktu, gdzie taki sprite sheet się opłaca, ale where are the numbers, Lebowsky?:)
Hej, No tak, docelowo to HTTP, przecież nasza-klasa. Testowali różne opcje i w szczycie popularności wyszło im, że tak jest najszybciej. Prezentacja z opisem co i jak: http://osec.pl/sites/default/files/barcamp/materialy/Nasza-Klasa%20-%20syste...
Niestety nie ma tam wykresów ani tabelek.
W dniu 9 lipca 2015 09:27 użytkownik Jarosław Górny < jaroslaw.gorny@gmail.com> napisał:
No tak, docelowo to HTTP, przecież nasza-klasa.
Pomieszałeś. Spirity HTTP nie mają nic wspólnego z FS, a z narzutem przy każdym jednym odwołaniu po plik przy HTTP < 2, które wynika z ciastek i innego dupikowanego i nadmiarowego śmiecia.
W dniu 9 lipca 2015 19:22 użytkownik Kuba Niewiarowski marsjaninzmarsa@gmail.com napisał:
W dniu 9 lipca 2015 09:27 użytkownik Jarosław Górny jaroslaw.gorny@gmail.com napisał:
No tak, docelowo to HTTP, przecież nasza-klasa.
Pomieszałeś.
Nie. Nie pomieszałem. Po prostu nie wiedziałem (i nadal nie wiem) co Tomek miał na myśli. Z WWW doświadczenie mam zerowe. Z budowaniem / tjunowaniem / utrzymaniem systemów pracujących pod dużym obciążeniem również. Piorek rzucił hasło "trzymanie plików w jednym wielkim pliku", a ja akurat wiem o przynajmniej jednej implementacji tego pomysłu na dużą skalę, która się bardzo sprawdziła w praktyce. Więc się podzieliłem. Ot i tyle.
Spirity HTTP
Co to są spirity HTTP? o_0 Nawet google nie wie.
W dniu 09.07.2015 o 20:08, Jarosław Górny pisze:
Spirity HTTP
Co to są spirity HTTP? o_0 Nawet google nie wie.
Sprite (jedno "i" mniej) sheet - to polega na tym, że jak masz www, a na nim wiele maleńkich obrazków, np buttonów, wielkości że czasem handshake http niemal potrafi być dłuższy od każdego z nich to opłaca się skleić je w jeden plik (czyli zamiast n*0,5kB masz np 5kB) i pokazywać fragmenty tego pliku w miejscach na stronie gdzie co ma być. W ten sposób oszczędza się zamiast wielokrotnych wywołań http, ma się jedno po ciut większą ilość danych. Ofc ma to sens głównie dla takich maleńkich obrazków. Dawniej się tego typu rzeczy robiło w grach, żeby wiele bitmap na raz załadować do pamięci karty grafiki.
Krok dalej to dla prostych monochromatycznych symboli w ogóle zrezygnować z grafik i zamienić je w customowy font (np GameJolt tak robi).
Wracając do tematu - mam wielkie wrażenie że masa rzeczy jakie OP chce od tego rozwiązania implementuje lub w przyszłości zaimplementuje btrfs.
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.
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.
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
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.
On 2015-07-08 19:18, antoszka wrote:
Tako rzecze spin@hackerspace.pl (2015-07-07, 22:44):
Again, wiem że pakowanie longblobów do bazy danych jest bad practice, ale ma kilka zalet które mnie interesują i chciałem się pobawić.
A może coś a la Venti z plan9?
W połączeniu z bazą, i wtedy mapa klucz-sha1 po której adresujesz te dane?
-
antoszka -
Jarosław Górny -
Kuba Niewiarowski -
Marcin Cieslak -
Piotrek 'piorek' Fiorek -
rysiek -
spin＠hackerspace.pl -
Tomasz Dubrownik -
Łukasz 'Cyber Killer' Korpalski