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.