Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну сколько можно? Тебе уже несколько человек говорят — не трепись о том, о чем не знаешь. Нет там никаких "диких" расходов.
ОК, если ты в отличие от меня действительно знаешь о чём говоришь, то для тебя конечно же не будет проблемой поделиться конкретными цифрами? )
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В решарпере нет доступа к БД через линк. От слова совсем. IQueryable и IEnumerable это далеко не одно и тоже.
Прочти внимательнее, на что я отвечал. Там же чётко написано "это уже речь не про обсуждаемый здесь linq к БД, а про просто linq, который ещё более печален." Довольно глупо пытаться выставить собеседника незнающим идиотом с помощью стирания цитат — на форуме же всё равно всё записано.
Здравствуйте, gandjustas, Вы писали:
_>>Да, и кстати чем больше база, тем собственно больше будет бонус от подключения кэша (он то по любому в оперативной памяти сидит и при этом занимает не особо много места). G>Это полнейший бред. Чем больше база, тем больше памяти нужно для каждого запроса. При чтении с дика данные поднимаются в память (buffer pool), а уже оттуда отдаются на клиент. Если у тебя есть кеш, то он отнимает память у buffer pool и базе приходится чаще читать с диска.
В buffer pool ведь сидят страницы, в которых находятся целые строки таблиц, так? Тогда:
1. Закэшированный результат запроса скорей всего будет занимать меньше памяти чем "эквивалентный" набор страниц для повторного запроса, так как в нём будет меньше столбцов и строк — только самое необходимое. А следовательно будет больше свободной памяти, которую можно использовать под другие страницы, или другие кэши запросов.
2. Даже если все необходимые страницы в памяти, то "эквивалетная" закэшированному запросу операция может занять намного больше времени — так как требуется обработать больше данных из random'ных участков памяти.
Здравствуйте, gandjustas, Вы писали:
G>Обычно корпоративным софтом называют тот, который используется в интересах компаний, а не конкретных пользователей. G>Если ты хоешь обсудить тот софт, который создается несофтовыми конторами, то очевидно там качество кода будет ниже, чем в софте, создаваемом софтовыми конторами. Но какое это имеет отношение к предмету разговора?
Потому как:
1. Именно эти товарищи и представляют собой основную массу программистов (а вовсе не авторы какого-нибудь там mssql).
2. Именно эти товарищи никогда не будут делать поддержку нескольких БД и избегать говнокода. Потому как им это всё просто не надо. Так что в их приложениях действительно никогда не встретится уровень абстракции БД. Однако это не значит, что данный стиль работы надо брать за образец.
G>Еще раз для тебя повторю проблему: надо под каждый сценарий генерировать свою строку. В серьезной программе таких строк — тысячи. Просто выписать их невозможно, генерировать с помощью склейки — проблемно. При ручной склейке строк возникают проблемы безопасности (ты и сам пример привел), часто получаются неочень корректные и неочень оптимальные запросы.
G>Нужен тул, который автоматизириует. А еще надо поддерживать (то есть править строки при правке логики и схемы данных), что с Linq делать очень удобно, а без него — ад.
G>Я тебе это уже раз десять повторил. Ты все еще не понял проблемы? Зачем тогда продолжаешь писать?
А я тебе уже 10 раз ответил, что двумя руками за подобный тул для автоматизации. Речь была исключительно о том, что конкретная реализация по имени linq очень далека от идеала.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>На фоне десятков миллисекунд доступа к БД даже на простых запросах — совсем немного.
EP>А если запрос в БД закэширован, или хотя бы нужные страницы уже в памяти? Неужели даже в этих случаях современные БД дают десятки миллисекунд?
прошу прощения. можно влезть как наблюдателю?
обращение к обоим спорщикам:
вы могли бы привести реальные тесты/замеры/цифры затрат на linq генерацию, чтобы говорить уже не об абстрактных вещах которые уже по пятому разу интерпретируются в нужную сторону от микросекунд до миллисекунд? ну чтобы спор стал предметным и можно было "тыкать носом"
p.s. от себя могу добавить, что мне таки приходится использовать CompiledQuerys в linq2db, потому как на частых запросах (сотни в секунду) загрузка процессора вырастает без всякой на то нужды, причем заметно.
Здравствуйте, AK107, Вы писали:
AK>прошу прощения. можно влезть как наблюдателю?
Конечно
AK>обращение к обоим спорщикам: AK>вы могли бы привести реальные тесты/замеры/цифры затрат на linq генерацию, чтобы говорить уже не об абстрактных вещах которые уже по пятому разу интерпретируются в нужную сторону от микросекунд до миллисекунд? ну чтобы спор стал предметным и можно было "тыкать носом"
gandjustas — думаю завышать он не будет, а уж придумывать тем более. Причём, насколько я понял, он там говорил про оверхед только от обхода Expression Tree, в то время как под капотом там же не только ET обходится.
Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе.
Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
AK>p.s. от себя могу добавить, что мне таки приходится использовать CompiledQuerys в linq2db, потому как на частых запросах (сотни в секунду) загрузка процессора вырастает без всякой на то нужды, причем заметно.
Если бы compiled LINQ от plain отличался бы на 10 микросекунд, то на сотнях запросах в секунду загрузка процессора от plain LINQ была бы меньше процента.
Здравствуйте, gandjustas, Вы писали:
_>>Угу, есть. И не точечные. Правда не какого-то большого приложения, а специально написанного мелкого тестового. G>Показывай.
Я тебе как раз их и озвучивал тут, когда говорил о запросах в пару секунд и кэширование их в 0,5 мс. )
G>Это полнейший бред. Чем больше база, тем больше памяти нужно для каждого запроса. При чтении с дика данные поднимаются в память (buffer pool), а уже оттуда отдаются на клиент. Если у тебя есть кеш, то он отнимает память у buffer pool и базе приходится чаще читать с диска. G>Ты ни разу не тестировал на базе, которая не влезает в ОП если так говоришь.
Это ты похоже бредишь, если считаешь что размер кэша и основной памяти должен быть одинаковым. Даже если не можешь провести аналогию с классическими кэш системами, то хотя бы просто взглянул на дефолтное значение параметра размера кэша в обсуждаемых СУБД.
Ну и кстати даже если бы предположим кэш занимал бы очень много и вытеснял страницы таблицы из памяти, то увеличение времени первого запроса в несколько раз с одновременным уменьшением тысяч следующих запросов (таких же) в 100 раз приводит понятно к какому результату. )))
G> G>Логика на грани фантастики. Небольшой ликбез — реальное быстродействие запроса зависит от количества чтений с диска. Чтение происходит страницами, есть более-менее универсальный показатель physical read. Чем больше физических чтений, тем медленнее работает. G>Если база маленькая (влезает в ОП с запасом), то physical read = 0 всегда и быстродействие начинает зависеть от многих факторов, но несильно. Чем меньше у тебя памяти под buffer pool, тем больше physical read, тем медленнее все работа. Кеш в базе отбирает память у buffer pool, причем чем чаще попадания в кеш, тем меньше памяти у buffer pool и тем медленнее все работает. Естественно это можно увидеть только на базах, больших чем ОП сервера, есть подозрение, что ты таких не видел.
Повторюсь ещё раз: чем больше база, тем лучший будет эффект от включения кэша. Если тебе это не очевидно, то я даже не знаю о чём можно ещё говорить. )))
G>Это и есть динамические запросы. Так как в точки зрения конструктора нет ни одной фиксированной части запроса, на которую можно ориентироваться. Я это уже объяснял — что можно взять запрос, навесить на него свой предикат\проекцию\группировку, и передать в другую функцию в другой сборке. Ты не понял? Я тебе уже по 10 раз одно и тоже разными словами пытаюсь объяснить, а ты до сих пор делаешь вид что не понимаешь. Или ты реально не понимаешь? Тогда зачем пишешь?
Угу, он динамический... Относительно той переменной. ))) Однако если ты посмотришь на итог, то окажется что из конкретного модуля у тебя будет исходить всегда один и тот же запрос.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
G>>На нетривиальных запросах это несколько миллисекунд. При тыще запросов в секунду только формирование SQL из ET скушает пару ядер процессора.
Обрати внимание — на нетривиальных. Это такие запросы, которые выполняются десятые секунды и даже единицы секунд. На этом фоне называть 1-2 миллисекунды диким расходом — это, мягко говоря, перебор.
НС>>Избавившись от линка ты просто вынужден будешь писать меппинг руками. Получив все те же миллисекунды. EP>Что конкретно входит в mapping? Используется ли там что-то типа reflection?
Нет, не используется. Используется генерация кода.
НС>>Ты уж поверь — в процессе разработки linq2db он сравнивался с полностью рукопашным кодом. EP>С каким конкретно рукопашным кодом? Гвоздями прибитым к конкретным структурам, или всё же с некоторой автоматизацией?
С гвоздями. Быстрее в рамках платформы ваще никак.
Здравствуйте, alex_public, Вы писали:
НС>>Ну сколько можно? Тебе уже несколько человек говорят — не трепись о том, о чем не знаешь. Нет там никаких "диких" расходов. _>ОК, если ты в отличие от меня действительно знаешь о чём говоришь, то для тебя конечно же не будет проблемой поделиться конкретными цифрами? )
Десятые и сотые доли процента от времени всего запроса.
Здравствуйте, Ночной Смотрящий, Вы писали:
G>>>На нетривиальных запросах это несколько миллисекунд. При тыще запросов в секунду только формирование SQL из ET скушает пару ядер процессора. НС>Обрати внимание — на нетривиальных. Это такие запросы, которые выполняются десятые секунды и даже единицы секунд. На этом фоне называть 1-2 миллисекунды диким расходом — это, мягко говоря, перебор.
Нетривиальный может выполняться достаточно быстро — например если все страницы в памяти, или результат запроса уже в кэше.
И опять таки, даже если запрос из базы приходит долго — это не повод лишний раз загружать процессор на клиенте (выше говорят что от сотен запросов в секунду есть ощутимая нагрузка).
НС>>>Избавившись от линка ты просто вынужден будешь писать меппинг руками. Получив все те же миллисекунды. EP>>Что конкретно входит в mapping? Используется ли там что-то типа reflection? НС>Нет, не используется. Используется генерация кода.
Во время сборки/компиляции или в runtime? (bytecode emit?)
НС>>>Ты уж поверь — в процессе разработки linq2db он сравнивался с полностью рукопашным кодом. EP>>С каким конкретно рукопашным кодом? Гвоздями прибитым к конкретным структурам, или всё же с некоторой автоматизацией? НС>С гвоздями. Быстрее в рамках платформы ваще никак.
Тогда о чём ты говоришь тут:
НС>Несколько миллисекунд это вообще весь меппинг. Избавившись от линка ты просто вынужден будешь писать меппинг руками. Получив все те же миллисекунды.
?
То есть от LINQ практически нулевой overhead? Или ты всё же про скомпилированные запросы?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Десятые и сотые доли процента от времени всего запроса.
В такой формулировке это разговор ни о чём, потому как тогда надо уточнять ещё десяток параметров по устройству запроса, БД, настройкам СУБД. К примеру включение/выключение индексов или кэширования меняет указанное тобою значение в десятки раз.
Так что лучше назови значение в абсолютных цифрах, а время обработки конкретных запросов БД (и соответственно процент накладных расходов для них) тут все способны прикинуть сами.
Здравствуйте, alex_public, Вы писали:
_>>>Ну так значит "внезапно" реляционная модель оказывается не единственной полезной? ) НС>>Извивы твоей логики от меня ускользают.
_>Всё ты прекрасно понял.
Нет.
_> ) Просто не стоило кидаться фразами
Давай я как нибудь сам буду решать, что мне стоило, а что нет.
_>Сам же понимаешь, что будет в случае попытки использования этой модели для каких-нибудь там графов. )
Нет, не понимаю. Чтобы хранить граф в РСУБД придется придумать для него реляционное представление. Если же решать задачу в лоб, просто преобразуя связи в FK, то, с хорошей вероятностью, тормоза обеспечены.
_> Ну вот предположим int поле из БД должно отoбражаться во что-то типа class MyInt{int val; public: operator=(...); operator+(...);...}.
Да просто указываешь его в качестве типа свойства класса модели и все. Плюс там какие то требования к этому классу есть, я сейчас по памяти точно не помню. Модель данных, о которой я говорил это прежде всего связи. А маппинг между типом БД и типом CLR это мелочь, которую умеет любой приличный ORM.
НС>>А с чего бы мне считать обычную функцию аж слоем абстракции? Слой это когда ты полностью все закрываешь. А когда у тебя чтение пользователей все равно через IQueryable идет — никакой это не слой. _>Про чтение мы ещё не говорили, пока речь была просто про создание.
Тогда нефик приплетать сюда слои.
_> И там функция имела вид dbAddUser(string), а внутри могла иметь как несколько sql запросов, так и один nosql (в таких базах благодаря иерархической структуре обычно достаточно одного). На мой взгляд вполне себе нормальная абстракция.
Не абстракция, а банальная функция. Нет нужды ее выносить в отдельный слой. На практике обычно такое пишется прям по месту, а если вдруг понадобилось где то еще, то делается один из самых примитивных рефакторингов — extract method. Причем соверешнно пофигу, если там линк, нет его, им есть ли там вообще хоть что то напоминающее БД.
_>Ну и если говорить о чтение, то откуда там обязательно IQueryable?
Оттуда.
_> ) Скорее User dbGetUser(int id); и vector<User> dbGetUsers(); или что-то подобное. )
Во во. Об этом я и говорю — плодим кучу методов, внутри которых перекладывание из пустого в порожнее. И что особо радует глаз, так это то что 90% таких методов вызываются ровно в 1 месте. Я уж не говорю про веселье под названием User — то ли мы из БД все сразу тянем, то ли этот самый User в полуинициализироыванном состоянии. А потом веселый парень передает этот User куда нибудь, где кто то ждет те поля, которые на самом деле незаполнены, и привет странные и трудно вылавливаемые глюки. И это, замечу, не несуществующие ситуации типа сложения рублей с килограммами, а самая что ни на есть скучная рутина.
Вобщем, стрелять. Ставить перед пушкой и стрелять.
_>Ну так в общем случае конечно же не получится написать что-то оптимальное.
Вот и нефик лужу газировать вредными абстракциями.
_> Однако если мы говорим о конкретном приложение с конкретной БД (не СУБД, а именно таблицами и т.п.), то какие могут быть проблемы в написание оптимального слоя абстракции?
Ненужная и вредная работа и раздутый на ровном месте код.
Здравствуйте, alex_public, Вы писали:
НС>>В решарпере нет доступа к БД через линк. От слова совсем. IQueryable и IEnumerable это далеко не одно и тоже. _>Прочти внимательнее, на что я отвечал. Там же чётко написано "это уже речь не про обсуждаемый здесь linq к БД, а про просто linq, который ещё более печален."
Ну то есть ты признаешься что решил заняться демагогией и перевести тему?
_> Довольно глупо пытаться выставить собеседника незнающим идиотом с помощью стирания цитат — на форуме же всё равно всё записано.
Идиотами ты ту пытаешься выставить нас, а мне приходится постоянно ловить тебя за руку.
Здравствуйте, alex_public, Вы писали:
IT>>Ты его сам видел хотя бы один раз вблизи? _>Конечно видел и его и аналогичные или лучшие инструменты из других языков.
Т.е. ты можешь совершенно точно сказать где именно у linq критические в плане производительности места и как с этим можно бороться?
Если нам не помогут, то мы тоже никого не пощадим.
gandjustas — думаю завышать он не будет, а уж придумывать тем более. Причём, насколько я понял, он там говорил про оверхед только от обхода Expression Tree, в то время как под капотом там же не только ET обходится. EP>Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе. EP>Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
ну вообще здесь есть сравнение, но данные устаревшие. разница между plain sql и bltoolkit в любом случае не драматична, да и не должна быть таковой в виду сетевого ввода/вывода, даже если в СУБД все закэшировано по самый край
еще добавлю, если мне нужны ну ооочень частые запросы (а это как правило очень быстрые запросы), я использую compiled queries, в противном случае разница в два раза в сравнение с plain sql вообще не имеет значения — такие запросы как правило занимают уже существенно больше времени сами по себе на стороне БД чем оверхед на генерацию sql. Но да, я готов платить за удобство, статическую проверку и общий подход к работе с БД как с наборами данных.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Нетривиальный может выполняться достаточно быстро — например если все страницы в памяти, или результат запроса уже в кэше.
И сам запрос в кеше, и много чего еще. По факту латентность доступа к реальной БД всегда более чем ощутима.
НС>>Нет, не используется. Используется генерация кода. EP>Во время сборки/компиляции или в runtime? (bytecode emit?)
Тулой во время сборки, без тулы при первом использовании в рантайме.
EP>То есть от LINQ практически нулевой overhead?
Не нулевой, но довольно маленький.
EP> Или ты всё же про скомпилированные запросы?
Конкретно linq2db компиляцию запросов даже в рантайме кеширует. Проблема там только одна — для получения хеша запроса приходится обходить дерево. Это на самом деле довольно быстро (не в EF, так индусы наиндусячили) — никакого рефлекшена при обходе нет, там обычная AST в памяти максимум на сотню-другую узлов. Но да, какой то процент на куче мелких запросов отыграть можно, если МС соблаговолит дать возможность сделать это быстрее, подпилив компилятор шарпа.
Здравствуйте, alex_public, Вы писали:
НС>>Десятые и сотые доли процента от времени всего запроса. _>В такой формулировке это разговор ни о чём
А твой вопрос, без конкретных запросов, БД, железа и т.п. — тоже ни о чем. Интересно значение в конкретной ситуации — напиши и прогони тест сам. Я за тебя это сделать не в состоянии. А на моих данных — я сказал.
И могу тебе другое сказать — переписывание реальных приложений с текстовых запросов и ХП на linq мне приходилось делать несколько раз. И всегда после переписывания приложение начинало работать быстрее, от десятков процентов до разов. Хочешь верь, а хочешь нет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
EP>В buffer pool ведь сидят страницы, в которых находятся целые строки таблиц, так? Тогда:
EP>1. Закэшированный результат запроса скорей всего будет занимать меньше памяти чем "эквивалентный" набор страниц для повторного запроса, так как в нём будет меньше столбцов и строк — только самое необходимое. А следовательно будет больше свободной памяти, которую можно использовать под другие страницы, или другие кэши запросов.
Интересно как ты это посчитал.
Даже если в программе банальный CRUDL, то к каждой таблице идет минимум два запроса — на получение списка и на чтение одной строки по ключу. То есть в кеше будет занимать БОЛЬШЕ данных чем buffer pool. В реальном приложении, с джоинами будет еще больше данных в кеше. А если список достаточно большой и запросы равновероятны, то от кеша вообще толку нет, так как hit ratio будет слишком низкий.
EP>2. Даже если все необходимые страницы в памяти, то "эквивалетная" закэшированному запросу операция может занять намного больше времени — так как требуется обработать больше данных из random'ных участков памяти.
Тытоже не понимаешь как базы работают? Когда данные уж в ОП, то там различия минимальные, доли миллисекунд. Самое долгое — поднятие данных с диска. Получается примерно так: если база не помещается в память, то резервирование под кеш 10% объема ОП приведет к росту чтений с диска на 10%. Это десятки-сотни миллисекунд. Так что автоматический кеш в базе категорически неэффективен. Автоматический кэш запросов даже в приложении неэффективен, у него hit ratio чрезмерно низкий, и это при том, что он не мешает работать БД.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Обычно корпоративным софтом называют тот, который используется в интересах компаний, а не конкретных пользователей. G>>Если ты хоешь обсудить тот софт, который создается несофтовыми конторами, то очевидно там качество кода будет ниже, чем в софте, создаваемом софтовыми конторами. Но какое это имеет отношение к предмету разговора?
_>Потому как: _>1. Именно эти товарищи и представляют собой основную массу программистов (а вовсе не авторы какого-нибудь там mssql).
С чего ты взял? Как раз большая часть разработчиков работает в конторах, которые специализируются на софте.
_>2. Именно эти товарищи никогда не будут делать поддержку нескольких БД и избегать говнокода. Потому как им это всё просто не надо. Так что в их приложениях действительно никогда не встретится уровень абстракции БД. Однако это не значит, что данный стиль работы надо брать за образец.
Кроме них еще миллионы разработчиков не будут делать поддержку нескольких БД просто потому что им это не надо.
Ты наверное не понимаешь, что поддержка нескольких БД не является ценностью. Для этого нужно много затрат, зачастую снижает другие характеристики приложения, а продажи повысить не поможет вообще никак (в большинстве случаев).
G>>Еще раз для тебя повторю проблему: надо под каждый сценарий генерировать свою строку. В серьезной программе таких строк — тысячи. Просто выписать их невозможно, генерировать с помощью склейки — проблемно. При ручной склейке строк возникают проблемы безопасности (ты и сам пример привел), часто получаются неочень корректные и неочень оптимальные запросы. G>>Нужен тул, который автоматизириует. А еще надо поддерживать (то есть править строки при правке логики и схемы данных), что с Linq делать очень удобно, а без него — ад. G>>Я тебе это уже раз десять повторил. Ты все еще не понял проблемы? Зачем тогда продолжаешь писать? _>А я тебе уже 10 раз ответил, что двумя руками за подобный тул для автоматизации. Речь была исключительно о том, что конкретная реализация по имени linq очень далека от идеала.
Так другой нет. Да и с Linq проблем не много, поэтому не надо чинить что не сломано. В других языках даже близко подобного нет.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Угу, есть. И не точечные. Правда не какого-то большого приложения, а специально написанного мелкого тестового. G>>Показывай. _>Я тебе как раз их и озвучивал тут, когда говорил о запросах в пару секунд и кэширование их в 0,5 мс. )
Код показывай и базу.
G>>Это полнейший бред. Чем больше база, тем больше памяти нужно для каждого запроса. При чтении с дика данные поднимаются в память (buffer pool), а уже оттуда отдаются на клиент. Если у тебя есть кеш, то он отнимает память у buffer pool и базе приходится чаще читать с диска. G>>Ты ни разу не тестировал на базе, которая не влезает в ОП если так говоришь.
_>Это ты похоже бредишь, если считаешь что размер кэша и основной памяти должен быть одинаковым. Даже если не можешь провести аналогию с классическими кэш системами, то хотя бы просто взглянул на дефолтное значение параметра размера кэша в обсуждаемых СУБД.
А с чего ты взял что я так считаю?
_>Ну и кстати даже если бы предположим кэш занимал бы очень много и вытеснял страницы таблицы из памяти, то увеличение времени первого запроса в несколько раз с одновременным уменьшением тысяч следующих запросов (таких же) в 100 раз приводит понятно к какому результату. )))
Это при условии что один и тот же запрос приходит Ты же понимаешь что в реальности так не бывает. Тебе прилетит 1000 разных запоров, а только 1001 будет повторять первый. При этом кеш первого уже вытеснен, а ОП для buffer pool стало меньше ровно на размер кешей и внезапно нужные страницы не в памяти, и ты попадаешь на физическое чтение.
На маленькой базе этого не будет видно, а на большой — еще как.
Даже если кешировать на стороне приложения и иметь огромный объем памяти под кеш за пределами базы, то кешировать все запросы — крайне неэффективная стратегия (сам делал, знаю). А в базе, отбирая ресусры у buffer pool — вообще выглядит плохой шуткой. В лучшем случае выборочный кеш нужен, а в идеале за пределами БД.
_>Повторюсь ещё раз: чем больше база, тем лучший будет эффект от включения кэша. Если тебе это не очевидно, то я даже не знаю о чём можно ещё говорить. )))
Архитектура баз данных говорит нам ровно обратное, о чем еще ты хочешь поговорить?
Или можешь объяснишь нам как кеш помогает уменьшить чтение с диска если приходят разные запросы?
_>Угу, он динамический... Относительно той переменной. ))) Однако если ты посмотришь на итог, то окажется что из конкретного модуля у тебя будет исходить всегда один и тот же запрос.
Количество запросов, которое делает база — конечно. Но это тебе ничем не поможет. Даже в небольшом приложении будут тысячи запросов (если его оптимизировать). Без декомпозиции никуда.
Если нам не помогут, то мы тоже никого не пощадим.
Ты же понимаешь что в реальности так не бывает. Тебе прилетит 1000 разных запоров, а только 1001 будет повторять первый. При этом кеш первого уже вытеснен, а ОП для buffer pool стало меньше ровно на размер кешей и внезапно нужные страницы не в памяти, и ты попадаешь на физическое чтение.