kugu
Новичок
Хранение объектов с точки зрения производительности
Собственно, почитал phpclubForum->search('хранение объектов')
Нашёл интересные вещи и реализации. Но подход там такой, что необходим механизм для хранения конкретных данных уже в виде объектов.
А у меня ситуация несколько иная:
Прелюдия:
По входным данным (варианты из списка, а не произвольные, список иногда обновляется) средствам множественных манипуляций с БД создается группа объектов. В основном, связанных и иерархичных.
Собственно проблема в том, что на построение уходит много ресурсов. Страница с минимумом данных (2-3 логически разных элемента) может использовать 30-50 SQL запросов с сложными объединениями которые в свою очередь используют представления (view) созданые ещё более сложными процедурами о_О БД Postgres.
Я сам не разбираюсь во всех запросах и методах объектов. Но в целом запросов с выполнением больше 0.02 сек - раз два и обчёлся. Т.е. сами запросы оптимизировать можно, но реальной производительности не даст. Среднее время обработки "простой" страницы 2-4 секунды. Оптимизация запросов даст от силы процентов 30 в скорости (это некоторых отдельных запросов, а в целом для страницы процентов 5 ну 10), имхо. Для "статичных" страниц это слишком дофига =\.
Суть:
Отсюда возникает мысль ... если страницы условно статичны и зачастую обновляются крайне редко то необходим механизм кеширования связанных объектов. Т.е. выполняем все операции по конструкции объектов, скорее всего частично доводя лишь до уровня отрисовки по темплейтам. И делаем дамп объектов в некий кеш...
Первоначальную "сложную" схему сборки объектов лучше вообще не трогать). Т.к. она было сделана по необходимости, а не по глупости) Просто типа очень обширная и универсальная схема...
Основные вопросы:
1) Что лучше использовать [un]serialize() (в текст файл, бд как текст или ещё как?) или какой-то иной способ ... например xml файлы или та-же бд, но уже не для дампа, а для структурированных свойств объекта? Возможно подключаемый php файл с инициализацией "заполненых" объектов?
2) Как лучше хранить связи? В мане по сериалайз вроде написано, что он автоматически сериализует всё по ссылкам объекта, а потом правильно востанавливает. Может кто сталкивался с подводными камнями?
3) Какие-то другие способы? Поделитесь, чтобы не изобретать велосипед). Возможно какой-то другой подход с кешем первичного сбора данных ... хз ... самое сложное, что я сам плохо въезжаю в схему и менять всю структуру - чревато многим...
Доп вопросы:
4) Идентификация объектов в кеше?) Сталкивались ли с уникальной идентификацией сгруппированных данных? В принципе, более-менее уникально идентифицирует полный УРЛ, но есть встроенные объекты которые сами как страница (могут менятся со временем ... в целом всё на динамике из бд, но обновляется не очень часто).
5) Вытекает из 4 .... контроль изменений ... даже если изменился только один незначительный компонент по идее лучше пересобрать весь объект родитель с потомками... Но! Как учесть какие группы объектов из кеша нужно рефрешить? =).
Вот... пока сам ещё не особо осмыслил, что и как должно быть ... но вдруг кто-то сталкивался =) В целом тема, имхо, интересная т.к. при построении очень "идеологических" объектных приложений и "очень реляционных баз данных" такие проблемы с тяжелым, ресурсоёмким построением должны возникать довольно часто).
З.Ы. (пока писал ещё нахлынуло...))
Объекты родители и входящие в них потомки отделены друг от друга. Потомки не "строки в таблицы", а паралельные элементы на странице ... ну типа родитель это веб-страница, а тут у неё меню, тут статья, а тут голосование ... к примеру).
Вот ... есть ли смысл кешировать постранично:
получил урл -> проверил кешибельность по урлу -> достал из кеша все данные для темплейтов и вывел (вроде совсем быстро)
или "по модульно":
получил урл -> проверил кешибельность -> достал быстрый список связей -> проверил кешибельность для каждого модуля -> вывел из кеша что было, чего небыло - собрал заново
вроде более умно и более гибко в плане применения ... больше инфы будет кешироваться, а не только совсем статичные страницы...
Пишите свои размышления на тему, мне в основном мыслей нехватает ... а уж конкретный функционал - это было-бы супер!
А ... и главный вопрос... допустим сериалайз и в файл, а потом ансериалайз в другой сессии ... быстрая ли это манипуляция?)) Объекты не самые простые, но бывают и сложнее ...) Выиграю ли что-то по сравнению с бд?). Абстрактно...)
Собственно, почитал phpclubForum->search('хранение объектов')
Нашёл интересные вещи и реализации. Но подход там такой, что необходим механизм для хранения конкретных данных уже в виде объектов.
А у меня ситуация несколько иная:
Прелюдия:
По входным данным (варианты из списка, а не произвольные, список иногда обновляется) средствам множественных манипуляций с БД создается группа объектов. В основном, связанных и иерархичных.
Собственно проблема в том, что на построение уходит много ресурсов. Страница с минимумом данных (2-3 логически разных элемента) может использовать 30-50 SQL запросов с сложными объединениями которые в свою очередь используют представления (view) созданые ещё более сложными процедурами о_О БД Postgres.
Я сам не разбираюсь во всех запросах и методах объектов. Но в целом запросов с выполнением больше 0.02 сек - раз два и обчёлся. Т.е. сами запросы оптимизировать можно, но реальной производительности не даст. Среднее время обработки "простой" страницы 2-4 секунды. Оптимизация запросов даст от силы процентов 30 в скорости (это некоторых отдельных запросов, а в целом для страницы процентов 5 ну 10), имхо. Для "статичных" страниц это слишком дофига =\.
Суть:
Отсюда возникает мысль ... если страницы условно статичны и зачастую обновляются крайне редко то необходим механизм кеширования связанных объектов. Т.е. выполняем все операции по конструкции объектов, скорее всего частично доводя лишь до уровня отрисовки по темплейтам. И делаем дамп объектов в некий кеш...
Первоначальную "сложную" схему сборки объектов лучше вообще не трогать). Т.к. она было сделана по необходимости, а не по глупости) Просто типа очень обширная и универсальная схема...
Основные вопросы:
1) Что лучше использовать [un]serialize() (в текст файл, бд как текст или ещё как?) или какой-то иной способ ... например xml файлы или та-же бд, но уже не для дампа, а для структурированных свойств объекта? Возможно подключаемый php файл с инициализацией "заполненых" объектов?
2) Как лучше хранить связи? В мане по сериалайз вроде написано, что он автоматически сериализует всё по ссылкам объекта, а потом правильно востанавливает. Может кто сталкивался с подводными камнями?
3) Какие-то другие способы? Поделитесь, чтобы не изобретать велосипед). Возможно какой-то другой подход с кешем первичного сбора данных ... хз ... самое сложное, что я сам плохо въезжаю в схему и менять всю структуру - чревато многим...
Доп вопросы:
4) Идентификация объектов в кеше?) Сталкивались ли с уникальной идентификацией сгруппированных данных? В принципе, более-менее уникально идентифицирует полный УРЛ, но есть встроенные объекты которые сами как страница (могут менятся со временем ... в целом всё на динамике из бд, но обновляется не очень часто).
5) Вытекает из 4 .... контроль изменений ... даже если изменился только один незначительный компонент по идее лучше пересобрать весь объект родитель с потомками... Но! Как учесть какие группы объектов из кеша нужно рефрешить? =).
Вот... пока сам ещё не особо осмыслил, что и как должно быть ... но вдруг кто-то сталкивался =) В целом тема, имхо, интересная т.к. при построении очень "идеологических" объектных приложений и "очень реляционных баз данных" такие проблемы с тяжелым, ресурсоёмким построением должны возникать довольно часто).
З.Ы. (пока писал ещё нахлынуло...))
Объекты родители и входящие в них потомки отделены друг от друга. Потомки не "строки в таблицы", а паралельные элементы на странице ... ну типа родитель это веб-страница, а тут у неё меню, тут статья, а тут голосование ... к примеру).
Вот ... есть ли смысл кешировать постранично:
получил урл -> проверил кешибельность по урлу -> достал из кеша все данные для темплейтов и вывел (вроде совсем быстро)
или "по модульно":
получил урл -> проверил кешибельность -> достал быстрый список связей -> проверил кешибельность для каждого модуля -> вывел из кеша что было, чего небыло - собрал заново
вроде более умно и более гибко в плане применения ... больше инфы будет кешироваться, а не только совсем статичные страницы...
Пишите свои размышления на тему, мне в основном мыслей нехватает ... а уж конкретный функционал - это было-бы супер!
А ... и главный вопрос... допустим сериалайз и в файл, а потом ансериалайз в другой сессии ... быстрая ли это манипуляция?)) Объекты не самые простые, но бывают и сложнее ...) Выиграю ли что-то по сравнению с бд?). Абстрактно...)
