Float-опции (плоские опции)

На днях нужно было решить одну проблему, но не знал с какого бока подойти. Требовался плагин, который позволяет выводить разные текстовые/php-блоки на сайте. Проблема здесь в том как именно хранить данные.

Для WordPress'а я делал плагин Ушки, который вполне возможно вы до сих пор успешно используете. Ушки хранят тексты в базе банных в своей таблице. В принципе такой подход меня может быть вполне и устроил, если бы не одно «но».

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

С другой стороны, нужные мне данные можно хранить как обычные опции.

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

Причем кэшируется и в памяти - за счет этого опции работают очень быстро.

Получается, что если я начну использовать опции для хранения своих данных, то они автоматом попадут в кэш. С этим можно было бы смириться, но иной раз требуется сохранить не маленькие данные, вроде «true» и «false», а что-то посерьезней, например текст страницы на десяток килобайт.

А такой размер уже сравним с размером всех опций. Получается замкнутый круг...

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

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

Но дело не в этом. Я подумал, что можно внедрить нечто подобное в MaxSite CMS, только еще проще. Вместо того, чтобы использовать базу данных, мы сохраним настройки в обычном файле. Причем данные могут сразу серилизоваться, что позволяет сохранять в них любые php-типы.

Таким образом я пришел функциям

• mso_add_float_option() - добавление float-опции
• mso_get_float_option() - получение float-опции
• mso_delete_float_option() - удаление float-опции

Их синтаксис совпадает с обычными mso_add_option(), mso_get_option() и mso_delete_option(), за исключением того, что можно указать свой каталог. По-умолчанию float-опции будут храниться в «uploads/_mso_float».

Получается довольно интересная штука с множеством плюсов.

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

Дабы усилить эффект приведу пример из WordPress'а.

Я когда-то об этом писал на своем блоге, и тут как раз вполне по теме получается.

В WordPress'е данные слепо хранятся в таблице опций. Но проблема с их получением возникла давно и разработчики придумали дополнительный параметр «autoload», который теоретически должен был быть указателем на то, какие опции следует автоматом получать, а какие нет.

Но сами по себе опции небольшие - в этом их суть, так почему же в кэше WordPress опции занимают такой большой размер: обычно от 500Кб (при полезных 30-60Кб)? А дело в том, что опции, так же как и у меня автоматом сохраняются в кэше целиком, не взирая ни на какие автолоады.

Ну а поскольку разработчики, как обычно, не утруждали себя подумать как следует над этой (и не только) проблемой, то в опциях сохранялся всякий хлам, вроде rss-лент, уведомлений об обновлениях и т.д., и т.п. И получилось, что этот бесполезный хлам в итоге занимает примерно 90% всех опций. Вот вам еще один источник прожорливости и тормознутости WordPress.