Где хранить данные, которые меняются раз в 3-6 месяцев?

Question

[Vitaly Vitaly]

Привет всем, есть данные, которые обновляются максимум в 3-6 месяца, а могут и не меняться целый год, к примеру названия типов данных

$types = [1 => 'Автомобили', 2 => 'Недвижимость', 3 => 'Путешествия'];

Раз через какое-то время при добавлении нового раздела сервиса возможно добавления нового типа.
Обращения к этим данных происходит часто, не хотелось бы хранить это в MySQL.
В проекте используется MySQL + Redis.
Есть мысль занести данные в Redis, может есть альтернатива? Кто где хранит такие данные?

Сейчас пока идет разработка, данные просто находятся массивом в контролере и передается во View.

Answer 1

[Alex Pts]

Хранить их в БД, но при этом кешировать. Чтобы за таким словарем не бегать в БД каждый раз.

Answer 2

[Максим Кудрявцев]

Если данные настолько "часто" меняются, тогда почему бы их не забить в отдельный PHP-словарь - просто файл, который содержит массив и инклудится туда, где он нужен.

Минус - да, надо будет каждый раз лезть и менять руками, но раз в квартал, я думаю можно.

Comments

[Алексей Murz Корепов]

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

Answer 3

[Александр Губарев]

Можете хранить в базе, а при изменении экспортировать в пхп массив.

Вот список способов хранения, по убыванию скорости. Сериализованные массивы самые быстрые, но php массивы может кешировать op cache.

Serialized arrays
Plain PHP code
INI files
XML files
YAML files

Comments

[Алексей Murz Корепов]

А подскажите пожалуйста что имеется в виду под "Serialized arrays" и " Plain PHP code".
Т.е. вот такой код:
<?php $myarray = unserialize("длинная сериализованная строка"); ?>
должен работать быстрее чем
<?php $myarray = array('a','b','c'); ?>
- так?

[Александр Губарев]

Алексей Murz Корепов: да, только в первом случае еще чтение файла, а во втором include php кода

[Александр Губарев]

Алексей Murz Корепов: вот такой функцией можно экспортировать из подготовленные данные из бд в php файл protected function saveToFile($data, $file)
{
file_put_contents($file,"<?php\nreturn ".var_export($data, true).";\n");
}

[Алексей Murz Корепов]

Александр: ну с отдельными файлами понятно, что быстрее прочитать файл с данными чем инклюдить и исполнять php-файл. Интересует как раз скорость работы если эти оба варианта прямо в коде написаны, ну и там не 3 элемента, а 100500 элементов.

[Александр Губарев]

Алексей Murz Корепов: вам уже дали решение на блюдечке, хотите 100500 элементов напишите свой бенчмарк

[Алексей Murz Корепов]

Александр: ну это понятно что мне можно самому написать бенчмарк и провереть, просто интересуюсь может у вас уже есть результаты, чтобы мне не изобретать велосипед. Попробую тогда сам выяснить, по результатам отпишусь тут.

Answer 4

[Viktor Vsk]

Эмм, ну явно не в редисе. Он должен хранить данные в оперативке, а реляционные базы - на диске. Кто в итоге больше подходит под хранение данных, которые изменяются редко ?
Именно в mysql и храните. Тем более, пока нет никаких ограничений. Почему вам "не хочется" их там хранить ?

Comments

[Vitaly Vitaly]

Странно, ну возьмите, что раз в секунду грузит 50 человек страницу, 50 * 60 = 3000 запросов в минуту, это не много, но я не вижу смысла давать mysql 3000 запросов в минуту за статичными данными. Как раз таки Redis держит данные в оперативной памяти для оперативного получения и облегчения жизни реляционной базы, в моем случае это mysql.

[Viktor Vsk]

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

[Vitaly Vitaly]

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

[Viktor Vsk]

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

Можно оставить их в мускуле и по нажатию кнопки выгружать в файл.

Если решите использовать оперативку, то если уже используется редис, ставить, например, мемкеш, просто так смысла очень мало.

В общем, опять же, все зависит от требований и ресурсов

[Viktor Vsk]

Vitaly Vitaly: Хранить в редисе? То есть, вы хотите следить еще за одной системой бэкапа, плюс, писать свою обертку для "админки" этих значений в редисе? Или будете их менять вручную ?

[Vitaly Vitaly]

Виктор Выскребенцев: ну по поводу слежения, это системного админа задача :)
А что сложного написать? Это же простой CRUD.

[Vitaly Vitaly]

Виктор Выскребенцев: их можно даже менять вручную, это такие данные, если они добавляются или изменяются - значит новый раздел разработан

[Viktor Vsk]

Vitaly Vitaly: вот я и говорю, завист от требований и ресурсов.
Уверены, что через 3-6 месяцев лично Вам захочется лезть и менять в консольку редиса эти данные?
А так, скорее всего, какую-то админку вы делаете для клиента. Куда удобнее (для себя) и универсальнее - дать ему возможность менять эти данные.

И с учетом того, что админка на мускуль будет, а на редис писать обертку только ради этих данных - это, опять же, плюс для хранения в мускуле.

Насчет админа тоже все верно. Однако, до тех пор, пока этим админом не станете вы сами :)

Если, например, вы вообще не делаете админку, то вернемся к первому утверждению: задача и ресурсы :)

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

Если допускаете ручное модерирование, то логичнее, как по мне для такого случая - синглтон-класс настроек

[Vitaly Vitaly]

Виктор Выскребенцев: Щас попробую разные варианты под нагрузкой посмотреть, что и как даст свой эффект. Обязательно отпишусь)

Answer 5

[Алексей Murz Корепов]

Предлагаю хранить эти данные также в базе, но кешировать их вывод прямо в PHP. Например при каждом изменении данных или по крону (например, раз в сутки) запускать скрипт, который будет делать выборку из базы и перегенерить файл types_data.inc.php или как serialized-массив.

Тем самым вы решите проблему администрирования списка (сортировка, фильтрация, добавление нового, изменение, переименование) раз в 3-6 месяцев, и при ежедневном запросе на чтение не будет каждый раз делаться запрос к БД.

Хотя не факт что файл будет быстрее - "горячий" кеш БД возможно в некоторых ситуациях будет быстрее, чем чтение файла с забитым под завязку другими файлами файловым кешем.

Comments

[Алексей Murz Корепов]

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