2009-09-04 pgsql large objects
by Vasil KolevИ нещо по тема, която отдавна ме трови…
Използването на Large Objects (наричани по-нататък ебекти) в Postgres е вредно за здравето. Бавно е, криво и неудобно от почти всички гледни точки.
Да почнем с това, че е бавно. По лични наблюдения ваденето на ебект от postgres е около 3-4 пъти по-бавно от ваденето му от файловата система (понеже най-малкото трябва да се преточи през някакво IPC). Ако се работи по мрежа, да речем, че разликата е минимална на ПЪРВОТО достъпване до файла, след това има кеш (например при NFS, който аз използвам за заместител в такива случаи, и който си работи прекрасно).
Достъпването на ебект също е сравнително по-бавно (в сравнение пак с файл в директория). Би трябвало всички да са наясно, че всяка свястна файлова система размазва всяка база данни (даже тефтерчето mysql, което за някои неща има способността да е нечовешки бързо) на търсене по единичен индекс (който е директорийната структура). Аз лично още не съм видял база, дето да може да се сравни с reiserfs 3 (не съм тествал с 4 или с directory index-ите на ext4). Lookup-а във файлова система е оптимизиран за ЕДНО нещо, и то се оказва точно това, което трябва.
(няма да говоря как се реализира ебекта в postgres, страничка по страничка и т.н.)
Неудобството за работа от гледна точка на програмиста също го има, защото се работи с отделни функции да се създаде обекта, да се налее, след което OID-а му се сипва някъде като link, за да можем да стигнем до него. Ползва се базата като калпав block device, което поне аз намирам за глупаво.
А за неудобството от гледна точка на админа ако почна да говоря подробно, вероятно ще ме затворят за смущаване на обществения морал. Не може например да се каже на dump-а “сложи ми отделно ебектите”, не се поддават лесно на incremental backup (не че самата база се поддава), backup-а им е един малък ад, а възстановяването – друг такъв. Даже на свестен хардуер на човек му се иска да застреля някой – имам чувството, че еквивалентна база по размер на тая с ебектите и с индексите си се качва по-бързо…
Не знам, може в някоя друга база ебектите да са реализирани свястно и да нямам желание без да искам да ги drop-на всички, но специално в postgres са малък ужас.
(ако ги забързат и ми реализират rsync поне само за ебектите, може да си променя донякъде мнението)
(също така държа да отбележа, postgres все още ми е любимата база)
(а също така поне според мен е ВЪРХЪТ на простотията в една база да се държат ВСИЧКИ генерирани до тук PDF-и на фактури на клиенти, ама за тоя проект просто не успях да ги убедя. Поне в един друг не държим в базата видеата и картинките..)
September 5th, 2009 at 12:13
Напълно подкрепям! До ден днешен не мога да проумея ползата от цялата идея с пазенето на файлове в база данни. Цялото концепция ми звучи като абсолютно безмислено упражнение по вкарване на още няколко нива на абстракция – нещо, по което “програмистите” си падат изключително много. Нещо като едно оплакване от потребител, което получих на едно предишно работно място. Писмото се състоеше от две думи в Subject-а – “Problemi s internet!” и прикачен MS Word файл, в който имаше paste на screenshot на cmd.exe с ping (!) до машина в Уганда с 1% загуби. Go figure.
“Програмисти”, моля, за благото на човечеството, за децата – KISS!
BLOB-овете са измислени за пазене на сурови данни, _в_ които да можете да търсите (hint: битове, маски, перуки и други подобни) и които биха заемали доста по-голям обем, ако се структурират. До сега съм виждал три смислени real-world приложения на BLOB. Едното пазеше детайлна прогноза на ветрове (Postgres), другото сурови данни от датчици (Postgres и Oracle), а третото резултати от тестове (Oracle). Към безумиците спадат система видеонаблюдение (10000-20000 JPEG на ден) MS-SQL и системи за документооборот – doc и xls, pdf (MySQL и MS-SQL).
Скъпи програмисти, за съхранение на файлове имаме измислени хиляди специализирани бази данни – наричат се файлови системи – използвайте ги!
September 5th, 2009 at 13:11
Струва ми се че плюете блобовете незаслужено. Най-малкото в случай на системи за документооборот е много по-лесно да пазят различни версии на файловете. Освен това много по-лесно се организира достъпа.
September 5th, 2009 at 18:03
@ceci_: Аз (а до колкото разбирам и Васил) не плюем BLOB-овете. Как и защо според теб е по-лесно да се пазят различните версии на файловете в базата, отколкото като файлове? Аз лично не виждам проблеми организирането на достъпа (AAA, нали така?) да се извършва от базата без самите файлове да са вътре.
September 6th, 2009 at 09:20
Ами, как ще доставяш файловете до клиента? чрез файл-шеринг? А как ще се изменят, ще се надяваш на правата на ОС-та?
September 6th, 2009 at 09:56
@ceci_, ми както го правиш по принцип, просто вместо от базата ги вадиш от файловата система (в повечето случаи това става през някакво http), просто имаш два storage-а – една база и една файлова система. Останалото си е съвсем същото :)
Това за правата не го схванах.
September 6th, 2009 at 10:32
Има голям смисъл binary данните да бъдат в DB-то: просто всичките ти данни ще са на едно място и ще ги управляваш по един и същ начин, с едно и също API. Съвременните бази данни имат и достатъчно библиотеки, които ще помогнат ако трябва да се прави някакъв post processing – извличане на параметри на обектите, налагане на слоеве и пр. Не, че не може да се свърши и на FS, но отново попадаме на разликата в API-тата, все отговорни за достъпа до данните.
Кеш имаш винаги, дори преди години беше модерно Oracle да се инсталира на raw дялове, демек без да се минава през файловата система, направо DB-то си управлява диска на блоково ниво. Сега се разработили специални файлови системи, които бъкат със всички необходими им features + специфични за конкретното DB (OCFS/OCFS2/ASM и т.н.)
Още аргументи имам, но за да не узурпирам блога ще отбележа, че някъде имплементацията може да е по-крива за използване, с по-ниска производителност и т.н., но всичко това подлежи на подобрение, още повече когато говорим за система с отворен код ;)
September 6th, 2009 at 11:44
@Alex Stanev, аз говоря за postgres, където api-то е същото като за към файлова система (отделно се отварят обекти и т.н.),не говоря даже за blob-ове в таблици… Колкото за еднаквия интефейс, понякога той не е предимство:) За мен файла си е фундаментално различен от всичко, което е в базата и поне според мен би трябвало да се третира различно (иначе например може да се стигне до момента да се ползва интерфейса на базата данни за мрежови комуникации например, select * from send_packet() .. :) ).
В Oracle може да е различно, слушал съм за весели неща като вкарване на word документи и fulltext search в тях…
September 6th, 2009 at 12:45
Хаха, стигнало се е, че и по-далече, например:
DECLARE
c utl_tcp.connection; — TCP/IP connection to the Web server
ret_val pls_integer;
BEGIN
c := utl_tcp.open_connection(remote_host => `www.acme.com’,
remote_port => 80,
charset => ‘US7ASCII’); — open connection
ret_val := utl_tcp.write_line(c, `GET / HTTP/1.0′); — send HTTP request
ret_val := utl_tcp.write_line(c);
BEGIN
LOOP
dbms_output.put_line(utl_tcp.get_line(c, TRUE)); — read result
END LOOP;
EXCEPTION
WHEN utl_tcp.end_of_input THEN
NULL; — end of input
END;
utl_tcp.close_connection(c);
END;
от официалната документация на Oracle:
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10802/u_tcp.htm
Иначе, определено има какво да се подобрява в Postgres при работата с LOBs, ама пусто време, не стига и за бира вече…
September 6th, 2009 at 12:51
Еееее, ако ще си говорим за извращения, аз па съм писал нещо, което от postgresql trigger да вади данни от mysql (по-точно размера на базата на потребителя) :) Въпроса не е какво може (както например червото има програмче, което предава данни бит по бит през няколко семафора), а как би трябвало да се направи :)
September 6th, 2009 at 18:39
Хмм на така поставения въпрос… мм щом базата не го поддържа сменете базата :)
Аз съм съгласен че картинки за веб най-вероятно е много по-добре да се слагат на фс-ката. Но за някаква смислена система … хмм удвоява се администрирането, поддържаш база + сторидж, поддържаш фс+сторидж
архивиране отново *2 и за да е по-хубаво по два различни начина. И освен това проблеми от сорта на какво прави базата когато нещо не е наред с фс-ката. и дали пък някой не е решил да подмени някой друг файл с по-добра версия (за базата най вероятно се прави одитиране, в твоя случай ще трябва да се прави и за фс-ката)
Оставам си на мнението че ако е възможно всичко да е вътре в базата е по-добре :)
September 8th, 2009 at 02:02
:> И идва красивия ден когато така наречения безумен “програмист” решава да ползва слвдваща версия на postgresql за да си улесни живота и тогава ми е интерено как точно и за колко време ще стане dump/restore на база с пълна с глупости вътре и колко псувня ще отнесе.
September 8th, 2009 at 08:03
@mutant, рекорда до тука мисля, че е 26 часа dump (точно заради ебектите) – огромно количество картинки, всяка от тях в няколко размера за три вида thumbnail-и + оригиналния размер…