Mamy taki system w ciężkiej produkcji z ponad 30 000 plików i ponad 20 GB do tej pory...
Column | Type | Modifiers
-------------+-----------------------------+----------------------------------------------------------
File_ID | integer | not null default nextval('"ACRM"."File_pseq"'::regclass)
CreateDate | timestamp(6) with time zone | not null default now()
FileName | character varying(255) | not null default NULL::character varying
ContentType | character varying(128) | not null default NULL::character varying
Size | integer | not null
Hash | character varying(40) | not null
Indexes:
"File_pkey" PRIMARY KEY, btree ("File_ID")
Pliki są po prostu przechowywane w jednym katalogu z liczbą całkowitą File_ID jako nazwą pliku. Mamy ponad 30 000 bez żadnych problemów. Testowałem wyżej bez żadnych problemów.
To używa RHEL 5 x86_64 z ext3 jako systemem plików.
Czy zrobiłbym to ponownie w ten sposób? Nie. Pozwólcie, że podzielę się kilkoma przemyśleniami na temat przeprojektowania.
-
Baza danych jest nadal „głównym źródłem” informacji o plikach.
-
Każdy plik jest haszowany sha1() i przechowywany w hierarchii systemu plików na podstawie tego skrótu:
/FileData/ab/cd/abcd4548293827394723984723432987.jpg -
baza danych jest nieco mądrzejsza w przechowywaniu metainformacji w każdym pliku. Byłby to system trzech stołów:
File:przechowuje informacje, takie jak nazwa, data, adres IP, właściciel i wskaźnik do obiektu Blob (sha1)File_Meta:przechowuje pary klucz/wartość w pliku, w zależności od typu pliku. Może to obejmować informacje takie jak Image_Width itp...Blob:przechowuje odniesienie do sha1 wraz z jego rozmiarem.
Ten system usuwałby duplikaty zawartości pliku, przechowując dane, do których odwołuje się skrót (wiele plików może odwoływać się do tych samych danych pliku). Bardzo łatwo byłoby wykonać kopię zapasową, zsynchronizować bazę danych plików za pomocą rsync.
Ponadto wyeliminowane zostałyby ograniczenia danego katalogu zawierającego wiele plików.
Rozszerzenie pliku będzie przechowywane jako część unikalnego skrótu pliku. Na przykład, jeśli hash dla pustego pliku to abcd8765 ... Pusty plik .txt plik i pusty .php plik odwołuje się do tego samego skrótu. Powinny raczej odnosić się do abcd8765.php i abcd8765.txt . Dlaczego?
Apache itp. można skonfigurować tak, aby automatycznie wybierał typ zawartości i reguły buforowania na podstawie rozszerzenia pliku. Ważne jest, aby przechowywać pliki z prawidłową nazwą i rozszerzeniem, które odzwierciedla zawartość pliku.
Widzisz, ten system może naprawdę zwiększyć wydajność, delegując dostarczanie plików za pośrednictwem nginx. Zobacz http://wiki.nginx.org/XSendfile .
Mam nadzieję, że to w jakiś sposób pomoże. Uważaj.
