Porównaj ceny domen i usług IT, sprzedawców z całego świata

Przechowywanie miliona obrazów w systemie plików


Mam projekt, który wygeneruje ogromną ilość obrazów. Na początek około 1 000 000. To są małe obrazy, więc zatrzymam je wszystkie na tym samym komputerze podczas uruchamiania.
Jak radzisz wydajnie przechowywać te obrazy? (Obecnie system plików NTFS)
Zastanawiam się nad schematem nazewnictwa ... na początek wszystkie obrazy będą miały przyrostową nazwę od 1 do Mam nadzieję, że pomoże mi to później posortować je w razie potrzeby i wrzucić do różnych folderów.
który schemat nazewnictwa byłby lepszy:
a/b/c/0 ... z/z/z/999lub
a/b/c/000 ... z/z/z/999masz jakieś pomysły na ten temat?
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Zalecałbym używanie zwykłego systemu plików zamiast baz danych. Łatwiej jest używać systemu plików niż bazy danych, możesz użyć zwykłych narzędzi, aby uzyskać dostęp do plików, systemy plików są zaprojektowane do tego celu itp. NTFS powinien działać dobrze jako system pamięci masowej.
Nie przechowuj rzeczywistej ścieżki do bazy danych. Lepiej jest przechowywać numer kolejny obrazu w bazie danych i mieć funkcję, która może generować ścieżkę na podstawie numeru sekwencyjnego. na przykład:
File path = generatePathFromSequenceNumber(sequenceNumber);

Łatwiej sobie z tym poradzić, jeśli musisz w jakiś sposób zmienić strukturę katalogów. Być może musisz przenieść obrazy w inne miejsce, być może zabraknie Ci miejsca i zaczniesz przechowywać niektóre obrazy na dysku A, a niektóre na dysku B, itp. Łatwiej jest zmienić jedną funkcję niż zmienić ścieżki w bazie danych.
Do stworzenia struktury katalogów użyłbym takiego algorytmu:
  • Najpierw wprowadź numer kolejny z zerami na początku, aż uzyskasz co najmniej 12-cyfrowy ciąg. To jest nazwa twojego pliku. Możesz dodać sufiks: [list][*]
                   12345             
    ->
                   000000012345.jpg             

[/*]
[*]
Następnie podziel ciąg na bloki po 2 lub 3 znaki, gdzie każdy blok reprezentuje poziom katalogu. Miej stałą liczbę poziomów katalogu (np. 3):
  •                000000012345             
    ->
                   000/000/012             

[/*]
[*]
Zapisz plik w wygenerowanym katalogu:
  • Zatem pełna ścieżka i nazwa pliku z identyfikatorem sekwencji to
                   123             
    jest
                   000/000/012/00000000012345.jpg             
  • Dla pliku z identyfikatorem sekwencji
                   12345678901234             
    tak będzie
                   123/456/789/12345678901234.jpg             

[/*]
[/list]
Kilka kwestii do rozważenia dotyczących struktur katalogów i przechowywania plików:
  • Powyższy algorytm zapewnia system, w którym każdy katalog docelowy zawiera maksymalnie 1000 plików (zakładając, że masz mniej niż 1 000 000 000 000 plików).
  • Na przykład mogą istnieć ograniczenia dotyczące liczby plików i podkatalogów, które może zawierać katalog System plików Linux ext3 http://en.wikipedia.org/wiki/Ext3ma limit 31998 podkatalogów na katalog.
  • Popularne narzędzia (WinZip, Eksplorator Windows, wiersz poleceń, powłoka bash itp.) Mogą nie działać zbyt dobrze, jeśli masz dużą liczbę plików w katalogu (> 1000).
  • Sama struktura katalogów zajmie trochę miejsca na dysku, więc nie potrzebujesz zbyt wielu katalogów.
  • Dzięki powyższej strukturze zawsze możesz znaleźć poprawną ścieżkę do pliku obrazu, po prostu patrząc na nazwę pliku na wypadek, gdyby przypadkowo zepsułeś strukturę katalogów.
  • Jeśli chcesz uzyskać dostęp do plików z wielu komputerów, rozważ udostępnienie plików za pośrednictwem sieciowego systemu plików.
  • Powyższa struktura katalogów nie będzie działać, jeśli usuniesz dużo plików. Pozostawia to „dziury” w strukturze katalogów. Ale ponieważ nie usuwasz plików, powinno być dobrze.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Zamierzam wystawić moje 2 centy na negatywną radę: nie używaj bazy danych.
Od lat pracuję z bazami danych do przechowywania obrazów: duże (1 megabajt -> 1 gigabajt) pliki, które często się zmieniają, wiele wersji pliku, do których często uzyskuje się dostęp. Problemy z bazą danych, które napotykasz podczas przechowywania dużych plików, są niezwykle uciążliwe, problemy z zapisem i transakcjami są zawiłe i napotykasz problemy z blokowaniem, które mogą spowodować poważne wraki pociągów. Mam więcej praktyki w tworzeniu skryptów dbcc i przywracaniu tabel z kopii zapasowych niż ktokolwiek inny.

zawsze

mieć.
Większość nowych systemów, z którymi pracowałem, przeniosła magazyn plików do systemu plików i polegała na bazach danych jedynie w celu indeksowania. Systemy plików są zaprojektowane do tego rodzaju nadużyć, są znacznie łatwiejsze do rozszerzenia i rzadko tracisz cały system plików, jeśli jeden wpis zostanie uszkodzony.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Myślę, że większość witryn, które muszą sobie z tym poradzić, używa pewnego rodzaju skrótu, aby pliki były równomiernie rozmieszczone w folderach.
Powiedzmy, że masz skrót pliku, który wygląda mniej więcej tak
         515d7eab9c29349e0cde90381ee8f810

Możesz to zapisać w następującej lokalizacji i używać tylu poziomów, ile potrzebujesz, aby liczba plików w każdym folderze była niewielka.
         \51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg
Wielokrotnie widziałem to podejście. Nadal potrzebujesz bazy danych, aby zamapować te skróty plików na nazwę czytelną dla człowieka i inne metadane, które musisz zachować. Ale to podejście skaluje się dobrze, ponieważ możesz rozpocząć dystrybucję przestrzeni adresowej skrótu na wiele komputerów i/lub pul pamięci itp.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Najlepiej byłoby uruchomić wiele testów czasu dostępu swobodnego dla różnych struktur, ponieważ określone ustawienia dysku twardego, buforowanie, dostępna pamięć itp. Mogą zmienić te wyniki.
Zakładając, że masz kontrolę nad nazwami plików, podzieliłbym je na 1000s na katalog. Im więcej poziomów katalogów dodasz, tym więcej i-węzłów piszesz, dlatego występuje tutaj push-pull.
Na przykład.,
/root/[0-99]/[0-99]/nazwa pliku
Notatka,

http://technet.microsoft.com/e ... 81134(WS.10).aspx
http://technet.microsoft.com/e ... 81134(WS.10).aspx
więcej informacji na temat konfigurowania systemu plików NTFS. W szczególności: „Jeśli używasz dużej liczby plików w folderze NTFS (300 000 lub więcej), wyłącz generowanie krótkich nazw plików, aby zwiększyć wydajność, zwłaszcza jeśli pierwsze sześć znaków długich nazw plików jest podobnych”.
Powinieneś także przyjrzeć się wyłączaniu funkcji systemu plików, których nie potrzebujesz (np. Czas ostatniego dostępu).

http://www.pctools.com/guides/registry/detail/50/
http://www.pctools.com/guides/registry/detail/50/
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Cokolwiek robisz, nie trzymaj ich wszystkich w jednym katalogu.
W zależności od rozmieszczenia nazw tych obrazów, możesz utworzyć strukturę katalogów, w której masz foldery najwyższego poziomu z jedną literą, gdzie masz inny zestaw podfolderów dla drugiej litery obrazów i tak dalej.
Więc:
Teczka
         img\a\b\c\d\e\f\g\
będzie zawierać obrazy zaczynające się od „abcdefg” i tak dalej.
Możesz wprowadzić wymaganą głębokość.
Wspaniałą rzeczą w tym rozwiązaniu jest to, że struktura katalogów skutecznie działa jak tablica skrótów/słownik. Znając nazwę pliku obrazu, poznasz jego katalog, a mając dany katalog, poznasz podzbiór obrazów, które tam trafiają.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Mamy system przechowywania zdjęć z 4 milionami zdjęć. Używamy bazy danych tylko dla metadanych, a wszystkie obrazy są przechowywane w systemie plików przy użyciu systemu odwrotnego nazewnictwa, w którym nazwy folderów są generowane z ostatniej cyfry pliku, ostatnia cyfra 1, itp. Np .: 000001234.jpg jest przechowywany w strukturze katalogów, takiej jak 4 \ 3 \ 2 \ 1 \ 000001234.jpg.
Ten schemat działa bardzo dobrze z indeksem tożsamości w bazie danych, ponieważ równomiernie wypełnia całą strukturę katalogów.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nowy MS SQL 2008 ma nową funkcję do obsługi takich przypadków, nazywa się FILESTREAM. Spójrz:
Przegląd Microsoft TechNet FILESTREAM
http://technet.microsoft.com/e ... .aspx
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Przechowałbym je w systemie plików, ale to zależy od tego, jak szybko rośnie liczba plików. Czy te pliki są w Internecie? Ilu użytkowników będzie miało dostęp do tego pliku? Oto pytania, na które należy odpowiedzieć, zanim dam ci lepszą rekomendację. Spojrzałbym też na Haystack z Facebooka, mają bardzo dobre rozwiązanie do przechowywania i serwowania zdjęć.
Ponadto, jeśli wybierzesz system plików, będziesz musiał podzielić te pliki na katalogi. Zbadałem ten problem i znalazłem rozwiązanie, ale w żadnym wypadku nie jest ono doskonałe. Dzielę partycje według tablicy skrótów i użytkowników, więcej możesz dowiedzieć się na moim

blog
http://blinkered.ca/blog/2009/ ... stem/
.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:


Czy będziesz musiał nadać swoim obrazom jednoznaczną nazwę?

Czy proces, który generuje te obrazy, może utworzyć tę samą nazwę pliku więcej niż raz? Trudno powiedzieć, nie wiedząc, które urządzenie tworzy nazwę pliku, ale powiedzieć, że urządzenie jest „restartowane” i po ponownym uruchomieniu zaczyna nazywać obrazy tak, jak było to ostatnim razem, gdy było „resetowane” - jeśli to jest taki problem. .
Ponadto twierdzisz, że miesięcznie otrzymujesz milion obrazów. Co powiesz na to?

Jak szybko te obrazy będą nadal wypełniać system plików?

W pewnym momencie zostaną uzupełnione i wyrównane do około 1 miliona RAZEM obrazów lub

czy będzie rósł i rósł z miesiąca na miesiąc?

Pytam, ponieważ możesz zacząć projektować swój system plików miesiąc po miesiącu, a potem obrazy. Mogę zasugerować przechowywanie obrazów w takiej strukturze katalogów:
imgs\yyyy\mm\filename.extwhere: yyyy = 4 digit year
mm = 2 digit monthexample: D:\imgs\2009\12\aaa0001.jpg
D:\imgs\2009\12\aaa0002.jpg
D:\imgs\2009\12\aaa0003.jpg
D:\imgs\2009\12\aaa0004.jpg
|
D:\imgs\2009\12\zzz9982.jpg
D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
D:\imgs\2010\01\aab0001.jpg

Miesiąc, rok, a nawet dzień są odpowiednie dla obrazów typu ochronnego. Nie jestem pewien, czy to właśnie robisz, ale zrobiłem to z domową kamerą bezpieczeństwa, która robiła zdjęcie co 10 sekund ... Więc twoja aplikacja może przeskoczyć do określonego czasu lub nawet zakresu, który może pomyśleć wygenerowane. Albo zamiast roku, miesiąca - czy istnieje inna „wartość”, którą można wyodrębnić z samego pliku obrazu? Czy są jakieś inne deskryptory oprócz podanego przeze mnie przykładu daty?
Nie przechowywałbym danych binarnych w bazie danych. Nigdy nie miałem dobrej pracy/szczęścia w tego typu sprawach. Nie mogę sobie wyobrazić, że działa dobrze z 1 milionem zdjęć. Zachowałbym nazwę pliku i to wszystko. Jeśli wszystkie są w formacie JPG, nawet nie zapisuj rozszerzenia. Utworzyłbym tabelę sterującą, która przechowuje wskaźnik serwera, dysk, ścieżkę do pliku itd. W ten sposób można przenieść te obrazy do innego pola i nadal je znajdować.

Chcesz oznaczyć obrazy słowami kluczowymi?

Jeśli tak, to musisz stworzyć odpowiednie tabele, które pozwolą na takie nakładanie się.
Ty/inni mogliście omawiać te pomysły, kiedy odpowiadałem .. Mam nadzieję, że to pomoże ..
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Krótko mówiąc, nie musisz przechowywać ścieżki pliku w swojej bazie danych. Możesz po prostu zapisać wartość liczbową, jeśli twoje pliki są nazwane tak, jak opisujesz. Następnie, korzystając z jednego z dobrze zdefiniowanych schematów przechowywania, które zostały już omówione, możesz pobrać indeks jako liczbę i bardzo szybko znaleźć plik, patrząc na strukturę katalogów.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jestem zaangażowany w projekt, który przechowuje 8,4 miliona obrazów w ciągu roku, aby udokumentować stan różnych urządzeń. Nowsze obrazy są częściej dostępne, a starsze obrazy są rzadko wyszukiwane, chyba że zostanie znaleziony warunek, który skłonił kogoś do kopania w archiwach.
Opierając się na tym zastosowaniu, moim rozwiązaniem było stopniowe archiwizowanie obrazów w skompresowanych plikach. Obrazy są w formacie JPG, każdy o wielkości około 20KB i niezbyt skompresowany, więc nie ma schematu kompresji ZIP. Odbywa się to po prostu w celu połączenia ich w jeden wpis systemu plików, co znacznie pomaga NTFS pod względem szybkości, jeśli chodzi o przenoszenie ich z dysku na dysk lub przeglądanie listy plików.
Obrazy starsze niż jeden dzień są łączone w „codzienne” zip; kody pocztowe starsze niż miesiąc są łączone w odpowiadające im „miesięczne” kody pocztowe; i wreszcie wszystko, co ma więcej niż rok, nie jest już potrzebne i dlatego jest usuwane.
Ten system działa dobrze, ponieważ użytkownicy mogą przeglądać pliki (za pośrednictwem systemu operacyjnego lub wielu aplikacji klienckich), a wszystkie nazwy są nazywane na podstawie nazw urządzeń i sygnatur czasowych. Zwykle użytkownik zna te dwie informacje i może szybko znaleźć dowolny z milionów obrazów.
Zdaję sobie sprawę, że prawdopodobnie nie jest to związane z twoimi konkretnymi szczegółami, ale pomyślałem, że podzielę się.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałbym tendencję do tworzenia struktury folderów na podstawie daty, takiej jak \ rok \ miesiąc \ dzień i używania sygnatur czasowych dla nazw plików. W razie potrzeby sygnatury czasowe mogą mieć dodatkowy składnik licznika, jeśli obrazy mają być generowane tak szybko, że w ciągu milisekundy może ich być więcej niż jeden. Używając kolejności od najbardziej do najmniej znaczących do sortowania nazw, wyszukiwanie i utrzymanie jest łatwe. np. hhmmssmm [seq] .jpg
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Mogę się na to spóźnić. Ale jednym rozwiązaniem (jeśli pasuje do twojego przypadku użycia) może być haszowanie nazwy pliku. Jest to sposób na utworzenie łatwo odtwarzalnej ścieżki do pliku przy użyciu nazwy pliku, a także na stworzenie dobrze rozproszonej struktury katalogów. Na przykład możesz użyć bajtów kodu skrótu nazwy pliku jako ścieżki:
String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

W rezultacie ścieżka będzie:
/172/029/cat.gif

Wtedy możesz znaleźć
         cat.gif
w strukturze katalogów poprzez odtworzenie algorytmu.
Używanie HEX jako nazw katalogów jest tak proste, jak konwersja
         int
wartości:
String path = new StringBuilder(File.separator)
.append(String.format("x", firstDir))
.append(File.separator)
.append(String.format("x", secondDir)
.toString();

Wynik:
/AC/1D/cat.gif

Napisałem o tym artykuł kilka lat temu i niedawno przeniosłem się na Medium. Zawiera więcej szczegółów i przykładowy kod:

Haszowanie nazw plików: Utwórz zaszyfrowaną strukturę katalogów
https://medium.com/%40michael. ... 91... Mam nadzieję że to pomoże!
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Chociaż nie przesłałem zdjęć w tej skali, wcześniej napisałem małą galerię do obsługi ~ 25k obrazów na maszynie 400 MHz w. Około 512 MB pamięci RAM. Jakieś doświadczenie;
  • Unikaj relacyjnych baz danych za wszelką cenę; chociaż bazy danych bez wątpienia mogą obsługiwać dane, nie są one przeznaczone do tego celu (mamy wyspecjalizowane hierarchiczne bazy danych klucz-wartość dla tego, systemy plików ). Chociaż mam tylko przeczucie, założę się, że pamięć podręczna DB wyskoczy przez okno, jeśli rzucisz w nią naprawdę dużymi plamami. Podczas gdy mój dostępny sprzęt był rzadki, bez dotykania bazy danych podczas wyszukiwania obrazów, prędkość była o rząd wielkości większa.
  • Sprawdź, jak zachowuje się system plików; na ext3 (a wtedy było to ext2 - nie pamiętam) limit możliwości sprawnego wyszukiwania podkatalogów i plików wynosił około 256; więc w każdym folderze jest tylko tyle plików i folderów. Znowu zauważalne przyspieszenie. Chociaż nie wiem nic o NTFS, rzeczy takie jak XFS (które pamiętam przy użyciu B-drzew) są bardzo szybkie po prostu dlatego, że potrafią bardzo szybko wyszukiwać.
  • Dystrybuuj dane równomiernie; kiedy eksperymentowałem z powyższym, próbowałem rozłożyć dane równomiernie we wszystkich katalogach (utworzyłem adresy URL MD5 i użyłem ich do katalogów;
    /1a/2b/1a2b...f.jpg           
    ). Dlatego osiągnięcie dowolnego ustawionego limitu wydajności zajmuje więcej czasu (a pamięć podręczna systemu plików i tak jest pusta dla tak dużych zestawów danych). (wręcz przeciwnie, możesz chcieć zobaczyć, gdzie są ograniczenia na wczesnym etapie; wtedy chcesz wrzucić wszystko do pierwszego dostępnego katalogu.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Czy rozważasz odzyskiwanie po awarii?
Niektóre z sugerowanych tutaj rozwiązań prowadzą do uszkodzenia nazwy pliku (na przykład, jeśli fizyczny plik został przeniesiony, stracisz pojęcie, czym naprawdę jest plik). Zalecam zachowanie unikalnej fizycznej nazwy pliku, aby w przypadku uszkodzenia głównej listy lokalizacji plików można było ją przywrócić za pomocą małej powłoki, uh, powershell, skryptu;)
Z tego, co tutaj przeczytałem, wygląda na to, że wszystkie te pliki będą przechowywane w tym samym systemie plików. Rozważ przechowywanie ich w wielu systemach plików na wielu komputerach. Jeśli masz zasoby, zdefiniuj system przechowywania dla każdego pliku na dwóch różnych komputerach na wypadek utraty zasilania, a jego wymiana zajmie 2 dni.
Zastanów się, jakie procedury będziesz musiał utworzyć, aby przesłać pliki między maszynami lub systemami plików. Możliwość zrobienia tego za pomocą systemu w czasie rzeczywistym i online może zaoszczędzić wiele bólu głowy w przyszłości.
Możesz rozważyć użycie identyfikatora GUID jako fizycznej nazwy pliku zamiast przyrostowej liczby na wypadek, gdyby Twój licznik przyrostowy (kolumna z identyfikatorem bazy danych?) Się pomylił.
W razie potrzeby rozważ użycie CDN, takiego jak Amazon S3.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Być może schemat nazewnictwa oparty na dacie utworzenia - albo uwzględniający wszystkie informacje w nazwie pliku, albo (lepiej do późniejszego przejrzenia) dzielący go na katalogi. W zależności od tego, jak często tworzysz obrazy, przychodzą mi do głowy następujące rzeczy:
  • Codziennie generowanych jest kilka obrazów:
               Year/Month/Day/Hour_Minute_Second.png         
  • Kilka w miesiącu:
               Year/Month/Day_Hour_Minute_Second.png         

itp. Rozumiesz mnie ... =)
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Widzę inne wzmianki o bazie danych, ale nie widzę żadnej wzmianki o tym w Twoim poście. W każdym razie moja opinia na ten temat jest taka: trzymaj się bazy danych lub systemu plików. Jeśli chcesz je wymieszać, bądź ostrożny. Sprawy się komplikują. Ale być może będziesz musiał. Przechowywanie miliona zdjęć w bazie danych nie jest dobrym pomysłem.
Możesz być zainteresowany następującą specyfikacją, większość aparatów cyfrowych stosuje ją do zarządzania przechowywaniem plików:

https://en.wikipedia.org/wiki/ ... ormat
https://en.wikipedia.org/wiki/ ... ormat
Zasadniczo folder jest tworzony jak
         000OLYMPUS
a zdjęcia są dodawane do tego folderu (na przykład
         DSC0000.RAW
). Gdy licznik nazw plików osiągnie
         DSC9999.RAW
tworzony jest nowy folder (
         001OLYMPUS
) i obraz jest dodawany ponownie, licznik jest resetowany, ewentualnie z innym prefiksem (na przykład:
         P_0000.RAW
).
Alternatywnie możesz także tworzyć foldery na podstawie części nazwy pliku (wspomnianych już kilka razy). Na przykład, jeśli Twoje zdjęcie nazywa się
         IMG_A83743.JPG
, przechowywać
         IMG_\A8\3\IMG_A83743.JPG
... Jest trudniejszy do zaimplementowania, ale ułatwi wyszukiwanie plików.
W zależności od systemu plików (zajmie to trochę badań), możesz po prostu zrzucić wszystkie obrazy do jednego folderu, ale z mojego doświadczenia wynika, że ​​zwykle powoduje to problemy z wydajnością.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Właśnie przeprowadziłem test na zfs, ponieważ lubię zfs i miałem partycję o pojemności 500 GB, która została skompresowana. Napisałem skrypt, który wygenerował 50-100 tys. Plików i umieściłem je w zagnieżdżonych katalogach 1/2/3/4/5/6/7/8 (głębokość 5-8) i pozwoliłem mu działać przez, myślę, 1 tydzień. (To nie był najlepszy scenariusz.) Wypełnił dysk i skończył z około 25 milionami plików. Dostęp do dowolnego pliku ze znaną ścieżką był natychmiastowy. Wyświetlenie dowolnego katalogu ze znaną ścieżką było natychmiastowe.
Jednak obliczenie listy plików (za pomocą funkcji find) zajęło 68 godzin.
Przeprowadziłem również test, umieszczając wiele plików w jednym katalogu. Zanim przestałem, miałem około 3,7 miliona plików w jednym katalogu. Wyświetlenie katalogu do zliczenia zajęło około 5 minut. Usunięcie wszystkich plików z tego katalogu zajęło 20 godzin. Ale znalezienie i dostęp do dowolnego pliku było natychmiastowe.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli WSZYSTKIE nie są wymagane od razu i można je generować w locie, a są to małe obrazy, dlaczego nie zaimplementować pamięci LRU lub pamięci podręcznej dysku nad generatorem obrazu?
Czy może to zaoszczędzić miejsce na dysku i zachować gorące obrazy do udostępniania z pamięci?
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli korzystasz z systemu Windows, co z systemem plików exFat?
http://msdn.microsoft.com/en-u ... .aspx
http://msdn.microsoft.com/en-u ... .aspx
został zaprojektowany z myślą o przechowywaniu multimediów i jest już dostępny.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Łatwym sposobem na wygenerowanie ścieżki z dużej liczby jest łatwe przekonwertowanie jej na hex, a następnie podzielenie!
na przykład
         1099496034834
>
         0xFFFF1212
>
         FF/FF/12/12
public string GeneratePath(long val)
{
string hex = val.ToString("X");
hex=hex.PadLeft(10, '0');
string path="";
for(int i=0; i<hex.Length; i+=2 )
{
path += hex.Substring(i,2);
if(i+2<hex.Length)
path+="/";
}
return path;
}

Przechowywanie i ładowanie:
public long Store(Stream doc)
{
var newId = getNewId();
var fullpath = GeneratePath(newId)
// store into fullpath
return newId;
}public Stream Load(long id)
{
var fullpath = GeneratePath(newId)
var stream = ...
return stream;
}

Pełne kody źródłowe:

https://github.com/acrobit/AcroFS
https://github.com/acrobit/AcroFS
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Możesz rzucić okiem na ZFS (system plików, menedżer woluminów firmy Sun)
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Niestety systemy plików są bardzo słabe (wydajność z wieloma plikami w katalogu lub głębokimi drzewami katalogów, czas sprawdzania przy ponownym uruchomieniu, niezawodność) podczas zarządzania wieloma małymi plikami, więc powyższe rozwiązanie, które obejmuje pliki ZIP, jest najlepsze, jeśli chcesz użyć pliku system.
Korzystanie z menedżera bazy danych jest zdecydowanie najlepszą opcją; proste, jak BDB lub GDBM; nawet względny DBMS, taki jak MySQL, byłby lepszy. Tylko leniwi ludzie, którzy nie rozumieją systemów plików i baz danych (na przykład ci, którzy odrzucają transakcje) mają tendencję do używania systemów plików jako baz danych (lub nieco rzadziej i odwrotnie).
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

A co z bazą danych z tabelą zawierającą identyfikator i obiekt blob do przechowywania obrazu? Następnie możesz dodać nowe tabele, gdy chcesz powiązać więcej elementów danych ze zdjęciem.
Jeśli spodziewasz się skalowania, dlaczego nie skalować go teraz? Zaoszczędzisz czas zarówno teraz, jak i później, IMO. Zaimplementuj warstwę bazy danych raz, co jest dość łatwe do rozpoczęcia. Lub zaimplementuj coś z folderami i nazwami plików i bla bla bla, a następnie przełącz się na coś innego, gdy zaczniesz wysadzać MAX_PATH.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się