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

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

Релевантные данные могут полностью находится в памяти.

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

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

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

"Эквивалентные" страницы для запроса могут помещаться в память, даже в случае когда вся база нет.

G>Время раундтрипа до базы окажется выше разницы между отдачей результата из кеша и из страниц в памяти. Даже при высоком hit ratio.

1. На обработку данных может понадобится десятки миллисекунд. Например для dummy пробежки одним ядром по ста магабайтам требуется около десяти миллисекунд. Roundtrip может быть намного меньше.
2. Даже если roundtrip намного больше, то всё равно есть преимущество — процессор/память базы не нагружается, соответственно больше свободных ресурсов для обработки других задач. То есть даже при большом latency всё равно для хорошего throughput много применений

G>>>Чтение одной "страницы" занимает 5-10 мсек,
EP>>Это HDD, причём в случае случайного доступа — если же грузится пачка последовательных страниц, то намного меньше
G>А у тебя есть уверенность, что тебе нужна последовательная пачка?

Конечно же нет — но это не повод выдавать частные утверждения за общие.

G>Станицы в файле данных обычно выделяются случайным образом, так как выделяется только первая свободная.

А разве СУБД не старается положить страницы таблицы рядом? Например те же extent'ы.

EP>>Для БД также используют SSD.
G>И что?

А то что для SSD чтение рандомной страницы будет как минимум в разы быстрее.

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

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

http://rsdn.ru/forum/flame.comp/6021253.1

Автор: gandjustas
Дата: 19.04.15

G>Тытоже не понимаешь как базы работают? Когда данные уж в ОП, то там различия минимальные, доли миллисекунд.

Даже для обработки сотен мегабайт, что совсем немного по меркам современных объёмов RAM — требуется десятки миллисекунд (одним ядром), а никакие не "доли"

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

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

G>Также очевидно что при равной вероятности любых запросов hit ratio будет нулевым и кеш по факту не будет работать, а при неравномерном распределении та же проблема решается индексами. Но тебе это тоже неочевидно.

Конечно это не очевидно, так как контрпример строится элементарно.

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

Опять таки, хотя бы на счёт агрегации ты согласился, так? Тогда зачем тест?
Или ты всё же считаешь что это практически не осуществимо? Если так, то что мешает?

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

Поясни. Что конкретно тебе понятно, и во что ты "не веришь" для утверждения №1?

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

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

Аргументы либо верные, либо нет — разница в опыте тут совершенно ортогональна. Их может быть недостаточно для основания утверждения, но в этом случае достаточно привести контраргумент.
Либо сами аргументы могут быть не верные, но и в этом случае достаточно привести контраргумент.

Апелляция к опыту может прокатить только против каких-то субъективных суждений. Пример субъективного суждения: "ИМХО, LINQ сильно тормозит".
Если же приводится объективное высказывание — "кэш результатов может уменьшить количество чтений с диска" — то тут апелляция к опыту не катит, как минимум она никак не опровергает это утверждение.

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

Ты приводишь не контраргументы, а лишь говоришь что для каких-то частных случаев это не справедливо — с чем я кстати согласен. Но, тем не менее, это никак не опровергает технические "выкладки".

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

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

G>ты считаешь "техническим руслом" ?

Нет, это ответ на твоё хамство.

G>Тогда я из него никогда и не выходил.

А я так и заметил