Что более дорого - вызов БД или новый звонок?

Question

Я отлаживаю дамп ядра процесса, и я хотел бы сделать изменение дизайна. Процесс C++ использует eSQL/C для подключения к базе данных informix.

В настоящее время приложение использует запрос, который извлекает из базы данных более 2lacs строк. Для каждой строки она создает динамическую память с использованием new и обрабатывает результат. Это приводит к ошибкам Out of memory, возможно, из-за встроенных утечек памяти.

Я имею в виду вариант, по которому я буду запрашивать только 500 строк из базы данных за раз, распределять динамическую память и обрабатывать ее. Как только он будет выделен, загрузите следующие 500 и так далее. Но это увеличило бы число запросов БД, хотя динамическая память, требуемая одновременно, уменьшилась.

Итак, мой вопрос в том, является ли эта опция масштабируемым решением. Может ли большее количество вызовов БД сделать приложение менее масштабируемым?

Answer 1

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

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

Answer 2

Зависит от запроса.

Ваш единственный вызов в данный момент занимает определенное количество времени, чтобы вернуть все 200 тыс. Строк. Предположим, что время пропорционально количеству строк в БД, назовите его n.

Если выяснится, что ваш новый, меньший вызов еще занимает время, пропорциональное количеству строк в БД, то ваша общая операция займет время, пропорциональное n^2 (потому что вы должны сделать n/500 звонки по стоимости n каждый). Это может быть не масштабируемо.

Итак, вы должны убедиться, что у вас есть нужные индексы в базе данных (или, скорее всего, убедитесь, что вы разделите строки на группы по 500 в соответствии с порядком некоторого поля, которое уже индексировано) так что меньшие вызовы требуют времени, примерно пропорционального количеству возвращаемых строк, а не количеству строк в БД. Тогда это может быть масштабируемо.

В любом случае, если у вас есть утечки памяти, тогда они являются ошибками, они не являются «неотъемлемыми», и их следует удалить!

Answer 3

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

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

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

Answer 4

Сначала укажите, есть ли у вас утечки памяти или нет, и исправьте их, если вы это сделаете.

Утечки памяти плохо масштабируются.

Вторичное распределение динамической памяти обычно намного быстрее, чем доступ к БД - за исключением случаев, когда вы выделяете много памяти и требуете увеличения кучи.

Если вы запрашиваете много (100k вверх строк) для выполнения обработки - во-первых, спросите себя , почему необходимо принести все эти - может SQL быть изменен, чтобы выполнить обработку на основе критериев - если вы уточните обработку, мы можем предоставить более подробные рекомендации о том, как это сделать.

Получение и обработка больших объемов данных требует надлежащей мысли, чтобы обеспечить ее масштабирование.