База данни JDBC, използваща многоядрени спрямо ниво на изолация

здравей

Искам да получа данни в база данни на многоядрена система с ative 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, но същото ще важи, ако не поддържат необходимите нива на изолация. Базата данни може автоматично да надстрои нивото на изолация до по-високо ниво, за да отговори на желаните характеристики на изолация. Трябва да преосмислите този подход, ако желаното ниво на изолация на вашето приложение трябва да бъде Повторяемо четене.

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

person Vineet Reynolds    schedule 14.06.2011
comment
Това, което Oracle нарича Serializable, всъщност е Snapshot isolation или греша? Не мисля, че никоя от тези бази данни има истински Serializable. - person Franz Kafka; 14.06.2011
comment
Това е изолация на моментна снимка, тъй като SCNs (номера за промяна на системата) по време на четене/актуализация се сравняват с тези в началото на транзакцията. Ако открие промяна, извежда грешката 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

Мисля, че ограничаващият фактор тук ще бъде дисковият IO, а не режийните разходи за преминаване към повторяемо четене.

Дори една нишка може да успее да увеличи максимално дисковете на DB сървъра, особено с количеството регистриране в DB, ​​необходимо при вмъкване/актуализация. Сигурен ли си, че това вече не е така?

Също така, във всяка многопотребителска система вероятно искате да работите с изолация за повтарящо се четене (Postgres поддържа само това и може да бъде сериализирано). Така че не мисля за това като за добавяне на някакви "режийни разходи" над това, което обикновено бих видял.

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