Кэширование SQL запросов. как взрослые дяди делают это?

[Wingely Dog]

Кэширование SQL запросов. как взрослые дяди делают это?

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

 

[neko]

хорошо было бы еслиб ты сам еще понимал о чем спрашиваешь

 

[alpes]

Query Cache

 

[Wingely Dog]

2neko
я не имел ввиду каширование именно текстов запросов 8).
естественно идет речь о кэшировании результатов. так что я тебя уверяю, все хорошо.

2alpes
нет не то. я думаю на счет того, чтобы сделать свою систему кэширования на основе php. на манер того, как это делает Smarty со своими шаблонами. Я написал некий датамаппер позволяющий получать объекты в качестве результата работы с базой данных. Причем интерфейс не зависит от того с какой базой данных идет работа. Так что использование нативное кэширование с помощью сервисов какой то конкретной базы данных не подходит.

Сходу напрашивается вариант использования сериализации объектов и записи их в файлы. Но возникает вопрос насколько это шустрое решение? не будет ли время сериализации - десериализации сопоставимо со временем запроса в базу данных? Тоесть я конечно могу попробовать. Но хотелось бы обойти в этом вопросе те грабли по которым ходили уже другие.

 

[neko]

чудесно, но прости -- это очень простые вопросы
на них ты должен ответить сам если собираешся заниматься такими вещами

если тебя интересуют грабли, я могу подсказать одни самые типичные с кешированием:
а именно
попытка всунуть в приложение кеширующий слой между неподходящими для такой прослойки звеньями

 

[Wingely Dog]

простота вопроса зависит от отвечающего.
и необходимость самостоятельного принятия решения весьма спорна, ибо изорбретение даже очень хорошего велосипеда, остается изобретением велосипеда.

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

 

[neko]

мне очень грустно это слышать
ведь любое кеширование, суть оптимизация на скорость
а как мы знаем(?) прежде чем что-угодно оптимизировать надо определить нужно ли это вообще и если да, то какие места в архитектуре приложения наиболее подходят для оптимизации

а ты этот, ключевой для данной проблемы вопрос, оставил без внимания.
извини форматы сброса это абсолютно неинтересная на данном этапе тема
тем более что и выбор небольшой при такой постановке задачи, не так ли?

 

[Wingely Dog]

neko - мозг не жмет? 8)

с чего ты взял что я не знаю для чего я собираюсь делать кэширование и нужно ли оно мне? я что где-то в этом топике написал что-то вроде "люди я тут написал что-то и вот не знаю нужно мне кеширование и если нужно то в каком месте?".
С чего ты вообще взял что я нахожусь на этапе проектирования слоя обращений к базе данных?!

если тебе на каком то этапе не интересна данная тема, просто не пиши сюда. неужели это сложно?

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

Есть некий результат обращения к базе данных в виде множества объектов описывающих строки выборки. Необходимо сбросить это на диск и по идеинтичному запросу, в случае актуальности выборки, снять с диска и вернуть результат.
Все.

Задача заключается в оптимальном алгоритме сброса-чтения множеств.

 

[neko]

ура, заговорил
значит смотри

меня интересует механизм именно кэширования

а) механизм зависит от места применения

С чего ты вообще взял что я нахожусь на этапе проектирования слоя обращений к базе данных?!

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

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

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

Задача заключается в оптимальном алгоритме сброса-чтения множеств

г) оптимальным в данном случае будет либо описать задачу более подробно, либо принять за факт -- то, чего ты хочешь, не имеет ни практической, ни какой либо иной пользы

 

[Wingely Dog]

то что ты говоришь субъективно.

а) -> я тоже знаю кучу многзначительных фраз. могу продемонстрировать.

б) ->
не факт, что верхние слои не должны знать с чем они работают. не должны знать те кто работает с моделью данных. но объект занимающийся извлечением данных из базы данных ИМХО вполне может решать обращаться к базе данных через прямой интерфейс или через интерфейс использующий кэширование.
соответственно заявление типа "если разница есть, то это не кеширование" - бред сивой кобылы.

в) ->
рекомендую к прочтению буку М.Фаулера "архитектура корпоративных прокраммных продуктов" ( вроде так зовется ). Особенно рекомендую обратить внимание на паттерны "множество записей" "шлюз данных" и на различия между объектными и реляционными данными. Просто чтобы быть в курсе о чем идет речь.

г) -> см. пункт а)

 

[neko]

а) -> я тоже знаю кучу многзначительных фраз. могу продемонстрировать.

не трудись, это заметно с начала треда

объект занимающийся извлечением данных из базы данных ИМХО вполне может решать обращаться к базе данных через прямой интерфейс или через интерфейс использующий кэширование.

да пожалуй тут ты прав

рекомендую к прочтению буку М.Фаулера "архитектура корпоративных прокраммных продуктов" ( вроде так зовется ).

дай угадаю, под "архитектурой прокраммных продуктов" подразумевается patterns of enterprise application architecture? спасибо, я ее читал 2 года назад примерно.

да кстати, на случай если ты не заметил, из нас двоих я не нуждаюсь в том, чтобы мне что-то доказывали -- вопрос и так предельно ясен.

у тебя еще есть что рассказать о своих грандиозных замыслах, и что более важно о их причинах, или осталось только (а)?

 

[Wingely Dog]

ежли читал то к чему твоя реплика о хранении множества записей в РСУБД?
у меня есть множество объектов собраное неким громоздким запросом, ты мне предлагаешь засунуть его назад в БД. Оригинально 8). Тогда действительно кэширование не имеет никакого смысла.

после того что ты ляпнул в своем пункте б) я врятли в ближайшем будущем послушаю твоего мнения о скольнибудь серьезной теме.

ЗЫ: да кстати если ты не заметил. из нас двоих только тебе непонятно что ненравится и только ты из полудесятка постов ничего по теме не сказал.

 

[neko]

у меня есть множество объектов собраное неким громоздким запросом, ты мне предлагаешь засунуть его назад

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

 

[Wingely Dog]

ее? вася петя кирпич башка бум бум? 8)
честно говоря не понял предложения.

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

 

[neko]

честно говоря не понял предложения.

честно говоря я упарился повторять за пол дня десятый раз одно и то же, видимо нет во мне павловского упорства

 

[Wingely Dog]

ну дык и я примерно тем же занимаюсь,
только с другой стороны 8)

так ты объясни русскими буквами идею то? препирались препирались пол дня и вот когда уже стал виден свет в конце тунеля ты вдруг упарился 8)
колись уже по делу, что куда?

 

[Sad Spirit]

Автор оригинала: Wingely Dog

в) ->
рекомендую к прочтению буку М.Фаулера "архитектура корпоративных прокраммных продуктов" ( вроде так зовется ). Особенно рекомендую обратить внимание на паттерны "множество записей" "шлюз данных" и на различия между объектными и реляционными данными. Просто чтобы быть в курсе о чем идет речь.

Фаулер в вопросах, связанных с реляционной моделью, лажает не по-детски. Красноречивая цитатка (стр. 62 в русском издании):

Здесь и ниже, употребляя слово таблица (table), я имею в виду, что обсуждаемые приёмы и решения применяемы в равной мере ко всем данным, отличающимся табличным характером: к хранимым процедурам (stored procedures), представлениям (views), а также к (промежуточным) результатам выполнения "традиционных" запросов и хранимых процедур. К сожалению, какой-либо общий термин, который охватывал бы все эти понятия, отсутствует.

Очевидно, что такой термин есть: relation (отношение), в честь него и названы реляционные базы. Мэтр в них очевидно понимает не больше, чем посетители местного загона для мысклеводов.

 

[Wingely Dog]

где-то в php&ЮМОР
была подобная темка, только там про 2х2 спрашивали 8/

 

[neko]

Sad Spirit
не читай переводы
в оригинали не "термин отсутствует"
а "there isn't a widely used term"

relation это терминалогия гм, определенной группы лиц.
далеко не все знают что такое кортеж, отношение итп.

про "хранимые процедуры отличающиеся табличным характером" я помолчу

 

[wrapper]

>тема заключается в кэшировании результатов обращения к базе >данных, яля множестов записей, для разгрузки базы данных.
ИМХО кеширование результатов запроса это забота СУБД.