Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #1 (permalink)  
Старый 05.07.2018, 22:26
Аватар для xShift
Профессор
Отправить личное сообщение для xShift Посмотреть профиль Найти все сообщения от xShift
 
Регистрация: 22.11.2016
Сообщений: 192

Реализация кэша БД
Собсно, вопрос про кэш БД на PHP.

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

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

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

Есть ли у MySQL такая фича?
Ответить с цитированием
  #2 (permalink)  
Старый 05.07.2018, 23:01
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 9,481

Нет такого, есть триггеры, используйте.
Ответить с цитированием
  #3 (permalink)  
Старый 06.07.2018, 16:35
Аватар для xShift
Профессор
Отправить личное сообщение для xShift Посмотреть профиль Найти все сообщения от xShift
 
Регистрация: 22.11.2016
Сообщений: 192

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

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


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


Цитата:
CHECKSUM TABLE tbl_name [, tbl_name] ... [QUICK | EXTENDED]
https://dev.mysql.com/doc/refman/5.7...sum-table.html

Последний раз редактировалось xShift, 06.07.2018 в 16:58.
Ответить с цитированием
  #4 (permalink)  
Старый 06.07.2018, 16:59
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 9,481

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

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

Вряд ли есть необходимость следить за всей базой (решение проблем с потерями данных возлагается на резервное копирование), но бывает необходимость слежения за изменением определенных данных в таблицах и для этого служат триггеры.
Ответить с цитированием
  #5 (permalink)  
Старый 06.07.2018, 17:09
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 9,481

xShift,
вы путаете понятия "кеш", "хеш" и "контрольная сумма". Даже в последнем случае, это вопрос администрирования баз, и таковое делают по расписанию, иначе ... то, что выше написано.
Ответить с цитированием
  #6 (permalink)  
Старый 06.07.2018, 17:16
Аватар для xShift
Профессор
Отправить личное сообщение для xShift Посмотреть профиль Найти все сообщения от xShift
 
Регистрация: 22.11.2016
Сообщений: 192

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

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

p.s.: жалко что хостинг в SCHEMA не пускает из-за того, что это корневая фича(каждая БД разделена на аккаунты без этих привилегий - там есть эта срань).
Ответить с цитированием
  #7 (permalink)  
Старый 06.07.2018, 18:04
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 9,481

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

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

А в контексте кеширования сопутствующих вопросов куча, которые придется решать. Но коли база, это нечто простое, то хозяин барин.
Ответить с цитированием
  #8 (permalink)  
Старый 06.07.2018, 20:54
Аватар для xShift
Профессор
Отправить личное сообщение для xShift Посмотреть профиль Найти все сообщения от xShift
 
Регистрация: 22.11.2016
Сообщений: 192

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-идиотов.

Последний раз редактировалось xShift, 06.07.2018 в 20:56.
Ответить с цитированием
  #9 (permalink)  
Старый 06.07.2018, 21:38
Профессор
Отправить личное сообщение для laimas Посмотреть профиль Найти все сообщения от laimas
 
Регистрация: 14.01.2015
Сообщений: 9,481

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

А если говорить об истинном кешировании SQL запросов, то кто вам мешает почитать, ведь об этом написано предостаточно, например, или, и т.д., в общем Гугл в помощь.
Ответить с цитированием
  #10 (permalink)  
Старый 07.07.2018, 00:13
Аватар для xShift
Профессор
Отправить личное сообщение для xShift Посмотреть профиль Найти все сообщения от xShift
 
Регистрация: 22.11.2016
Сообщений: 192

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

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

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

Цитата:
$SQL = 'CHECKSUM TABLE `'. self::$sql_hash_table .'`;';
выполняется, если предыдущее выставило флаг

Цитата:
$SQL = 'INSERT INTO `revolver__hash` (`field_id`, `field_'. explode('__', self::$sql_hash_table)[1] .'`) VALUES (\'1\', \''. self::$sql_actual_hash .'\')
ON DUPLICATE KEY UPDATE `field_id`=\'1\', `field_'. explode('__', self::$sql_hash_table)[1] .'`=\''. self::$sql_actual_hash .'\';';
дальше таблица пишется в файл полностью и к ней лепится метка self::$sql_actual_hash.

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

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

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

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

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

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

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

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

Последний раз редактировалось xShift, 07.07.2018 в 00:16.
Ответить с цитированием
Ответ



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
функция работает только один раз после очистки кэша. помогите пожалуйста silverva Общие вопросы Javascript 0 22.02.2017 13:33
JS загружает изображение всегда с локального кэша - почему? buhpro Общие вопросы Javascript 4 02.10.2013 21:01
Простой вопрос - как запросить страницу НЕ ИЗ кэша kefi AJAX и COMET 1 20.09.2010 15:26
Реализация "Удалить"..."Восстановить" как вконтакте.ру Darooma2 AJAX и COMET 10 26.05.2010 13:41
Как убрать загрузку картинки из кэша? chuser Общие вопросы Javascript 2 31.03.2010 17:19