Количество соединений с БД против потоков Java

Question

В настоящее время я разрабатываю Java-приложение, которое сравнивает данные таблиц, представленные в 2 разных базах данных.

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

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

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

В настоящее время мое приложение порождает один поток (из пула потоков) на одну таблицу, и он устанавливает 2 разных соединения БД с 2 разными базами данных (пока последовательно), и как только данные извлекаются, тот же поток вызывает метод, который сравниваетданные.

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

1. Если у меня больше потоков, чем N, будет ли это полезно для моего варианта использования?если да, то как?
2. Какой здесь ограничивающий фактор - количество ядер или нет.соединений?
3. Полезно ли иметь больше потоков, чем M?

Answer 1

N - нет. ядер и М макс нет. соединений БД БД может принимать

1. Если у меня больше потоков, чем N, будет ли это полезно для моего варианта использования? если да, то как?
2. Какой здесь ограничивающий фактор - количество ядер или нет. соединений?
3. Полезно ли иметь больше потоков, чем М?

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

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

3. Наличие большего количества потоков, чем максимальное количество соединений, может принести небольшую выгоду, если вы уверены, что: а) получите соединение из пула соединений, б) прочитаете все данные в, в) отпустите соединение обратно пул, а затем г) сделать сравнение данных. Это потому, что когда один поток сравнивает данные, другой поток может использовать это соединение для чтения данных. Однако сравнение данных звучит как довольно простая и быстрая работа, поэтому выгода не будет такой большой: ваш поток выполнит сравнительное сравнение данных довольно быстро, после чего он захочет получить другое соединение из пула, на котором указать, что он будет заблокирован, если все соединения используются.

С учетом вышесказанного, я надеюсь, что вы знаете о том факте, что существуют инструменты, даже бесплатные, которые будут выполнять такие сравнения для вас. Ищите «Сравнение SQL». (Я знаю, что это неправильно, инструменты не сравнивают SQL, они сравнивают базы данных, и они используют SQL для запроса баз данных, которые они сравнивают; я не придумала название, создатели этих инструментов сделали. )

Answer 2

Простой ответ на ваши вопросы - «это зависит»; т.е. нет простого ответа или волшебной формулы.

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

Предположим (ради аргумента), что запросы независимы; то есть один запрос не блокирует ресурс, от которого зависит другой.

Теперь, если ваша рабочая нагрузка достаточно мала (в зависимости от самих запросов и количества потоков на стороне клиента), то отдельные шаги каждого запроса будут потреблять все больше и больше (соответствующих) ресурсов (ЦП, ввод-вывод). пропускная способность). Вы можете продолжать увеличивать количество потоков на стороне клиента, но в какой-то момент один из ресурсов, вероятно, будет чрезмерно выделен ... и вы столкнетесь с узким местом. Как только вы достигнете этой точки, увеличение количества клиентских потоков не делает вещи быстрее. Зайдите слишком далеко, и пропускная способность может фактически начать падать из-за различных эффектов конфликта ресурсов.

В: Можем ли мы предсказать, каким будет предел пропускной способности?

A: Не без глубокого анализа всей системы и рабочей нагрузки, что ... не практично.

В: Можем ли мы предсказать, каким будет узкое место?

A: Не без глубокого анализа всей системы и рабочей нагрузки, что ... не практично.

В: Можем ли мы определить оптимальное количество потоков на стороне клиента для заданного количества ядер на стороне клиента.

A: Не без знания ответов на два предыдущих вопроса.

---

В: Так каков практический способ решения этой головоломки о том, как определить размер пула потоков?

A: Бенчмаркинг и настройка!

Определите, какова ваша реальная рабочая нагрузка, создайте ориентировочный эталонный тест (или отнеситесь к своей рабочей нагрузке как эталонный) и запускайте его многократно, регулируя количество потоков на стороне клиента вверх или вниз. В то же время измерьте фактическую загрузку ЦП и В / В на клиенте и в базе данных, чтобы попытаться определить, где находится фактическое узкое место в ресурсах. Эти меры могут быть полезны для других видов настройки (например, оптимизация базы данных и запросов, настройка сети) и для принятия решения о том, требуется ли вам больше оборудования, более быстрые сетевые интерфейсы и т. Д.

Если вы берете «тест и настройку», вам не нужен точный прогноз количества потоков.