Реализация кэша БД
 

Собсно, вопрос про кэш БД на PHP.

Есть ли у MySQL какая-то команда, которая выплевывает текущий хэш состояния или какой-то слепок MD5?

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

То есть мне по факту нужен MD5 конкретной таблицы ...

Есть ли у MySQL такая фича?

Нет такого, есть триггеры, используйте.

laimas, хреново, придется сделать ... Я лет 5 назад смотрел на instance SHEMA, который есть у БД MySQL и у меня родилась вот такая идея, но потом почему то все не довел до конца.

Какие-то есть идеи как это можно использовать или как бы это можно было реализовать?

Ура. Я сделал нормальный кэш :)


https://dev.mysql.com/doc/refman/5.7...sum-table.html

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

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

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

xShift,
вы путаете понятия "кеш", "хеш" и "контрольная сумма". Даже в последнем случае, это вопрос администрирования баз, и таковое делают по расписанию, иначе ... то, что выше написано.

laimas, к словам придираетесь.

Мне надо было знать что кэш статика(тупо JSON) соответствует контенту в БД, а за триггер спасибо. Подцеплю на insert, delete и update триггер для добавления этой checksum в табличку хэш и перед выполнением select буду сравнивать хэш статики и хэш в таблице hash_tables. Это даст мне офигенный прирост скорости. Щас укладываюсь в 20 запросов на все что нужно. Будет 1 - станет отлично.

p.s.: жалко что хостинг в SCHEMA не пускает из-за того, что это корневая фича(каждая БД разделена на аккаунты без этих привилегий - там есть эта срань).

Ну почему придираюсь. )

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

А в контексте кеширования сопутствующих вопросов куча, которые придется решать. Но коли база, это нечто простое, то хозяин барин. ;)

laimas, будете ли вы, Сэр, напрягаться из-за одного запроса перед обработкой всех данных, который будет дефайнить массив в глобальную переменную с хэшами текущего состояния базы?

Чувствую предлагаете вы использовать низкоуровневые функции MySQL для построчной обработки всех ячеек и последующей конкатенации какого-то более простого cheksumm? Нет, медихлорианы мои подсказывают, что мсье бы и знал толк в извращениях, но не стал бы это делать.

~80% активности это просмотр, а значит select. Цифра не случайна и вытекает из того, что большинство запросов создается анонами, ботами.

Один запрос в инициализацию ядра и мы имеем статический кэш. Один чуть более нагруженный inset/update и delete и мы имеем обновление. Одна файловая операция записи на эти уточнения и все чики-пуки.

Насчет триггеров, кстати, какая то там построковая непонятная логика. Пока не проверил, но FOREACH ROWS меня смущает. Наверное даже от три тригера откажусь.

Собсно, сегодня обнаружил, что у меня get comments зациклился и получилось 57 запросов. Оптимизировал - стало 17. Разница выполнения смешная: 0,02 секунды против 0,2 сек.

Исходя из того, что у меня есть свой движок для БД на базе конкатенации запроса абстракций из структурного массива и есть хэлпер, который просто получает то, что нужно по GetData('any_shit') - я просто добавляю автоматику для получения и обновления кэша, добавляю туда же автоматику для сброса и получения статики и больше ни о чем не думаю.

Сосали все Doctryne и ORM потому, что тот же WP жрет 60 запросов без обвязки, а кэш у него говно. А эти DQL вообще нахер не нужны.

Когда Node.JS доживет до своей нормальной БД - я задумаюсь уходить с backend PHP. Нода щас хуже раз в 15, а PHP стает слегка асинхронным.

Вот такой беспонтовый опус про BigData-идиотов.

Если ваше кеширование, это "не изменилось, значит не тревожим", ваше право, но это не есть гибкость приложения. Данные в базе даже неизменяемые во времени совсем еще не означают, что запрос на выборку всегда одинаков. Чего вы там пытаетесь хранить и зачем, вам виднее.

А если говорить об истинном кешировании SQL запросов, то кто вам мешает почитать, ведь об этом написано предостаточно, например, или, и т.д., в общем Гугл в помощь.

laimas, тщательно протестировал.

Вот пример query для создания хэша:

выполняется при update, insert, delete и выставляет флаг для следующего

выполняется, если предыдущее выставило флаг

дальше таблица пишется в файл полностью и к ней лепится метка self::$sql_actual_hash.

Запускается процесс и первым делом выставляется define('cache_hashe', [hashes] );

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

Каждая нужная таблица - отдельный файл.

Таким образом не нужны никакие метки протухания и планировщики.

Весь класс пока выложить не могу - еще нужна обкатка.

Мемкэш мне не нужен - это зависимости модуля и как правило 'залипание'.
Кэш есть и у самой БД внутри - это я знаю.
Кэш шаблонизатора - это тоже фигня фактически, хотя смерти в свое время был шикарен.
Cron - не гарантирует моментальное обновление и подразумевает геморройный batch.

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

p.s.: уложился в 1 запрос для создания checksumm и в 2 запроса при обновлении(checksumm+action), а также для сайтов со статическим содержимым типа библиотек без комментирования и пользователей всего 1 запрос на отрисовку.