Temat: Muzyka w bazie

Bogdan Pieńkowski:
Pewnie bo klient chce zapisywać informacje dla samego zapisywania. Nikogo nie zainteresowało "co ma być na wyjściu". Już kiedyś widziałem projekt dużego systemu, w którym "idealista" wyszedł od "zasobu informacji, które chce wpisać". Zaprojektował nawet strukturę bazy danych z logiką opartą na tablicach (słownikach). No i przyszło się wypełnić te słowniki i okazało się, że nikt nie jest w stanie tego zrobić :) Ludzie najprostsze rozwiązania są najlepsze. Najważniejsze są oczekiwania na wyjściu, a nie na wejściu. Jeżeli chcę zmagazynować w systemie 100 utworów mojej dyskografii nie będę ich ładował do BLOB'ów, zastanawiał się nad rollbackiem transakcji zagnieżdżonych, budował hurtowni na DB2, stawiał WAS-a czy Ciskowego ACE.

najprostsze rozwiązanie nie jest automatyczni najlepsze

Z bardzo prostej przyczyny, jak przyjdzie coś dodać do takiego "produktu" to koszt i nakład sił znacznie przewyższa to co było by konieczne przy mniej prostym projekcie. Znam to z własnego doświadczenia. Robiłem systemy a później musiałem coś dorabiać, jak bym postępował tak jak piszesz - nigdy bym się nie wyrobił

oczywiście nie należy popadać w skrajności, ale słowniki są raczej dobrym pomysłem, a jak ktoś ma burdel w danych i nie da się słownika zrobić - cóż to patologia, dokładnie taka sama patologia jest w momencie przekombinowania projektu więc trzeba wybrać po środku

Temat: Muzyka w bazie

Ja tam od rozwiazan prostych wole rozwiazania proste i eleganckie. Roznica jest taka, ze proste jest dorazne a proste i elegancke jest przemyslane i elastyczne.

Wracajac do BLOBa, juz doszlismy do tego, ze wszystko zalezy od wymagan, wiec nie zastanawiamy sie juz "po co" tylko "jak". Nawet jesli nie to ma sensu biznesowego, to ciekawe jest jakich inni uzywaja metod do rozwiazania konkretnych problemow.

Temat: Muzyka w bazie

Bartosz Ślepowronski:
Ja tam od rozwiazan prostych wole rozwiazania proste i eleganckie. Roznica jest taka, ze proste jest dorazne a proste i elegancke jest przemyslane i elastyczne.

Brakuje mi słowa *wydajne*, no ale pytanie brzmiało dość akademicko.

Wracajac do BLOBa, juz doszlismy do tego, ze wszystko zalezy od wymagan, wiec nie zastanawiamy sie juz "po co" tylko "jak". Nawet jesli nie to ma sensu biznesowego, to ciekawe jest jakich inni uzywaja metod do rozwiazania konkretnych problemow.

>
Dla mnie osobiście - jeżeli nie ma wymogu na ACID na tych danych nie widzę powodu, żeby musieć je trzymać w całości w bazie danych. Dokładniej - metadane wystarczą, blokowanie na poziomie metadanych + zestaw triggerów w pythonie, czy tam innym perlu wystarcza. W zupełności.
W kontekście wydajności - dużo zależy od platformy systemowej. Nigdy nie pracowałem z serwerem pod kontrolą Windowsa, więc się nie będę wypowiadać. Pod Linuxem - jest sporo systemów plików, indeksujących podkatalogi b-drzewem... Tak czy siak. Baza ma teoretycznie mniej seeków, ale z drugiej strony warto wiedzieć jak działa TOAST - to w kontekście PostgreSQLa. Nie polecam. Zdecydowanie.
Co do kompresowania, kodowania i czego tam jeszcze. System plików pod Linuxem ma takie coś że można go kapsułkować. W skrócie - google "CryptoFS". Można sobie podokładać czego się chce. Można też zrobić takie coś na niższym poziomie - jak się chce.
Problemem w przypadku tego typu danych jest to, że słabo się to kompresuje, zwykle pliki są duże i bardzo łatwo zabić serwer - wystarczy "select * from tabelka" - jeżeli tabelka ma sporo rekordów, a przy tym zawiera bloby... serwer musi przewalić się po całym zestawie danych. Trochę upraszczam, ale update na takiej tabelce zwykle takie coś wykłada - takiego MySQLa. Zmiana indeksu - w mojej "ulubionej" bazie danych - MySQLu oznacza przepisanie całej tabeli w tę i na zad. Im mniej do przewalania tym lepiej. PostgreSQL też nie jest jakoś specjalnie lepszy, podzieli takiego bloba na 8k klocki i zapisze w tabelce obok. No, ale można dumpa zrobić. Może trochę dziwny jestem, ale wolę rsynca i różnicowy backup.

Temat: Muzyka w bazie

Przemysław R.:

Sebastian Kolski:
Nie chciał bym zaczynać kolejnej odsłony wojny "pliki w bazie czy filesystemie", ale podam kilka powodów dla których jednak warto trzymać je w bazie:

- nie wystąpi sytuacja, w której manipulacja plikami na poziomie fs'u spowoduje rozjazd wskaźników na nie w bazie

przy ilu jednoczesnych transakcjach do bazy baza powie dość zakładając że pliki mają po kilkaset MB, SQL nie jest z gumy, pamięć też, a każda operacja skutecznie te zasoby zrzera

Co prawda pisałem o czymś innym (o sytuacji, gdy np ktoś inaczej, niż to jest zapisane w bazie, podmontuje zasób z plikami, albo skasuje/zmodyfikuje pliki z poziomu systemu operacyjnego), ale nie bardzo widzę powód dla którego baza miała by powiedzieć dość w opisanej powyżej sytuacji. To czy wrzucamy plik mający kilkaset mega czy kilka zżera mniej więcej tyle samo zasobów. Baza (w tym przypadku Oracle) przetwarza dane do wrzucenia nie w całości na raz, tylko w paczkach (kiedyś były to paczki po 32KB, obecnie są zmiennej wielkości max 64MB). Gdyby było inaczej to przy małej ilości pamięci przydzielonej bazie nie można by było wrzucić do niej dużych plików. Dodatkowo dane potrzebne do rollbackowania transakcji też nie są trzymane w pamięci. Co więcej np w Oracle nie ma, spotykanych w innych bazach, ograniczeń w ilości jednoczesnych insertów do jednej tabeli. Stąd też nie wiem dlaczego baza miała by powiedzieć dość.

- skalowalność

mocno naciągane
raczej chciałeś napisać wygodę w operowaniu

Zależy oczywiście o jakiej skali mówimy. Wrzuć do katalogu kilkadziesiąt milionów plików i spróbuj odczytać ostatni.

- spójność odczytów/zapisów

fakt

- backupy, które są regularnie testowane czy da się z nich odzyskać dane, i z których można odzyskać kompletne i spójne dane na zadany punkt w czasie

narzędzia do backupu FS też to potrafią

Potrafią odzyskać spójny obraz FS jaki był w zeszły czwartek o 19:34:32? Jeśli jest coś takiego to jak się nazywa? Wiem, że używając np ZFS'a można osiągnąć podobną funkcjonalność robiąc snapshoty, ale dokładność jest ograniczona częstotliwością robienia snapshotów.

zresztą nie odwarzył bym się zrobić FUL RECOVERY na bazie z takimi BLOBAMI- log by mnie zabił

Jedynie odtwarzając bazę z backupu można sprawdzić czy jest poprawny. Nie sprawdzany backup jest tylko niewiele lepszy niż brak backupu.

- łatwość przywrócenia skasowanych danych

co za różnica czy odtwarzasz z pliu do FS czy też z backupu do bazy

W przypadku bazy danych nie musisz nic odtwarzać z backupu.
Używasz po prostu flashback query
"Oracle Flashback Query retrieves data as it existed at an earlier time. The query explicitly references a past time through a time stamp or System Change Number (SCN). It returns committed data that was current at that point in time."

"Example 12-2 Restoring a Lost Row After Oracle Flashback Query

INSERT INTO employees (
SELECT * FROM employees
AS OF TIMESTAMP
TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE last_name = 'Chung'
);"

- szyfrowanie

eee, mocno nie trafiony argument, można zakodować głupiego zipa, rara czy co tam chcsz - a co śmieszniejsze za pomocą commandline

Oczywiście można to robić w ten sposób, tylko czy nie prościej jest po prostu przy tworzeniu tabeli dodać ENCRYPT i niech baza robi to za nas?

- deduplikacja

ale o co chcodzi?

google/bing -> wiki data deduplication

- automatyczna kompresja, wykrywanie czy kompresja coś da i stosowanie jej w takich przypadkach

kompresja może być w FS, NTFS tak ma, szyfrowanie też ma jakby co

Czy FS sprawdza czy dany plik warto kompresować? Czy też kompresuje wszystko jak leci?

- audytowalność zmian/dostępu

NTFS też to ma , wpisy idą do event-loga

Jakoś wydaje mi się, że wyciągnięcie rekordów audytu zapisanych w tabeli w bazie danych będzie łatwiejsze niż przeglądanie event-loga.

Oczywiście wszystko zależy od wymagań biznesowych.

tru

Dodatkowe pytanie, co oznacza zamulanie bazy bo nie znam tego pojęcia.

baza danych zużywa więcej zasobów niż posiada i mieli po dysku - to naprawdę denerwuje

Użycie bazy do składowania plików nie powinno w takim razie spowodować zamulania bazy (patrz początek).

-------

Najprawdopodobniej większość tekstu powyżej ma się nijak do pierwszego pytania, ale myślę, że warto porozmawiać o dostępnych technologiach

Temat: Muzyka w bazie

Bartosz Ślepowronski:
Zastanawiam sie, na ile takiego BLOBa da sie przeniesc pomiedzy bazami danych. Na przyklad, mam baze w mySQLz 400tys plikow zapisanych jako BLOB. Z takiego czy innego powodu musze sie przesiasc na jakas baze "profesjonalna".

Da sie polaczyc bazy i normalnie robic insert/select z mySQL do DB2/Oracle/MSSQL czy musze te 400tys plikow zrzucic z bazy na dysk i potem z dysku znowu do bazy?

Nigdy nie probowalem i szczerze mowiac nie wiem jak to dziala.Bartosz Ślepowronski edytował(a) ten post dnia 23.11.09 o godzinie 22:17

"Najprościej" można: select * w datareader i inserty dla każdej odpowiedzi. "Tylko" najpierw struktura bazy musi być powielona.

Temat: Muzyka w bazie

OK. To proszę o uzasadnienie BLOB-a dla serwisu WWW udostępniającego np. 500 utworów.

Proszę bardzo. Utworki są zapisane w formacie MIDI (średnia waga 40kb)... ;)

Temat: Muzyka w bazie

Bartosz Ślepowronski:
Ja tam od rozwiazan prostych wole rozwiazania proste i eleganckie. Roznica jest taka, ze proste jest dorazne a proste i elegancke jest przemyslane i elastyczne.

Różnica jest taka, że celem projektu jest zadowolenie użytkownika końcowego, a nie duma z siebie programisty.

Krzysztof Drelczuk:
Proszę bardzo. Utworki są zapisane w formacie MIDI (średnia waga 40kb)... ;)

A jak się mają do tego koszty szeroko rozumianego utrzymania nawet jeżeli weźmiemy pod uwagę "darmową" bazę danych?

Temat: Muzyka w bazie

Sebastian Kolski:
Co prawda pisałem o czymś innym (o sytuacji, gdy np ktoś inaczej, niż to jest zapisane w bazie, podmontuje zasób z plikami, albo skasuje/zmodyfikuje pliki z poziomu systemu operacyjnego), ale nie bardzo widzę powód dla którego baza miała by powiedzieć dość w opisanej powyżej sytuacji. To czy wrzucamy plik mający kilkaset mega czy kilka zżera mniej więcej tyle samo zasobów. Baza (w tym przypadku Oracle) przetwarza dane do wrzucenia nie w całości na raz, tylko w paczkach (kiedyś były to paczki po 32KB, obecnie są zmiennej wielkości max 64MB). Gdyby było inaczej to przy małej ilości pamięci przydzielonej bazie nie można by było wrzucić do niej dużych plików. Dodatkowo dane potrzebne do rollbackowania transakcji też nie są trzymane w pamięci. Co więcej np w Oracle nie ma, spotykanych w innych bazach, ograniczeń w ilości jednoczesnych insertów do jednej tabeli. Stąd też nie wiem dlaczego baza miała by powiedzieć dość.

jeżeli masz duże pliki, transakcje na nich i powiedzmy 4 GB RAM to przy przetwarzaniu kilkunastu plików + normalna praca bazy całość na pewno dostanie czkawki

sytuacja się pogorszy jak nie masz Oracle a coś innego i mniej wyrafinowanego.

Powiedzmy że Mam MySQL-a - co wtedy?

Zależy oczywiście o jakiej skali mówimy. Wrzuć do katalogu kilkadziesiąt milionów plików i spróbuj odczytać ostatni.

do jednego katalogu się nie da
do struktury katalogów w postaci drzewa to i owszem, wszystko zależy od przyjętego algorytmu składowania

Potrafią odzyskać spójny obraz FS jaki był w zeszły czwartek o 19:34:32? Jeśli jest coś takiego to jak się nazywa? Wiem, że używając np ZFS'a można osiągnąć podobną funkcjonalność robiąc snapshoty, ale dokładność jest ograniczona częstotliwością robienia snapshotów.

inne FS też mają snapshoty
co do odzyskiwania z taką dokładnością - jest to opłacalne w momencie gdy dane z plików nie są zbyt wielkie

bo powiedz jak wieli będzie LOG bazy danych po kilku dniach w tym modelu :) życzę powodzenia w składowaniu tych danych

zresztą nie odwarzył bym się zrobić FUL RECOVERY na bazie z takimi BLOBAMI- log by mnie zabił

Jedynie odtwarzając bazę z backupu można sprawdzić czy jest poprawny. Nie sprawdzany backup jest tylko niewiele lepszy niż brak backupu.

skąd pewność że backupu dla FS nie można sprawdzić?
głupi RAR oferuje dodanie jakiś tam bitów korekty

Stwierdzenie że jedynie jedynie backup bazy danych daje taka pewność jest co najmniej nadużyciem

W przypadku bazy danych nie musisz nic odtwarzać z backupu.
Używasz po prostu flashback query
"Oracle Flashback Query retrieves data as it existed at an earlier time. The query explicitly references a past time through a time stamp or System Change Number (SCN). It returns committed data that was current at that point in time."

"Example 12-2 Restoring a Lost Row After Oracle Flashback Query

INSERT INTO employees (
SELECT * FROM employees
AS OF TIMESTAMP
TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
WHERE last_name = 'Chung'
);"

jak nie mam Oracle to co wtedy? zresztą snapshot to nie to samo co backup

Oczywiście można to robić w ten sposób, tylko czy nie prościej jest po prostu przy tworzeniu tabeli dodać ENCRYPT i niech baza robi to za nas?

FS też to robi za nas
jak się uprzesz możesz też zaszyfrować każdy plik oddzielnie w ramach FS za pomocą jakiegoś narzędzia

- deduplikacja

ale o co chcodzi?

google/bing -> wiki data deduplication

eee, co za problem sprawdzić przed zapisem pliku MD5 pliku czy nie występuje już w bazie?, zresztą nie problem trzymać kopie plików w postaci BLOB-a

więc to wszystko zależy od ALGORYTMU a nie sposobu

Czy FS sprawdza czy dany plik warto kompresować? Czy też kompresuje wszystko jak leci?

moment, algorytmy kompresji są chyba podobne niezależnie od miejsca w którym zostaną zastosowane, nie istotne czy FS czy baza, jak masz plik skompresowany to masz najwyżej zerowy współczynnik kompresji.

Jakoś wydaje mi się, że wyciągnięcie rekordów audytu zapisanych w tabeli w bazie danych będzie łatwiejsze niż przeglądanie event-loga.

wbrew pozorom da się zrobić na tym SELECT-a

Użycie bazy do składowania plików nie powinno w takim razie spowodować zamulania bazy (patrz początek).

skoro to taki super pomysł to czemu o tym dyskutujemy?

Temat: Muzyka w bazie

Bogdan Pieńkowski:

Bartosz Ślepowronski:
Ja tam od rozwiazan prostych wole rozwiazania proste i eleganckie. Roznica jest taka, ze proste jest dorazne a proste i elegancke jest przemyslane i elastyczne.

Różnica jest taka, że celem projektu jest zadowolenie użytkownika końcowego, a nie duma z siebie programisty.

Ktore jest wynikiem realizacji podpisanych przez obie strony wymagan, ktore sa wpisane w plan projektu, ktory oparty jest na technicznej analizie wymagan i oszacowaniu czasu wymaganego do ich realizacji, ktory zalezy od tego w jaki sposob chcemy te wymagania zrealizowac. I to jest cos co na ogol dyskutuje sie z klientem, zeby osiagnac jego zadowolenie i pelna swiadomosc tego w co sie pakuje. Co pozwala nam potem na pytanie klienta "a dlaczego ta prosta zmiana bedzie tyle kosztowac" odpowiedziec "dalismy wam do wyboru rozwiazanie proste i tansze oraz drozsze i lepsze i z pelna swiadomoscia wybraliscie tansze ale mniej elastyczne, co jest zapisane w tym dokumencie i podpisane tu i tu".

Co sprowadza sie do tego, ze jakbym chcial osiagnac zadowolenie uzytkownika to bym go wyslal na wczasy, a celem projektu jest realizacja wymagan klienta.Bartosz Ślepowronski edytował(a) ten post dnia 24.11.09 o godzinie 11:00

Temat: Muzyka w bazie

A jak się mają do tego koszty szeroko rozumianego utrzymania nawet jeżeli weźmiemy pod uwagę "darmową" bazę danych?

Mniejsze. Wszystko dostajemy z pudełka. Możemy to robić na tanich serwerach (hosting) a nie tylko na dedykowanych (brak prawa zapisu na dysku przez aplikacje). Łatwiej zachować spójność danych (patrz dyskusja - aby otrzymać ACID na np. MSSQl trzeba zrobić job'a, którego nie ma w Expresie). Łatwiej backupować, synchronizować i utrzymać bezpieczeństwo oraz kilka innych powodów wyżej już wymienionych.

Generalnie zaryzykuje stwierdzenie, że nigdy nie powinno wychodzić z danymi po za bazę chyba że mamy ku temu poważne powody (czytaj w 99% nie warto). Przechowywanie terabajtów binariów tańsze i łatwiejsze w utrzymaniu będzie faktycznie na FS (choć nie będzie to takie banalne jak można by przypuszczać).

Natomiast jakbym miał nieograniczone zasoby i chciałbym zrobić coś dobrego to i tak skłaniał bym się ku bazie danych - nie jednej oczywiście. Dobry load balancer wystarczy - prędzej łącze się zapcha niż dobrze zaprojektowana baza "zamuli".Krzysztof Drelczuk edytował(a) ten post dnia 24.11.09 o godzinie 11:10

Temat: Muzyka w bazie

Bogdan Pieńkowski:

Paweł Grzegorz Kwiatkowski:
Odpowiedź padła w pierwszym poście - BLOB, a że o forum dyskusyjne, to wydaje mi się dość naturalne, że kolejne posty odbiegają od tematu głównego i nie ma się co krzywić z tego powodu i starać się trzymać pewien poziom wypowiedzi.

OK. To proszę o uzasadnienie BLOB-a dla serwisu WWW udostępniającego np. 500 utworów.

Przypomnę, że oryginalne zapytanie brzmiało JAK przychowywać pliki binarne w bazie, a nie czy ma to sens.

Dla 500 utworów nie widzę sensu robienia jakiegokolwiek serwisu. Natomiast widzę sens w wykorzystaniu BLOBów w bazie in memory dla systemów, które generują sporo read-only, powiedzmy o rozmiarze kilka(nascie) giga.

Jeżeli już mówimy o FS i BLOB-ach. Proszę o to przykład z ostatnich kliku miesięcy. System odpytuje 5 zasobów. Ilość odpytań ok 50 000/dobę. Istnieje konieczność logowania zarówno zapytania jak i odpowiedzi obie oczywiście XML. Co robi firma? FS be, zapiszemy do CLOB-ów (kompresja i owszem). Skutek przyrost bazy danych 1T/miesiąc. Koszty ok 0.5mln/miesiąc. Zapis w FS z kompresją oczywiście, zużycie zasobów ok. 1000 razy mniejsze.

Nie wiem skąd to taka oczywista oczywistość, że XML. Równie dobrze
można by to przechowywać binarnie. W końcu XML generuje spory narzut na wielkość danych, chociażby proste <FOO>1</FOO>, to 10:1.

Sam przyrost 1TB miesięcznie wydaje mi się spory jak na ten ruch. Jaka jest średnia wielkość requestu/response ? Jaki silnik bazodanowy?

Rozwiązanie o którym piszesz świadczy tylko o kompetencji osób zaangażowanych w sprzedaż tego systemu ;-)

Swoją drogą ciekawe jak wygląda struktura kosztów dla tego 0.5mln/m-c. To wszystko storage, czy też licencje / support, prąd ?

Z tego co widziałem na stronie SUNa, macierz na ~240 TB można kupić za 200k$, do tego pewnie dyski (ale to koszt, który można rozłożyć na lata zgodnie z planowanym przyrostem danych). Na pierwszy rzut oka zamykamy się w dużo niższej kwocie uwzględniając horyzont roczny.

pozdrawiam,

Temat: Muzyka w bazie

http://highscalability.com/youtube-architecture

tam był wykorzystany FS z metadanymi w bazie we wstępnej fazie

i jak dobrze rozumiem było to kosztowne. teraz dane są w partycjonowanej bazieKrzysztof Drelczuk edytował(a) ten post dnia 24.11.09 o godzinie 11:24

Temat: Muzyka w bazie

Krzysztof Drelczuk:
http://highscalability.com/youtube-architecture

Dzieki - ciekawy link. Szczegolnie"

Recipe for handling rapid growth
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

This loop runs many times a day.
;)

Temat: Muzyka w bazie

Krzysztof Drelczuk:

A jak się mają do tego koszty szeroko rozumianego utrzymania nawet jeżeli weźmiemy pod uwagę "darmową" bazę danych?

Mniejsze. Wszystko dostajemy z pudełka. Możemy to robić na tanich serwerach (hosting) a nie tylko na dedykowanych (brak prawa zapisu na dysku przez aplikacje). Łatwiej zachować spójność danych (patrz dyskusja - aby otrzymać ACID na np. MSSQl trzeba zrobić job'a, którego nie ma w Expresie). Łatwiej backupować, synchronizować i utrzymać bezpieczeństwo oraz kilka innych powodów wyżej już wymienionych.

komenda AT - lub kreator Task Sheulder-a
komenda CMDSQL
pliki CMD

nie tak wygodne jak JOBY, ale można odwzorować większość funkcjonalności, np. korzystając z dodatku http://www.sqldbatips.com/showarticle.asp?ID=27

Temat: Muzyka w bazie

Cóż, może wyskoczę jak Filip z konopii, ale... czy to nie jest tak, że ktoś po prostu nie potrafi obsłużyć mechanizmu BLOB, więc po prostu go nie stosuje zastępując innymi?

Jakiś czas temu szukałem rozwiązania problemu umieszczenia kilkudziesięciu... kilku tysięcy ikonek, małych pliczków z danymi w formie BLOBów w bazie. Zadałem konkretne pytanie, uzyskałem odp. od dwóch osób.:) (za które dziękuję)

Temat: Muzyka w bazie

Karol Z.:
Cóż, może wyskoczę jak Filip z konopii, ale... czy to nie jest tak, że ktoś po prostu nie potrafi obsłużyć mechanizmu BLOB, więc po prostu go nie stosuje zastępując innymi?

Albo ktos nie potrafi obsluzyc FS, wiec zastepuje go BLOBem?

Nie, poniewaz - jak juz wczesniej pisalismy - to zawsze zalezy od konkretnego problemu. Dla pewnych rozwiazan BLOB ma sens, dla innych nie ma, ot i cala filozofia.

Temat: Muzyka w bazie

A czemu nie połączyć przyjemnego (wydajność trzymania plików w FS) z pożytecznym (bezpieczeństwo i większa kontrola przy trzymaniu plików w bazie)?

Using FILESTREAM to Store BLOBs in the NTFS File System in SQL Server 2008

Temat: Muzyka w bazie

Suma sumarum znalazłem to czego szukałem. Faktycznie 'varbinary' super się nadaje i fajnie działa z LINQ.

Przykładowy kod, jeśli to kogoś interesuje(C# / LINQ / MSSQL 2005 Standard):

CREATE TABLE [dbo].[tSounds](
[id] [int] IDENTITY(1,1) NOT NULL,
[NAME] [varchar](50) NOT NULL,
[SOUND] [varbinary](max) NOT NULL,
CONSTRAINT [PK_tSounds] PRIMARY KEY CLUSTERED
(

DataClassesDataContext context = new DataClassesDataContext();
byte[] sample = System.IO.File.ReadAllBytes(@"c:\test.mp3");
tSound test = new tSound();
test.SOUND = sample;
context.tSounds.InsertOnSubmit(test);
context.SubmitChanges();

var query = from u in context.tSounds select u;
foreach (tSound item in query)
{
System.IO.File.WriteAllBytes(@"c:\test_z_bazy.mp3", item.SOUND.ToArray());
}

Dziękuję Państwu za pomoc i uwagi.Jakub Krupka edytował(a) ten post dnia 24.11.09 o godzinie 17:10

Temat: Muzyka w bazie

Może jeszcze dodam swoje 3 grosze.
Jestem Oracle'owcem i o tymże napiszę. Istnieje tutaj typ BLOB (Binary Large OBject). Można go użyć do przechowywania danych którymi może być np. plik mp3. To akurat zostało już napisane wcześniej.
Wiele osób nie zdaje sobie sprawy jak rozbudowany jest mechanizm obsługi BLOBów w Oracle. Poza zwykłym wrzuceniem danych do bazy mamy także możliwość wrzucenia BLOBa który jest linkiem do pliku w filesystemie. Możemy więc trzymać plik na dysku a baza nam się powinna zająć obsługą danych.
BLOBy (ogólnie LOBy) są inaczej traktowane przez bazę i dostęp do nich est nieco bardziej złożony - baza stara się oszczędzać na logach itp. przy operacjach na LOBach.
Wymienię teraz kilka zalet wrzucania pliku do bazy (w oparciu o Oracle):
- można klasyfikować pliki po kilku kluczach (w systemie plików mamy zwykle ściśle zdefiniowaną strukturę katalogów)
- możemy łatwo powiększać przestrzeń dyskową poprzez dorzucenie datafile'a (w systemie plików zazwyczaj podmontowujemy nowy dysk - często sieciowy jeśli nasz projekt jest "duży")
- kasowanie danych które uznaliśmy za "stare" może być bardzo proste i wydajne: ALTER TABLE DROP PARTITION
- do bazy możemy się łączyć po TCP i możemy ją również klastrować - więc możemy też rozszerzać architekturę systemu horyzontalnie
- kompresja może być obsługiwana przez nas, przez filesystem lub też przez aplikację ładującą plik

Jeśli ktoś chce korzystać z LINQ przy dostępie do dużych plików binarnych to uwaga na pamięć... mapowanie dużych struktur do obiektów w pamięci wiąże się ze zwiększonymi wymaganiami odnośnie pamięci (chociaż LINQ to fajny tool).
Podstawową sprawą przy wyborze bazy danych przechowywującej pliki audio powinno być określenie warunków w jakich ta baza ma pracować (np. ilość danych przechowywanych, częstotliwość/szybkość ładowania nowych danych, zastosowanie, ...).

Pozdrawiam

Temat: Muzyka w bazie

Stanowczo zgadzam się że trzymanie danych medialnych w bazie danych niesie za sobą duże korzyści. O bezpieczeństwie było już pisane, jeśli już jednak mowa o Oracle to można także, korzystając z pakietu interMedia np implementować mechanizmy wyszukiwania po zawartości danych multimedialnych.

W ogóle pakiet interMedia prezentuje całkiem ciekawe możliwości
w kontekście danych medialnych takich jak obraz (dla obrazków jest więcej gotowych algorytmów) czy dźwięk (tu jako że mamy do czynienia z medium zmiennym w czasie i bardziej złożonym niźli statyczny obraz w 10g nie ma jeszcze mechanizmów gotowych i trzeba nad nimi samemu popracować, z 11g nie pracowałem w kontekście danych MM) i warto go wziąć pod lupę przy okazji umieszczania takich danych w Oracle DBMS.Jan Wieremjewicz edytował(a) ten post dnia 25.11.09 o godzinie 09:36