Здравствуйте, gandjustas, Вы писали:

EP>>И чем они помогут в случае динамических фильтров и динамических предикатов?
G>В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
G>Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.

Тем не менее, вполне реальные use-case'ы для кэширования.

EP>>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
G>Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска.

1. Одна из задач, далеко не единственная. Причём это низкоуровевая постановка задачи, а высокоуровневая звучит как — оптимизировать скорость доступа к данным.
2. Я изначально рассмотрел два аспекта

Автор: Evgeny.Panasyuk
Дата: 19.04.15

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

G>Чтение одной "страницы" занимает 5-10 мсек,

Это HDD, причём в случае случайного доступа — если же грузится пачка последовательных страниц, то намного меньше
Для БД также используют SSD.

G>сколько там операций в памяти можно сделать за это время?

При последовательном доступе в одно ядро можно выдуть около десяти гигабайт за одну секунду, причём особо не напрягаясь.
За десять миллисекунд — около ста мегабайт. Если же результат обработки сотни мегабайт уже готов, то очевидно различия будут не доли миллисекунд как ты опрометчиво заявлял ранее.

EP>>>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>>>Походу ты действительно не знаешь как работают базы данных.
EP>>Аргументов как всегда не будет?
G>Я тебе их уже по три раза привел. Ты же всегда апеллируешь к теории. Увы, с теорией, особенно недоказанной спорить сложно.

А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно

G>Практических примеров у тебя нет.

То есть без практических примеров ты не можешь понять утверждение №1?

G>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование

Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.

G>поэтому твои теоретические выкладки не могу принять.

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

G>>>Не продолжай пожалуйста.
EP>>Давай, удачи, слив засчитан
G>Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.

Вот уже и лирика пошла, слабо оставаться в техническом русле?