Тогда извиняюсь. С 2015 года занимаюсь программированием только для своих сервисов и так уже сильно не слежу за изменениями.
Читал недавно статью, где автор рассуждает о не сильной популярности пхв в молодых программистов (на первые места вышли джаваскрипт, пайтон и т.д.). Хотя конечно по статистике 43% работаю на вордпресс, который написан на пхп. + пхп на каждом шаред хостинге, а node.js, python не часто встречается.
"Для PHP он видит другой путь – что-то вроде ребрендинга и переименование следующей версии PHP в HypeScript. Это будет воспринято как нечто новое, и люди снова обратят внимание на этот язык программирования. Кроме того, по мнению специалиста, так появится возможность отказаться от более старых фрагментов PHP или добавить более строгие правила, например сделать типы обязательными для улучшения качества и производительности."
Нужно быть совсем дебилом, чтобы судиться с говнохостингом из-за копеек.
А какой они закон выполняют? И почему этот закон не выполняют другие хостинги?
Так давно уже было понятно, что будут просить на выход. А они как маленькие начинают удивляться такому. Пора бы уже привыкнуть.
К стране применяется, а не к национальности. Они действуют согласно их законов. Можете попробовать оспорить в суде.
Ну вообще-то статья на хабре https://habr.com/ru/companies/wunderfund/articles/685894/ )
Это в мемкешед ключ - значение.
Вот какие типы данных поддерживает Redis:
Строка (String)
Битовый массив (Bitmap)
Битовое поле (Bitfield)
Хеш-таблица (Hash)
Список (List)
Множество (Set)
Упорядоченное множество (Sorted set)
Геопространственные данные (Geospatial)
Структура HyperLogLog (HyperLogLog)
Поток (Stream)
Не думаю, запросы все равно обрабатывать надо, а с кешированием уже открытых страниц, все ок.
Так там же можно и запросы в бд кэшировать (те что на чтение; те что на запись уже обычным способом), + он же еще и на диск периодически сбрасывает
Но во многих случаях Redis гарантирует достаточно высокий уровень сохранности данных, что позволяет использовать эту СУБД в роли настоящей основной базы данных. А добавление в систему плагинов Redis и различных конфигураций высокой доступности (High Availability, HA) делает базу данных Redis крайне интересной для определённых сценариев использования и рабочих нагрузок.
И вот я возвращаюсь к идеи полностью переместить ее в оперативку. Просто как правильно и сколько можно вырезать из условных 64 гб, когда база весит 10 гб + запас который нужен для работы самого мускул, кеш и прочее. Отсюда думать, как быстро написать скрипты, которые будут быстро копировать нужные конфиги, пути, файлы, чтобы быстро развернуть после возможного отключения сервера, что опять по аптайму показывает возможно и не понадобится.
А Redis не подходит для этого?
Просто такая реализация - это когда сам занимаешься проектом. А так должна быть защита от дурака.
Это же меню нужно связать со страницами. Для страницы обычно должны определяться подключаемые модули. Есть вероятность рассинхронизации страниц и меню.
По любому нужно связывать меню со страницами даже если это на файлах организовано (или писать админку или руками править файл). В меню должен быть или ID страницы (но это снова обращение в базу чтобы узнать урл страницы) или прописывать сразу полный урл (но в таком случае при его смене в базе можно получить 404).
Поэтому там разные варианты могут быть в зависимости от проекта и кто его будет вести.
Как вариант все в 1 таблице (меню и страницы), при ее изменении делать экспорт в файл (тот же джосн) и быть уверенным, что работаешь с актуальными данными. и т.д.
Но контент обычно периодически добавляется.
Все равно, мое мнение, если есть возможно и это рационально, то нужно по возможности меньше делать запросов к базе данных. Мне было удобнее сделать мультиязычность интерфейса на хранении этого текста в файлах (пхп массивы).
На сервере всё хранится в файлах на диске или в оперативной памяти. В том числе и БД. Но БД специально оптимизирована именно для работы с данными. Поэтому где "быстрее" - большой вопрос. Зависит от структуры данных и их объёма.
Вы хотите сказать что обращение к базе данных будет быстрее, чем считать файл? (не учитывая использования опкэш и мемкэш)
Здесь же речь шла о словах из интерфейса, а не контента. Контент в базе хранится. А зачем мне для текста из интерфейса (при мультиязычности) хранить его в базе данных, если это изредка только меняется? Подключил файл с нужным языком и сразу используй (json или просто обычный массив в php файле).
