Подсказки относительно Ускорения записей JDBC?
Для объектов неизменяемых значений, таких как int, строки или даты, идентификация объекта не особенно полезна. Лучше думать о равенстве. Идентификация - это, по сути, деталь реализации объектов значения - поскольку они неизменяемы, нет эффективной разницы между наличием нескольких ссылок на один и тот же объект или несколько объектов.
4 ответа
Это - проблема, что я должен был иметь дело с часто на моем текущем проекте. Для нашего приложения вставьте скорость, критическое узкое место. Однако мы обнаружили для подавляющего большинства пользователей базы данных, избранная скорость как их главное узкое место, таким образом, Вы найдете, что существует больше ресурсов, занимающихся той проблемой.
, Таким образом, вот несколько решений, которые мы предложили:
Первый, все решения включают использование пост-ГРЭС команда COPY. Используя КОПИЮ для импорта данных в пост-ГРЭС безусловно самый быстрый доступный метод. Однако драйвер JDBC по умолчанию в настоящее время не поддерживает КОПИЮ через сетевой сокет. Так, если Вы захотите использовать его, то необходимо будет сделать одно из двух обходных решений:
- А драйвер JDBC, исправленный для поддержки КОПИИ, такой как этот один .
- , Если данные Вы вставляете и база данных находится на той же реальной машине, можно выписать данные в файл в файловой системе и затем использовать команду COPY для импорта данных оптом.
Другие опции для увеличения скорости используют JNI для удара API пост-ГРЭС, таким образом, можно обсудить сокет Unix, удалив индексы и pg_bulkload проект . Однако в конце, если Вы не реализуете КОПИЮ, Вы будете всегда находить производительность неутешительной.
Проверьте, установлено ли Ваше соединение автоматически фиксировать. Если автоматическая фиксация будет верна, то, если у Вас есть 100 объектов в пакете при вызове executeBatch он выпустит 100 отдельных фиксаций. Это может быть намного медленнее, чем вызов executingBatch () сопровождаемый единственной явной фиксацией ().
я избежал бы искушения отбросить индексы или внешние ключи во время вставки. Это помещает таблицу в неприменимое состояние, в то время как Ваша загрузка работает, так как никто не может запросить таблицу, в то время как индексов не стало. Плюс, кажется достаточно безопасным, но что Вы делаете, когда Вы пытаетесь повторно включить ограничение, и это перестало работать, потому что что-то, Вы не ожидали происходить, произошло? RDBMS имеет ограничения целостности по причине, и отключение их даже "на некоторое время" опасно.
Можно, очевидно, попытаться изменить размер пакета для нахождения лучшего размера для конфигурации, но я сомневаюсь, что Вы получите фактор 3.
Вы могли также попытаться настроить свою структуру базы данных. У Вас могли бы быть лучшие действия при использовании единственного поля в качестве первичного ключа, чем использование составленного PK. В зависимости от уровня целостности Вам нужно, Вы могли бы сэкономить некоторое время путем деактивации проверок целостности на DB.
Вы могли бы также изменить базу данных, которую Вы используете. MySQL, как предполагается, довольно хорош для высокоскоростных простых вставок..., и я знаю, что существует ветвление MySQL вокруг этого, пытается сократить технические возможности для получения очень высоких производительностей на очень параллельном доступе.
Удачи!
попытайтесь отключить индексы и повторно включить им после вставки. также, перенесите целый процесс в транзакцию