Если Вам лично что то не понятно или есть какие-то вопросы, которые Вы по каким-то причинам не хотите задавать в комментариях — можете написать мне личное сообщение.
реализация в коде осталась за рамками данной статьи. что же касается хранения данных, то посмотрите таблицу tags — по структуре там видно как хранятся деревья, хранение синонимов в таблице tags_names.
Наверно стоило оговориться, что под синонимом в нашей системе подразумевается синоним на естественном языке, то есть одна сущность тэга может содержать несколько синонимов, а не так что несколько разных сущностей тэгов объявляются синонимами и для них назначается главный. сущность одна, значений много.
Sphinx посмотрите.
В базе будете первичные данные хранить без каких либо накладных индексов, а искать сфинксом — сказка.
Поиск по двум индексам и мердж этих индексов по ночам даст возможность риал-тайм индексации.
Привет, Артемий. Все что будет сказано в этом комментарии имеет отношение исключительно к нагруженным проектам.
К сожалению, в своих статьях о кэшировании ты рассуждаешь как теоретик — сразу видно отсутствие практического применения. Теперь по пунктам:
Что нужно кэшировать
кэшировать нужно абсолютно всё. В твоём примере данные извлекаются за 0.1 секунды, а из кэша отдаются за 0.2. Проблема в том что тест синтетический — на нагруженном проекте данные будут извлекаться за 0.9, а из кэша по прежнему отдаваться за 0.2, разумеется это зависит от того какие именно данные и куда производится кэширование, будем считать, что мы правильно определили куда кэшировать эти конкретные данные, и даже при этом тайминги будут различаться примерно так. Суть в том, что в твоей теории ты забываешь об окружении, а окружение — это уже практика.
Куда нужно кэшировать
Память — это очень правильно. Для кэширования объектов. Тут нет замечаний.
кэширование в файловую систему.
Во-первых, смотрим сюда en.wikipedia.org/wiki/Ext2 — ты говоришь о лимите файлов — теоретический лимит там указан как 1.3 умножить на 10 в 20 степени. число 32768 — это максимальное количество директорий внутри директории, но не файлов.
Так или иначе если в генерации страницы участвует 100-300 объектов (каждый из которых закэширован в файловую систему в виде отдельного файла) на нагруженном сервере эта генерация займет значительно больше времени чем вычитывание этих объектов из памяти — почему больше написано чуть ниже про файловые бд.
Файловые базы данных — TDB, SQLite, DB4
На действительно нагруженных проектах сервера выполняют невероятное количество операций с диском, особенно если часть статики крутится на одном сервере с пхп. И любое обращение к памяти «под нагрузкой» будет в «сто раз» быстрее чем обращение к диску, так как диск постоянно занят. Но попробуем пренебречь этими фактами и допустить что на самом деле данные меняются один раз в сутки, после изменения данных мы генерируем кэш и работаем только с ним оставшиеся 23 с копейками часа — это как раз теория. На практике нет — данные меняются очень часто. Поэтому кэширование в файлы будет работать лишь очень короткое время, затем вся польза такого кэширования будет сведена на нет.
О твоем развернутом примере.
Во-первых — 50 000 статей это мелочь, это такая мелочь что не стоит и думать о времени извлечения одной статьи из базы. Думать стоит о построении коллекций, но даже об этом при правильной реализации хранения в базе думать не приходится — ведь хранить сам контент по которому не строятся коллекции в одной таблице с временем публикации глупо. Во-вторых, приведенная схема, основанная на времени изменения таблицы в базе мне очень знакома, и ты сам знаешь почему. К сожалению она ущербна, как ты и написал, инвалидация кэша происходит при изменении одного итема. В-третьих поддержание зависимостей на уровне пхп кода достаточно сложная задача для программиста и не поддается автоматизации — пробовали, знаем. Итого: пример совершенно не разъясняет сути стратегии и является глубоко теоретическим.
О том «на что нужно обратить внимание»
Про кэширование в файловую систему уже выше написал. кэширование разных объектов нужно просто организовывать так, чтобы при формировании хеша использовался и айдишник объекта и его имя. Далее — твоё утверждение, что основная нагрузка приходится на главную страницу — абсолютно неверно. Главная страница, как правило, кэшируется и очень быстро отдаётся, настоящая нагрузка распределена по всем остальным страницам сайта, в этом и заключается основная проблема упреждающего кэширования и сильно распухших кэшей — мы никогда заранее не знаем на какую именно страницу сайта придет пользователь, или робот поисковой системы. В результате тратим время на генерацию этих страниц и кэшируем редко запрашиваемые страницы, получая распухший кэш и настоящую нагрузку на сервер. Твой вариант с периодическим удалением всего кэша в автоматическом режиме не реализуем. Сейчас ты можешь сказать, что кэш можно удалять в зависимости от того сколько места он занимает на диске, сколько времени прошло с последнего удаления и так далее, но все это не более чем костыль и к стабильности отношения не имеет.
Проблема в том, что не каждый браузер даст вам посмотреть значение input type="file". Gmail же просто сабмитит всю форму периодически, реализовывая таким образом auto save.
Задавайте вопросы, если имеются.
Наверно стоило оговориться, что под синонимом в нашей системе подразумевается синоним на естественном языке, то есть одна сущность тэга может содержать несколько синонимов, а не так что несколько разных сущностей тэгов объявляются синонимами и для них назначается главный. сущность одна, значений много.
надеюсь я правильно понял ваш вопрос.
В базе будете первичные данные хранить без каких либо накладных индексов, а искать сфинксом — сказка.
Поиск по двум индексам и мердж этих индексов по ночам даст возможность риал-тайм индексации.
К сожалению, в своих статьях о кэшировании ты рассуждаешь как теоретик — сразу видно отсутствие практического применения. Теперь по пунктам:
Что нужно кэшировать
кэшировать нужно абсолютно всё. В твоём примере данные извлекаются за 0.1 секунды, а из кэша отдаются за 0.2. Проблема в том что тест синтетический — на нагруженном проекте данные будут извлекаться за 0.9, а из кэша по прежнему отдаваться за 0.2, разумеется это зависит от того какие именно данные и куда производится кэширование, будем считать, что мы правильно определили куда кэшировать эти конкретные данные, и даже при этом тайминги будут различаться примерно так. Суть в том, что в твоей теории ты забываешь об окружении, а окружение — это уже практика.
Куда нужно кэшировать
Память — это очень правильно. Для кэширования объектов. Тут нет замечаний.
кэширование в файловую систему.
Во-первых, смотрим сюда en.wikipedia.org/wiki/Ext2 — ты говоришь о лимите файлов — теоретический лимит там указан как 1.3 умножить на 10 в 20 степени. число 32768 — это максимальное количество директорий внутри директории, но не файлов.
Так или иначе если в генерации страницы участвует 100-300 объектов (каждый из которых закэширован в файловую систему в виде отдельного файла) на нагруженном сервере эта генерация займет значительно больше времени чем вычитывание этих объектов из памяти — почему больше написано чуть ниже про файловые бд.
Файловые базы данных — TDB, SQLite, DB4
На действительно нагруженных проектах сервера выполняют невероятное количество операций с диском, особенно если часть статики крутится на одном сервере с пхп. И любое обращение к памяти «под нагрузкой» будет в «сто раз» быстрее чем обращение к диску, так как диск постоянно занят. Но попробуем пренебречь этими фактами и допустить что на самом деле данные меняются один раз в сутки, после изменения данных мы генерируем кэш и работаем только с ним оставшиеся 23 с копейками часа — это как раз теория. На практике нет — данные меняются очень часто. Поэтому кэширование в файлы будет работать лишь очень короткое время, затем вся польза такого кэширования будет сведена на нет.
О твоем развернутом примере.
Во-первых — 50 000 статей это мелочь, это такая мелочь что не стоит и думать о времени извлечения одной статьи из базы. Думать стоит о построении коллекций, но даже об этом при правильной реализации хранения в базе думать не приходится — ведь хранить сам контент по которому не строятся коллекции в одной таблице с временем публикации глупо. Во-вторых, приведенная схема, основанная на времени изменения таблицы в базе мне очень знакома, и ты сам знаешь почему. К сожалению она ущербна, как ты и написал, инвалидация кэша происходит при изменении одного итема. В-третьих поддержание зависимостей на уровне пхп кода достаточно сложная задача для программиста и не поддается автоматизации — пробовали, знаем. Итого: пример совершенно не разъясняет сути стратегии и является глубоко теоретическим.
О том «на что нужно обратить внимание»
Про кэширование в файловую систему уже выше написал. кэширование разных объектов нужно просто организовывать так, чтобы при формировании хеша использовался и айдишник объекта и его имя. Далее — твоё утверждение, что основная нагрузка приходится на главную страницу — абсолютно неверно. Главная страница, как правило, кэшируется и очень быстро отдаётся, настоящая нагрузка распределена по всем остальным страницам сайта, в этом и заключается основная проблема упреждающего кэширования и сильно распухших кэшей — мы никогда заранее не знаем на какую именно страницу сайта придет пользователь, или робот поисковой системы. В результате тратим время на генерацию этих страниц и кэшируем редко запрашиваемые страницы, получая распухший кэш и настоящую нагрузку на сервер. Твой вариант с периодическим удалением всего кэша в автоматическом режиме не реализуем. Сейчас ты можешь сказать, что кэш можно удалять в зависимости от того сколько места он занимает на диске, сколько времени прошло с последнего удаления и так далее, но все это не более чем костыль и к стабильности отношения не имеет.
фцу
а
фцу
фцу
афцуа фцуа