Нужно быть совсем дебилом, чтобы судиться с говнохостингом из-за копеек.
А какой они закон выполняют? И почему этот закон не выполняют другие хостинги?
Так давно уже было понятно, что будут просить на выход. А они как маленькие начинают удивляться такому. Пора бы уже привыкнуть.
К стране применяется, а не к национальности. Они действуют согласно их законов. Можете попробовать оспорить в суде.
Ну вообще-то статья на хабре 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 файле).
Вот именно, зачем их в базе хранить, если они не часто изменяются. Практики там наверное вообще 0 ))
Тогда зачем придумали БД по вашему? Хранили бы всё в файлах, зачем БД нужно тогда? 😆
А зачем все пихать в БД? Это одно из наиболее узких мест для производительности. И сколько таких запросов в бд в том же wp чтобы отобразить одну страницу. А еще же нужно плагинами обвешаться как новогодняя елка. Вот здесь точно для лендинга будет впс мало (без кэширования)
