Когда является более дорогим размер вызова базы данных, чем частота вызовов?

Unless there is a big performance problem (e.g. a highly latent db connection), I'd stick with leaving the data in the database and letting the db take care of things for you. A lot of things are done efficiently on the database level, for example

• isolation levels (what happens if other transactions update the data you're caching)
• fast access using indexes (the db may be quicker to access a few rows than you searching through your cached items, especially if that data already is in the db cache like in your scenario)
• updates in your transaction to the cached data (do you want to deal with updating your cached data as well or do you "refresh" everything from the db)

There are a lot of potential issues you may run into if you do your own caching. You need to have a very good performance reason befor starting to take care of all that complexity.

So, the short answer: It depends, but unless you have some good reasons, this smells like premature optimizaton to me.

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

Но посмотрите на ширину вашей сетевой шины (бит / сек) и сравните это со средним временем прохождения туда и обратно для вызова базы данных ...

Например, в сети 100baseT ваш размер составляет около 12 МБ. скорость передачи данных в секунду. Если ваше среднее время приема-передачи составляет, скажем, 200 мс, то ваша сетевая шина может доставить 3 Мбайта за каждый 200-миллисекундный вызов в оба конца.

Если вы используете гигабитный Ethernet, это число возрастает до 30 Мбайт за круговой обход. ..

Итак, если вы разделите запрос данных на два приема-передачи, это будет 400 мс,

"I guess I'm not really giving you one answer to your question. "It depends" is the best I can do."

yes, "it depends". It depends on the volatility of the data that you are intending to cache, and it depends on the level of "accuracy" and reliability that you need for the responses that you generate from the data that you intend to cache.

If volatility on your "base" data is low, then any caching you do on those data has a higher probability of remaining valid and correct for a longer time.

If "caching-fault-tolerance" on the results you return to your users is zero percent, you have no option.

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

• Если у вас есть веб-приложение .Net, которое кэширует данные в клиенте, вы не хотите извлекать 2k строк.

• Если у вас есть веб-сервис, они почти всегда лучше Chunky, чем Chatty, из-за дополнительных накладных расходов XML на транспорт.

• В достаточно прилично нормализованной и оптимизированной базе данных действительно должно быть очень мало раз, когда вам нужно вытаскивать 2k строк за раз, если только вы не создание отчетов.

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

• Отчеты ( любой DSS) будет обрабатывать гораздо большие наборы данных, но поскольку они не интерактивны, мы денормализуем их и позволяем им повеселиться.

• В случаях каскадных выпадающих списков и тому подобного методы AJAX окажутся более эффективными и действенными.

Думаю, я не могу дать вам один ответ на ваш вопрос. «Это зависит от обстоятельств» - лучшее, что я могу сделать.

Тип возвращаемых вами данных также влияет на решение. Вы не хотите кэшировать изменчивые данные или данные для потенциальных обновлений, которые могут устареть.

Это, вероятно, варьируется от РСУБД к РСУБД, но мой опыт показывает, что массовое извлечение почти всегда лучше. В конце концов, вам все равно придется вытащить 2000 записей, так что вы можете сделать все сразу. И 2000 записей на самом деле не очень много, но это во многом зависит от того, что вы делаете.

Мой совет - профилируйтесь и посмотрите, что работает лучше всего. РСУБД могут быть непростыми задачами с точки зрения производительности, и кэширование может быть таким же сложным.