Добрый день. Интересует такой вопрос...
Где выгодней хранить конфигурационные параметры с точки зрения производительности: в файле или в MySQL? Идет речь об обычных конфигах, к примеру, каких-либо CMS. Откуда информация будет быстрее извлекаться, если рассмотреть вариант некоторого числа одновременных обращений? Скажем, при 50 одновременных обращений что будет быстрее? 
С точки зрения удобства - конечно MySQL...

БД + умное кеширование, которое занет когда конфиг поменяли.

Это сообщение отредактировал(а) Daevaorn - 1.6.2008, 16:23

Немного утрировано но... Где вы храните конфигурационные параметры для БД. У вас наверняка есть файл где они хранятся. Почему бы его не использовать и для всех основных(тоесть которые применяются всегда) настроек раз он все равно подключается.

Очередной нуб, озаботившийся вопросами производительности. 
Которому объяснять бессмысленность его вопросов бесполезно

Ты грубо ошибаешься. Перед тем как делать выводы о человеке, сначала получше узнай его.
Да, и, количество сообщений равное 4-м ни о чем не говорит.
В ответ могу только улыбнуться 

Ну расскажи мне, неправильно судимый по четырем сообщениям, какие ещё критерии ты рассматривал, кроме производительности, и "удобства"?

Не имею желания продолжать с тобой дискуссию. Ты делаешь слишком поспешные выводы и относишься с долей предвзятости. Во всем что я буду далее говорить, с твоей стороны будут попытки найти какие-либо минусы. Я заведомо не буду тратить время на доказывание чего-либо 
Для остальных: вопрос остается актуальным. Куда обращения происходят быстрее, при одинаковом объеме извлекаемых данных: к файлам или к бд?

Это сообщение отредактировал(а) Brabus2008 - 1.6.2008, 16:21

Правильно. Буду находить минусы. 
Вы, почему-то, этого страшно боитесь. Как будто учитель в школе оценки ставит. 
Куда приятнее узнать об этих минусах не от постороннего человека, а на рабочем проекте, правда?
Я с легкостью могу доказать, что ни твой личный уровень, ни уровень твоего проекта, не требуют столь тонкого тюнинга производительности, а вопрос высосан из пальца. 
И эта твоя боязнь критики, боязнь "минусов" говорит о тебе гораздо больше, чем 4 поста в форуме.

Ну почему же. Опять поспешные выводы. Я люблю сам находить минусы, и когда их находят. Это полезно. Но полезно в том случае, когда находка обоснована, а не сделана на основе каких-то догадок, ничем не подтвержденных. У меня нет повода тебя слушать, т.к. информация бесполезна.

"Я с легкостью могу доказать": ну доказывай  От этого ни тебе ни мне не будет толку. Я в состоянии оценивать свои уровни и что для них требуется.
Вообще, чего мы тут пытаемся добиться? Ты и я тратим время - самое дорогое в жизни - на какую-то чушь.

Ты с самого начала начал тратить время - об этом я и говорил, тоже с самого начала.
Ты не имеешь ни малейшего представления о проектах, которые требуют 50 одновременных обращений. Для доказательства этого я просто хотел спросить, сколько при этом будет показывать посетителей на сайте.
Но суть-то не в этом.
Суть в том, что профессионалы не задают вопросов на форуме. 
А если задают - то не так. 
А задав - не так реагируют на ответы, сознавая свой уровень в задаваемом вопросе
Вот сам я задаю очень редко. Поскольку действительно выполняю все требования, которые описаны в известном документе. Не потому, что они там описаны, а потому, что понимаю - только выполнив их, я могу рассчитывать на ответ. И, разумеется, ответ получаю в процессе =)

Не будучи же профессионалом, ты не понимаешь, про что спрашивать. Для того, чтобы формат конфига стал бутылочным горлышком приложения, должно сложиться совершенно невозможное сочетание факторов. И для этого надо вылизать кучу других мест - реально требующих оптимизации. К примеру, решить, использовать ли при выдаче страниц базу данных вообще. Такого уровня вопрос я бы понял.
А твой взят с потолка, не имея ни малейшего отношения к реальности.
Вопрос производительности, действительно - большой и сложный. С одной стороны, мы имеем людей, которые о ней вообще не заботятся - и получают тормоза при сотне посетителей в сутки. С другой - тех, кого она заботит, но без действительного понимания. И начинается - "как лучше хранить настройки в файле - в виде пхп кода или  сериализованного массива? Ведь в случае сериалайза тратися время на парсинг!". Убейте меня три раза. Парсинг. Пхп каждый раз при запуске твоего скрипта парсит посимвольно его весь. Об этом не знает никто. Но пропарсить килобайт настроек - это поражает воображение. 
"Откуда лучше доставать - из базы или из фалйа?". Вопрос с головой выдает человека, который не представляет себе, что у запроса к БД проблема - выполнить его, а не получить результат. Вот о чем надо заботиться - чтобы запросы выполнялись быстро. А не о том, как получить три строчки настроек.

От доказательства вполне может быть польза. Возможно, ты перестанешь забивать себе голову бессмысленными вопросами, и займешься чем-то действительно важным.

Твоя точка зрения понятна  Хранение конфигов - предлог. Суть вопроса в том, куда обращения происходят быстрее. Мы здесь НЕ обсуждаем, нужен ли именно в этом месте данный выбор, или нет. Я просто спросил: "Куда быстрее"?

Это сообщение отредактировал(а) Brabus2008 - 1.6.2008, 19:24

Feldmarschall, что вы пристали к человеку? Нечего ответить по теме? Тогда расслабьтесь. Чего пустую болтовню разводить.

Brabus2008, при всей резкости Фельдмаршала, вам стоит прислушаться к его мнению.
А абстрактный вопрос, "куда обращения происходят быстрее" еще более бессмысленный, чем вопрос про конфиг.
Запросы они разные.
А если очень интересно для конкретного случая - проверьте. Это намного быстрее чем тут ругаться.

хехе. зависит от полторы сотен различных факторов.
удаленный файл и серверная СУБД локально? файловая БД и локальный файл? запрос на выборку с сортировкой или выбор из файла с последующей сортировкой на уровне программы? какие данные? какой размер? какая структура? фиксированной длины записи или нет? какой  механизм подключения к БД? какая ФС? 
продолжить?
Сначала ты ставил вопросы касательно вызывающей удивление цели.
теперь ты ставишь обобщенные вопросы и ожидаешь ответы.
так?

помню, самого не так уж и давно заботила проблема двойных/одинарных кавычек... 

Касаемо вопроса: суть понятна, несколько глупо, всем спасибо.
Касаемо поспешных выводов: определенно не правильная позиция.

Brabus2008 а какого типа параметры вы хотите хранит как конфигурационные?

krundetz, всяческие параметры системы, статус какого-либо функционала (вкл/выкл), адреса директорий и пр. В общем строки.
Самое глупое то, что изначально я в курсе, что брать эти параметры быстрее с файла, по сраневнию с запросом к бд. (будем иметь вду, что файл и сервер бд на локалхосте, выборка без всяких сортировок и группирований). Но разница между ними мизерная, если сравнивать "по одному". А когда в цикле 1000 одинаковых запросов туда и туда, файлы выигрывают почти вдвое. Но меня интересует ОДНОВРЕМЕННЫЕ обращения, которые я смоделировать точно не могу  На самом деле логично и далее предположить, что к файлам быстрее... Но насколько эти значения будут расходится и стоит ли идти у них на поводу.

Это сообщение отредактировал(а) Brabus2008 - 1.6.2008, 20:27

правильно.

правильно.

Однако ни один веб-сайт не отказывается от использования БД.
Теперь осталось сложить два и два, и сделать таки вывод, о котором я говорил с самого начала - видимо, скорость, быстродействие и производительность - не единственные факторы, по которым выбирается та или иная технология.
Вот пример: мы хотим хранить данные в БД. А зачем? Это реляционная информация? Мы будем сортировать эти данные? Связывать с ними какие-то другие? Запрашивать по отдельности? Если нет - то зачем нам БД вообще? Зачем использовать инструмент не по назначению? Почему такой очевидный критерий не рассматривается? 
Ну ладно - храним в БД. А как? Это будет эмуляция файла (все одним куском) или по строке на параметр? 
Этот вопрос интересен, поскольку тесно связан с вопросом "удобства", которое сводится, как я думаю, к количеству кода. 
$config=unserialize($file_get_contents(conf.txt)); - это неудобно?
Если в БД одним куском, то какая разница с 
$config=db->get_one(unserialize($file_get_contents(conf.txt));
?

Ну, в данный момент я повсеместно использую хранение в файле ini. Брать легко: parse_ini_file . А вот с записью мне не очень нравится. Нужно вышеуказанной функцией пропарсить файл, найти в массиве нужное значение, изменить его, и опять массив записать в нужном формате в файл. Куда удобней обновить одну запись в бд. Грубо говоря, во мне борятся два мнения: удобство (бд) или скорость (файл) 

Где э тут неудобство, если у тебя код уже написан?
И в том, и в другом случае все сводится к вызову одной функции. 

Удобство БД не в способе записи в неё данных, а в легкости манипулирования ими!

к сказанному Feldmarschall, хочу добавить ещё одно замечание. архитектурное.
обычно, все настройки настройки системы представляют собой многомерный массив(дерево или даже граф - в зависимости от ситуции): как минимум, "разделы" конфигурации(подключение к БД, язык интерфейса, режим работы.... да мало ли ещё!) и собственно параметры конфигурации(имя пользователя БД, имя каталога с картинками, и т.д. и т.п.), а БД у нас в основном используются реляционные. И получается, что для формаирования набора настроек из двумерного массива, хранящегося в БД, приходится делать дополнительную обработку. В то время, как при хранении в PHP-файле в виде массива достаточно просто сделать include. Да, с точки зрения скорости выполнения разницы большой не будет(один запрос к БД или одноразовая обработка включаемого скрипта), но в случае с файлом всю "грязную" работу делает PHP. Так зачем усложнять код и открывать дополнительный простор для совершения ошибок?  

Мм, верное замечание, спасибо.

как вам это по удобству.

Я что то не понимаю вас. Конфигурация это то что у нас должно подгрузиться в любом случае. В не зависимости от того чего это конфигурация всей системы или отдельного модуля. Какя здесь может быть вообще выборка. Пример. Есть система парсинга. Конфигурация в этом случае это адрес ресурса с которого парсим и адрес файла в с правилами парсинга. Все и то и другое необходимо. Если у нас есть какаята выборка по параметрам то это уже не конфигурация, а логика. Данные с которыми работает логика лучше хранить в БД.

На пример: есть страница админки, которая отвечает за конфигурирование какого-либо модуля. На ней было бы удобно выбирать (ну, в данном случае говорим о базе, потому) с базы только параметры, относящиеся к данному модулю. Вот и выборка. С другой стороны можно хранить конфиги в разных файлах для разных модулей, и эффект будет тот-же  Но не совсем централизовано будет, в отличие от варианта с бд.

ну, у тебя же картинки отдельно друг от друга лежат, так?   
да и модули - не все в одном-единственном файле...
вот когда однородная/однотипная информация начинает дробиться(на разные таблицы с одинаковой структурой... или на разные файлы) без веской причины, то это "не централизовано". а если информация разнотипная, ещё и по возможности - друг от друга не зависящая, то наоборот разделение - лучше. потому что делает части минимально зависящими друг от друга.

Добавлено через 1 минуту и 8 секунд
но это, опять же, разговор о "сферическом коне в вакууме", потому что все зависит от условий конкретной задачи: модели, ограничений на реализацию, требования к функционалу... в "общем виде" универсального решения нет.

Brabus2008 ИМХО странный както вы пример привели. Причем здесь админка? Скорость исполнения скриптов в админке не имеет существенного значения там важно совершенно другое(не будете же вы их менять каждую минуту). Да и скорость с которой будйт меняться конфигурационные параметры будет по определению больше чем скорость их чтения и не важно что это увас будет файл или БД.

Не стоит смешивать настройки системы в целом и настройки модулей. Разделение позволит вам упростить систему которая будет отвечать за включение нового модуля в систему и выключение ненужного из нее. Собственно говоря разделяете же вы саму систему на модули.

Это сообщение отредактировал(а) krundetz - 1.6.2008, 22:39

Как я уже сказал в своём вопросе http://forum.vingrad.ru/forum/topic-216786...y1550927/0.html , я сохраняю данные в xml-файле и вношу запись о нём в MySQL-базу.
Но это - для общего решения о сохранении заранее неизвестного количества неоднородных переменных некоего скрипта, одного из очень многих и имеющего такие ассоциативные признаки, как, к примеру, "username того, от чьего имени скрипт запущен", "время предыдущего запуска" и т.п.

В частных случаях IMHO надо действовать по ситуации: огромный массив однородных и не требующих выборки данных лучше просто записать в бинарник, разнородные переменные лучше хранить в xml-формате, а если требуется выборка, то никуда не деться от *SQL

В Вашем частном случае, как мне кажется, перспективнее всё-таки использовать базу, поскольку там не нужно заботиться об одновременных вызовах по чтению/записи, а случае с файлами в лучшем случае будут большие таймауты, а в худшем - собщения об ошибке "невозможно открыть файл" (занятый другим процессом)

Как вариант: XML.




Кэшируйте.

Файл конфигурации и спец. класс для парсинга и отдачи. Синглтоном.

Быстрее будет memcached (да, SixApart действительно во многих вещах облегчили жизнь веб-девелоперам, работающим с критичными нагрузками).
Но есть еще один момент - преждевременная оптимизация затрудняет дальнейшее развитие проекта. Кеширование - наипервейшая и чаще всего единственная необходимая вещь для оптимизации, но только после того, как понимаешь, что именно надо оптимизировать.

Добавлено через 3 минуты и 18 секунд
И, кстати, вариант типа $config = unserialize(file_get_contents('config.serialized.php')) будет по-быстрее, чем $config = array('blabla' => 'blabla', ......).