Будет ли быстрее использовать несколько потоков для обновления одной и той же базы данных?
Я написал программу на Java для добавления и извлечения данных из MS Access. В настоящее время он последовательно выполняет ~ 200K запросов на вставку за ~ 3 минуты, что я считаю медленным. Я планирую переписать его, используя потоки с 3-4 потоками, обрабатывающими разные части из сотен тысяч записей. У меня сложный вопрос:
Поможет ли это ускорить выполнение программы из-за разделения рабочей нагрузки или будет так же, потому что потокам по-прежнему придется обращаться к базе данных последовательно?
Как вы думаете, какая стратегия ускорит этот процесс (кроме оптимизации запросов, которую я уже сделал в дополнение к использованию подготовленного состояния Java)
Ответы 8
Не знаю. Не зная больше о том, что такое горлышко бутылки, я не могу прокомментировать, ускорит ли оно его. Если база данных является ограничителем, то есть вероятность, что большее количество потоков замедлит ее.
Я бы сбросил базу данных доступа в плоский файл, а затем загрузил бы этот файл массово. Массовая загрузка позволяет выполнять оптимизацию, которая намного быстрее, чем выполнение нескольких запросов на вставку.
На современных многоядерных машинах использование нескольких потоков для заполнения базы данных может иметь значение. Это зависит от базы данных и ее оборудования. Попробуйте и убедитесь.
Используя MSAccess в качестве серверной базы данных, вы, вероятно, получите лучшую производительность при вставке, если будете выполнять импорт из MSAccess. Другой вариант (поскольку вы используете Java) - напрямую манипулировать файлом MDB (если вы создаете его с нуля и нет других одновременных пользователей, что MS Access не очень хорошо обрабатывает) с помощью такой библиотеки, как Джекесс.
Если ни одно из этих решений для вас не подходит, я бы рекомендовал использовать профилировщик в вашем приложении Java и посмотреть, тратит ли оно большую часть своего времени на ожидание базы данных (в этом случае добавление потоков, вероятно, не поможет) или если он выполняет обработку, и распараллеливание поможет.
Просто попробуйте и посмотрите, поможет ли это. Я бы предположил, что нет, потому что узкое место, вероятно, будет в доступе к диску и блокировке таблиц, если вы не сможете найти способ разделить нагрузку на несколько таблиц и / или дисков.
Подход с массовой загрузкой Stimms, вероятно, будет вашим лучшим выбором, но все стоит попробовать один раз. Обратите внимание, что ваше бутылочное горлышко будет дисковым вводом-выводом, и несколько потоков могут замедлить работу. Доступ MS также может развалиться, когда несколько пользователей работают с файлом, и именно так будет действовать ваш многопоточный подход (сделайте резервную копию!). Если производительность продолжает оставаться проблемой, рассмотрите возможность обновления до SQL экспресс.
Документы MS Access to SQL Server Migrations.
Удачи.
Во-первых, не используйте Access. Переместите свои данные куда-нибудь еще - SQL / Server - MySQL - что угодно. Механизм доступа к БД (называемый Jet) очень медленный. Это не настоящая база данных; это для личных проектов, требующих небольших объемов данных. Он вообще не масштабируется.
Во-вторых, потоки помогают редко.
Соединение JDBC с базой данных - это ресурс всего процесса. Все потоки используют одно соединение.
«Но подождите, - скажете вы, - я создам уникальный объект Connection в каждом потоке».
Благородно, но иногда обречено на провал. Почему? Обработка операционной системы между вашей JVM и базой данных может включать сокет, который представляет собой единый ресурс всего процесса, совместно используемый всеми вашими потоками.
Если у вас есть один ресурс ввода-вывода на уровне ОС, который используется всеми потоками, вы не увидите значительных улучшений. В этом случае соединение ODBC является одним из узких мест. Другое дело - MS-Access.
Я согласен, что сброс Access будет лучшим первым шагом. Было сказано, что...
В среде .NET и SQL я определенно видел, как потоки помогают максимизировать пропускную способность INSERT.
У меня есть приложение, которое принимает асинхронные файлы, а затем обрабатывает их в таблицы в базе данных.
Я создал загрузчик, который проанализировал файл и поместил данные в очередь. Очередь обслуживалась одним или несколькими потоками, максимум которых я мог настроить с помощью параметра. Я обнаружил, что даже на одноядерном процессоре с вашим типичным диском 7200 об / мин идеальное количество рабочих потоков было 3. Это сократило время загрузки почти пропорционально. Ключ состоит в том, чтобы сбалансировать это так, чтобы узкие места ЦП и узкие места ввода-вывода были сбалансированы.
Поэтому в случаях, когда массовое копирование невозможно, следует рассмотреть возможность использования потоков.
Доступ IIRC не допускает множественных подключений к одному и тому же файлу из-за политики блокировки, которую он использует.
И я полностью согласен с демпингом доступа для sql.