JDBC базы данных с использованием многоядерных и уровней изоляции

Question

Алло,

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

Если приложение имеет несколько потоков, мне придется повысить уровень изоляции до Repeatable Read, который в базах данных MVCC должен быть сопоставлен с Snapshot isolation.

Если бы я использовал один поток, мне бы не понадобились уровни изоляции. Насколько мне известно, большинство Snapshot isolation баз данных анализируют наборы записи всех транзакций, которые могут иметь конфликт, а затем откатывают все, кроме одной из реальных конфликтных транзакций. Более конкретно я говорю об Oracle, InnoDB и PostgreSQL.

1.) Дорогой ли это анализ наборов записи?

2.) Является ли хорошей идеей многопоточность вставок для повышения общей пропускной способности? Реальный конфликт практически невозможен из-за того, что прикладной уровень обеспечивает потоки бесконфликтных вещей. Но база данных должна быть сетью безопасности.

Answer 1

Oracle не поддерживает Repeatable Read. Он поддерживает только Read Committed и Serializable. Я могу ошибаться, но установка уровня изоляции Repeatable Read для Oracle может привести к транзакции с уровнем изоляции Serializable. Короче говоря, вы оставлены на произвол судьбы поддержки баз данных для желаемых уровней изоляции.

Я не могу говорить за InnoDB и PostgreSQL, но то же самое применимо, если они не поддерживают требуемые уровни изоляции. База данных может автоматически обновить уровень изоляции до более высокого уровня, чтобы соответствовать требуемым характеристикам изоляции. Вы должны переосмыслить этот подход, если желаемый уровень изоляции вашего приложения должен быть Repeatable Read.

Проблема, которую вы правильно поняли, заключается в том, что оптимистическая блокировка может привести к откатам транзакций в случае обнаружения конфликта. Oracle делает это, сообщая об ошибке ORA-08177 SQL. Поскольку эта ошибка сообщается, когда два потока будут обращаться к одному и тому же диапазону данных , ее можно было бы избежать, если бы потоки работали с наборами данных, включающими различные диапазоны данных . При распределении работы между потоками вам нужно убедиться, что это так.

Answer 2

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

Даже один поток может быть в состоянии максимально использовать диски на сервере БД, особенно с количествомРегистрация БД требуется при вставке / обновлении.Вы уверены, что это еще не так?

Кроме того, в любой многопользовательской системе вы, вероятно, все равно захотите работать с изоляцией Repeatable Read (Postgres поддерживает только это и сериализует).Поэтому я не думаю, что это добавление каких-либо «накладных расходов» сверх того, что я обычно вижу.