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

Привет,

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

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

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

1.) Является ли этот анализ наборов записи дорогим?

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


multithreading database performance jdbc isolation-level
person Franz Kafka    schedule 14.06.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Vineet Reynolds    schedule 14.06.2011
comment
То, что Oracle называет Serializable, на самом деле является Snapshot isolation, или я ошибаюсь? Я не думаю, что какая-либо из этих баз данных имеет настоящие Serializable. - person Franz Kafka; 14.06.2011
comment
Это изоляция снимка в том смысле, что номера SCN (номера системных изменений) во время чтения/обновления сравниваются с номером в начале транзакции. Если он обнаруживает изменение, он выдает ошибку ORA-08177. - person Vineet Reynolds; 14.06.2011
comment
Хорошо, для моей многопоточной системы мне понадобится Orcales Serializable. Будет ли это все еще дешевле, чем одна нить? - person Franz Kafka; 14.06.2011
comment
Не могу сказать с моего кресла :) Вы должны профилировать это, так как в любом случае это будет точка доступа к производительности. - person Vineet Reynolds; 14.06.2011

arrow_upward
1
arrow_downward

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

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

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

person AngerClown    schedule 14.06.2011
comment
Сервер будет масштабирован для обработки WAL, данные могут оставаться в памяти (надеюсь). Интервал между контрольными точками будет установлен очень большим, чтобы WAL мог самостоятельно использовать диск. - person Franz Kafka; 14.06.2011