https://opennet.me/openforum/vsluhforumID3/43624.html "Firebird is faster than filesystem for blob storage! (http://codicesoftware.blogspot.com/2008/09/firebird-is-faster-than-filesystem-for.html)" - тестирование производительности показало, что хранить бинарные файлы в СУБД Firebird эффективнее, чем в файловой системе Windows. В ходе эксперимента было организовано копирование 3659 файлов общим объемом 343Мб, размещенным в 468 директориях. В Firebird данные были обработаны на 27669 ms, а в файловой системе за 40378 ms.<br><br>URL: http://codicesoftware.blogspot.com/2008/09/firebird-is-faster-than-filesystem-for.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=17674<br> https://opennet.me/openforum/vsluhforumID3/43624.html#10 Tue, 16 Sep 2008 13:23:08 GMT помнится, они обещали на Longhorn новую FS на базе MSSQL движка :) че-то пропал энтузиазм, зря наверное. Хуже все равно бы не было<br> https://opennet.me/openforum/vsluhforumID3/43624.html#8 Wed, 03 Sep 2008 02:42:53 GMT &gt;Так получается же, что firebird работает поверх все той же ФС.. Только <br>&gt;вся запись идет в один большой файл <br><br>Дык у NTFS и FAT как раз с этим все плохо, вот и получается такой парадокс.Это не заслуга БД, это дерьмовость ФС :)<br> https://opennet.me/openforum/vsluhforumID3/43624.html#7 Tue, 02 Sep 2008 15:33:40 GMT Так получается же, что firebird работает поверх все той же ФС.. Только вся запись идет в один большой файл<br> https://opennet.me/openforum/vsluhforumID3/43624.html#6 Tue, 02 Sep 2008 14:05:19 GMT &gt; В ходе эксперимента было организовано копирование <br>&gt; 3659 файлов общим объемом 343Мб, размещенным в 468 директориях. <br><br>Да, на куче небольших файлов (средний размер файла тут получается всего 100Кб) и разлапистой структуре директорий NTFS cливает с треском.<br><br>Только вот "ваше присутствие здесь - не ваша заслуга а наша недоработка" (с) ФЭД.То есть, <br>это не заслуга firebird, а недостаток NTFS :).Если на него сложить в диру в корне диска этак 30 000 файлов - потом систему будет жестоко клинить на добрый десяток минут при почти любых операциях с ФС где кто либо натыкается на эту диру.Даже фdd\remove programs будет открываться минут по 15 потом...<br><br>Вывол: понты, при том довольно дешевые.Обогнать тормозную файловую систему плохо подходящую под задачу любой дурак сможет.Более того - Maemo Mapper например юзает GDBM базу чтобы на карточках памяти с их дефективным FAT32 не складывать тысячи файлов.База и быстрее и slack из-за кластеризации отсутствует.Но все это в основном актуально для старых и дефективных фай https://opennet.me/openforum/vsluhforumID3/43624.html#5 Tue, 02 Sep 2008 13:45:16 GMT Даже не знаю, фрагментации в базе данных не бывает в принципе? Как насчет чтения/записи с реальными фрагментированными данными?<br> https://opennet.me/openforum/vsluhforumID3/43624.html#4 Tue, 02 Sep 2008 11:21:37 GMT &gt;Они бы еще с dos'ом с fat16 сравнивали. <br><br>А еще лучше с совсем древним fat12, если кто помнит такой xD<br>В целом верно в том смысле, что файловую систему совсем неплохо было бы указывать, а если ntfs то еще и ее настройки кое-какие (вроде тайм-стампа или как там оно называется, в куче виндовых твикалок есть возможность отключения этой фигни; а также насчет компрессии).<br> https://opennet.me/openforum/vsluhforumID3/43624.html#3 Tue, 02 Sep 2008 11:01:36 GMT Падение СУБД происходит ещё более эффективно. :-)<br> https://opennet.me/openforum/vsluhforumID3/43624.html#2 Tue, 02 Sep 2008 10:41:54 GMT ФС-то какая? Как можно писать такое, не указав ФС?<br><br>Правда, в случае с Windows это и не важно, но нормальные люди его уже ни с чем не сравнивают, ибо сложно найти, чему он не сольет.<br> https://opennet.me/openforum/vsluhforumID3/43624.html#1 Tue, 02 Sep 2008 10:07:22 GMT Они бы еще с dos'ом с fat16 сравнивали.<br>