Сообщение Re[43]: EntityFramework - тормоз от 20.04.2015 1:41
Изменено 20.04.2015 1:45 Evgeny.Panasyuk
Здравствуйте, gandjustas, Вы писали:
EP>>И чем они помогут в случае динамических фильтров и динамических предикатов?
G>В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
G>Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.
Тем не менее, вполне реальные use-case'ы для кэширования.
EP>>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
G>Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска.
1. Одна из задач, далеко не единственная. Причём это низкоуровевая постановка задачи, а высокоуровневая звучит как — оптимизировать скорость доступа к данным.
2. Я изначально рассмотрел два аспекта
G>Чтение одной "страницы" занимает 5-10 мсек,
Это HDD. Для БД также используют SSD.
G>сколько там операций в памяти можно сделать за это время?
При последовательном доступе в одно ядро можно выдуть около десяти гигабайт за одну секунду, причём особо не напрягаясь.
За десять миллисекунд — около ста мегабайт. Если же результат обработки сотни мегабайт уже готов, то очевидно различия будут не доли миллисекунд как ты опрометчиво заявлял ранее.
EP>>>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>>>Походу ты действительно не знаешь как работают базы данных.
EP>>Аргументов как всегда не будет?
G>Я тебе их уже по три раза привел. Ты же всегда апеллируешь к теории. Увы, с теорией, особенно недоказанной спорить сложно.
А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно
G>Практических примеров у тебя нет.
То есть без практических примеров ты не можешь понять утверждение №1?
G>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование
Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.
G>поэтому твои теоретические выкладки не могу принять.
Да не принимай — я привёл технические "выкладки". Если ты видишь в них ошибку, то тебе достаточно привести технический контраргумент, а не разглагольствовать на тему — можешь ли ты это принять или нет
G>>>Не продолжай пожалуйста.
EP>>Давай, удачи, слив засчитан
G>Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.
Вот уже и лирика пошла, слабо оставаться в техническом русле?
EP>>И чем они помогут в случае динамических фильтров и динамических предикатов?
G>В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
G>Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.
Тем не менее, вполне реальные use-case'ы для кэширования.
EP>>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
G>Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска.
1. Одна из задач, далеко не единственная. Причём это низкоуровевая постановка задачи, а высокоуровневая звучит как — оптимизировать скорость доступа к данным.
2. Я изначально рассмотрел два аспекта
Автор: Evgeny.Panasyuk
Дата: 19.04.15
: в первом существенно то что кэш занимает меньше памяти чем заняли бы эквивалентные страницы (и возможно не поместились бы, либо были вымыты из памяти и т.п.), а во втором сравнивается скорость в том случае когда и кэш и эквивалентные страницы полностью помещаются в пмять. Так вот, здесь мы находимся как раз во втором варианте — зачем ты вообще сюда пытаешься приплести чтение с диска?Дата: 19.04.15
G>Чтение одной "страницы" занимает 5-10 мсек,
Это HDD. Для БД также используют SSD.
G>сколько там операций в памяти можно сделать за это время?
При последовательном доступе в одно ядро можно выдуть около десяти гигабайт за одну секунду, причём особо не напрягаясь.
За десять миллисекунд — около ста мегабайт. Если же результат обработки сотни мегабайт уже готов, то очевидно различия будут не доли миллисекунд как ты опрометчиво заявлял ранее.
EP>>>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>>>Походу ты действительно не знаешь как работают базы данных.
EP>>Аргументов как всегда не будет?
G>Я тебе их уже по три раза привел. Ты же всегда апеллируешь к теории. Увы, с теорией, особенно недоказанной спорить сложно.
А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно
G>Практических примеров у тебя нет.
То есть без практических примеров ты не можешь понять утверждение №1?
G>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование
Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.
G>поэтому твои теоретические выкладки не могу принять.
Да не принимай — я привёл технические "выкладки". Если ты видишь в них ошибку, то тебе достаточно привести технический контраргумент, а не разглагольствовать на тему — можешь ли ты это принять или нет
G>>>Не продолжай пожалуйста.
EP>>Давай, удачи, слив засчитан
G>Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.
Вот уже и лирика пошла, слабо оставаться в техническом русле?
Re[43]: EntityFramework - тормоз
Здравствуйте, gandjustas, Вы писали:
EP>>И чем они помогут в случае динамических фильтров и динамических предикатов?
G>В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
G>Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.
Тем не менее, вполне реальные use-case'ы для кэширования.
EP>>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
G>Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска.
1. Одна из задач, далеко не единственная. Причём это низкоуровевая постановка задачи, а высокоуровневая звучит как — оптимизировать скорость доступа к данным.
2. Я изначально рассмотрел два аспекта
G>Чтение одной "страницы" занимает 5-10 мсек,
Это HDD, причём в случае случайного доступа — если же грузится пачка последовательных страниц, то намного меньше
Для БД также используют SSD.
G>сколько там операций в памяти можно сделать за это время?
При последовательном доступе в одно ядро можно выдуть около десяти гигабайт за одну секунду, причём особо не напрягаясь.
За десять миллисекунд — около ста мегабайт. Если же результат обработки сотни мегабайт уже готов, то очевидно различия будут не доли миллисекунд как ты опрометчиво заявлял ранее.
EP>>>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>>>Походу ты действительно не знаешь как работают базы данных.
EP>>Аргументов как всегда не будет?
G>Я тебе их уже по три раза привел. Ты же всегда апеллируешь к теории. Увы, с теорией, особенно недоказанной спорить сложно.
А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно
G>Практических примеров у тебя нет.
То есть без практических примеров ты не можешь понять утверждение №1?
G>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование
Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.
G>поэтому твои теоретические выкладки не могу принять.
Да не принимай — я привёл технические "выкладки". Если ты видишь в них ошибку, то тебе достаточно привести технический контраргумент, а не разглагольствовать на тему — можешь ли ты это принять или нет
G>>>Не продолжай пожалуйста.
EP>>Давай, удачи, слив засчитан
G>Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.
Вот уже и лирика пошла, слабо оставаться в техническом русле?
EP>>И чем они помогут в случае динамических фильтров и динамических предикатов?
G>В случае если пользователь может "накликать" любой запрос и кэш не поможет. Hit ratio будет низким.
G>Но в реальном приложении "произвольный" запрос к таблицам на миллионы строк можно встретить очень нечасто.
Тем не менее, вполне реальные use-case'ы для кэширования.
EP>>Я уже писал ранее что с СУБД вообще не приходится работать. Это, тем не менее, не освобождает оппонента от необходимости аргументировать свою позицию
G>Тогда специально для тебя еще раз объясняю. Задача СУБД — оптимизировать чтение с диска.
1. Одна из задач, далеко не единственная. Причём это низкоуровевая постановка задачи, а высокоуровневая звучит как — оптимизировать скорость доступа к данным.
2. Я изначально рассмотрел два аспекта
Автор: Evgeny.Panasyuk
Дата: 19.04.15
: в первом существенно то что кэш занимает меньше памяти чем заняли бы эквивалентные страницы (и возможно не поместились бы, либо были вымыты из памяти и т.п.), а во втором сравнивается скорость в том случае когда и кэш и эквивалентные страницы полностью помещаются в пмять. Так вот, здесь мы находимся как раз во втором варианте — зачем ты вообще сюда пытаешься приплести чтение с диска?Дата: 19.04.15
G>Чтение одной "страницы" занимает 5-10 мсек,
Это HDD, причём в случае случайного доступа — если же грузится пачка последовательных страниц, то намного меньше
Для БД также используют SSD.
G>сколько там операций в памяти можно сделать за это время?
При последовательном доступе в одно ядро можно выдуть около десяти гигабайт за одну секунду, причём особо не напрягаясь.
За десять миллисекунд — около ста мегабайт. Если же результат обработки сотни мегабайт уже готов, то очевидно различия будут не доли миллисекунд как ты опрометчиво заявлял ранее.
EP>>>>Пример конечно экстремальный, но поинт простой — готовый результат может быть в разы, а то и на порядки быстрее чем сырые данные. Причём не теряет актуальность даже в если до DB существенное latency — например в том случае если запросов много.
G>>>Походу ты действительно не знаешь как работают базы данных.
EP>>Аргументов как всегда не будет?
G>Я тебе их уже по три раза привел. Ты же всегда апеллируешь к теории. Увы, с теорией, особенно недоказанной спорить сложно.
А что тут "не доказано"? То что закэшированный запрос по данным в памяти может отличаться не на доли миллисекунд от обычного обхода (утверждение №1)? Вроде очевидно
G>Практических примеров у тебя нет.
То есть без практических примеров ты не можешь понять утверждение №1?
G>Можно лишь констатировать факт, что я немного больше знаю и имею больше опыта про субд и кеширование
Я об этом сразу сказал, можешь констатировать это хоть в каждом сообщении — аргументации это не добавит.
G>поэтому твои теоретические выкладки не могу принять.
Да не принимай — я привёл технические "выкладки". Если ты видишь в них ошибку, то тебе достаточно привести технический контраргумент, а не разглагольствовать на тему — можешь ли ты это принять или нет
G>>>Не продолжай пожалуйста.
EP>>Давай, удачи, слив засчитан
G>Тебе, конечно, никто не мешает считать себя умнее, но умнее от этого ты не станешь. Увы.
Вот уже и лирика пошла, слабо оставаться в техническом русле?