Да вы правы, это может быть дополнительной дырой в системе, но ее ведь можно закрыть как на уровне ОС (MySQL сервер выполянется под непривелигированым пользователем) так и средствами MySQL — забрать у пользователя привилегию Execute.
Если допускать возможность SQL инъекции, то хранить данные в БД тоже очень небезопасно выходит… Инъекция может прибить данные в таблице (связь имен файлов с статьями например) и тогда хоть файлы и будут нетронутыми, они будут бесполезные, так как удалены данные, с которыми они связаны.
Это как раз и есть «способ 2».
«к тому же у нас в проекте записи на удаление отбираются достаточно сложным SELECT, которые нельзя переделать в один UPDATE»
Вы не совсем поняли идею — файлами управляет MySQL — создает, удаляет, переименовывует и т.д., а пишем и читаем мы их просто через файловую систему, без всяких MySQL, сокетов и блобов…
Если у вас больше 1-го пользователя интернета — желательно поставить шейпер трафика — чтобы он между пользователями делился «честно», и исключить ситуацию, когда один пользователь забил весь канал своим торрент-трафиком и у других даже аська не коннектится :-)
сделать это можно например с помощью HTB в Linux, подробнее — как нибудь надо статью написать, как это дело настраивать.
Меньшее зло, но почему бы не объеденить преимущества обоих подходов? Файлы и как бы в БД и при этом лежат просто на ФС. Осталось самая малость — написать storage engine для MySQL :-)
Обычно в БД хранят не картинки интерфейса, которые дергаются один раз и остаются в кеше, а скажем фотография к новости (пользователь посмотрел новость и ушел дальше к следующей), архивы, фильмы (скачал один раз и все). Тоесть кешированием тут не решишь проблему производительности.
Именно так сейчас и сделано в нашем проекте, но хотелось бы сделать более прозрачный и удобный механизм хранения файлов, так как задача очень распространенная, и для каждого хранилища писать сборщики мусора как то не очень хочется.
Почитайте презентацию SQL Antipatterns, там более подробно расписано и даже нарисовано про проблемы храниения файлов отдельно от БД.
А по поводу хранения файлов в БД — абсолютно согласен с вами, это огромный удар по производительности. И цель этого поста была — именно рассмотреть способы устранения недостатоков хранения файлов «отдельнно» и проблем с производительностью при хранении «в БД».
для резервного копирования на домешнем сервере использую StoreBackup
как 2 года назад настроил, так все и работает, хотя винт с системой всего 40 GB
именно эа программа понравилась тем, что делает инкрементальные бекапы.
резервное копирование у меня выполняется каждый день, но в бекапе те файлы, которые не менялись за день заменяются ссылками на тот же файл из полного бекапа, а измененные — ложатся сжатые gzip'ом. таким образом все эти бекапы занимают очень мало места, и вы можете позволить себе делать их чаще.
В десктопе — легко!
Если кто-нибудь напишет программу для десктопа, позволяющую удобно загружать видео (а в идеале — еще и конвертировать его для более быстрой загрузки, если кто-то решит закачать видео 640х480 MJPEG из фотоаппарата например) — ему можно будет памятник ставить :-)
Интересная разработка! Только для реального использования нужна хорошая документация, желательно получше чем на Smotri.com :-)
Захостить на Google Code например, ну и наверное перенести пост в блог Java.
я бы попробовал пересобрать php, возможно собран со старой версией библиотек mysql
понаблюдал бы как ведет себя mysql в момент таких глюков и вообще сервер БД и на котором крутится PHP (muninx, nagios и тд)
попробовать в момент глюков подключаться из php используя простой тестовый скрипт с mysql_connect
с mysql уже столько было загадочных глюков, что поверишь и в влияние фаз луны и во что угодно (хотя всему потом находилось рациональное объяснение).
web20.a.ua/ (радио на главной в синем «портлете»)
или тут web20.a.ua/portlet-radio/popup.html?autoplay=1&playlist_url=/portlet-radio/playlist.xspf&track_index=0
обычный Flash-mp3 плеер, немного доточеный для воспроизведения радио (http://musicplayer.sourceforge.net/)
Интересный концепт, при чем воплотить его в жизнь в принципе можно своими руками — развинтить обычный роутер и платку запрятать в какую нибудь объемную вазу для для цветов, вставив в нее еще одну, поменьше, в которую налить воду. Инетерсный мод выйдет
«к тому же у нас в проекте записи на удаление отбираются достаточно сложным SELECT, которые нельзя переделать в один UPDATE»
сделать это можно например с помощью HTB в Linux, подробнее — как нибудь надо статью написать, как это дело настраивать.
А по поводу хранения файлов в БД — абсолютно согласен с вами, это огромный удар по производительности. И цель этого поста была — именно рассмотреть способы устранения недостатоков хранения файлов «отдельнно» и проблем с производительностью при хранении «в БД».
как 2 года назад настроил, так все и работает, хотя винт с системой всего 40 GB
именно эа программа понравилась тем, что делает инкрементальные бекапы.
резервное копирование у меня выполняется каждый день, но в бекапе те файлы, которые не менялись за день заменяются ссылками на тот же файл из полного бекапа, а измененные — ложатся сжатые gzip'ом. таким образом все эти бекапы занимают очень мало места, и вы можете позволить себе делать их чаще.
Если кто-нибудь напишет программу для десктопа, позволяющую удобно загружать видео (а в идеале — еще и конвертировать его для более быстрой загрузки, если кто-то решит закачать видео 640х480 MJPEG из фотоаппарата например) — ему можно будет памятник ставить :-)
Захостить на Google Code например, ну и наверное перенести пост в блог Java.
понаблюдал бы как ведет себя mysql в момент таких глюков и вообще сервер БД и на котором крутится PHP (muninx, nagios и тд)
попробовать в момент глюков подключаться из php используя простой тестовый скрипт с mysql_connect
с mysql уже столько было загадочных глюков, что поверишь и в влияние фаз луны и во что угодно (хотя всему потом находилось рациональное объяснение).
или тут web20.a.ua/portlet-radio/popup.html?autoplay=1&playlist_url=/portlet-radio/playlist.xspf&track_index=0
обычный Flash-mp3 плеер, немного доточеный для воспроизведения радио (http://musicplayer.sourceforge.net/)