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

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

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

EP>Тем не менее, вполне реальные use-case'ы для кэширования.
На которых кэш не будет работать если считать любую комбинацию равновероятной. Но в реальном мире равномерного распределения вероятностей почти никогда не встретишь, а при нормальном распределении можно построить индексы, которые покроют 80% запросов, а на остальные 20% забить. И это будет в разы эффективнее кеша в базе.

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

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

EP>2. Я изначально рассмотрел два аспекта

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

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

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

EP>Это HDD, причём в случае случайного доступа — если же грузится пачка последовательных страниц, то намного меньше
А у тебя есть уверенность, что тебе нужна последовательная пачка? Станицы в файле данных обычно выделяются случайным образом, так как выделяется только первая свободная. Если регулярно ребилдить индексы, то можно добиться линейности чтений, но на очень незначительное время. Так что можно смело считать, что большинство чтений с диска — случайны.


EP>Для БД также используют SSD.
И что? Даже с SSD чтение с диска на порядки медленнее чем операции в памяти.

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

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


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

EP>А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно
Также очевидно, что память скушанная кешем приведет к повышению количества чтений с диска. Но тебе почему-то неочевидно.
Также очевидно что при равной вероятности любых запросов hit ratio будет нулевым и кеш по факту не будет работать, а при неравномерном распределении та же проблема решается индексами. Но тебе это тоже неочевидно.
Причем этим очевидным вещам ты противопоставляешь чисто теориетические выкладки. Приведи хоть один результат тестов, который подтверждает твои слова.

G>>Практических примеров у тебя нет.
EP>То есть без практических примеров ты не можешь понять утверждение №1?
Понять != поверить.

G>>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование
EP>Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.
Это я к тому, что твоя агрументация слаба.

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

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

слив засчитан

ты считаешь "техническим руслом" ? Тогда я из него никогда и не выходил.