Проблема производительности Hibernate с отношениями OneToMany / nullable - PullRequest
1 голос
/ 06 февраля 2010

Мы используем @OneToMany для наших отношений Родитель-> Ребенок-> Ребенок-> Дочерняя БД:

@OneToMany(cascade = CascadeType.ALL)
@JoinColumn(name = "THE_ID", nullable = false )
private List<ChildClass> children = new ArrayList<ChildClass>();

У нас есть сценарий с большим количеством данных (100 тыс. Вставок), когда производительность при вставке ужасна (фактически истекает время ожидания). С небольшим количеством данных (1K вставок) у нас все хорошо.

Так что без всякой уважительной причины я удалил nullable = false и изменил внешний ключ БД в дочерних таблицах, чтобы разрешить нулевые значения и до того, как производительность будет довольно хорошей. Кто-нибудь может объяснить это?


Обновление : включена отладка. С nullable = false создается огромное узкое место, генерирующее идентификаторы для дочерних таблиц. Мы ожидаем, пока сгенерируются идентификаторы, с этим в журнале снова и снова:

[org.hibernate.event.def.AbstractSaveEventListener] [ ] generated identifier: <743088>, using strategy: org.hibernate.id.IncrementGenerator

Мы даже никогда не вставляем данные в БД. Мы просто застряли на идентификаторе. В настоящее время мы настраиваем Hibernate для генерации идентификаторов, просматривая значения максимального идентификатора, которые в настоящее время находятся в дочерней таблице:

@Id
@GeneratedValue(generator = "DummyString")
@GenericGenerator(name = "DummyString", strategy = "increment")
@Column(name = "THE_ID", nullable = false)
private Long id;

До этого мы использовали последовательность БД и видели те же проблемы.

Когда мы опускаем nullable = false, мы видим эти операторы ID gen (108K из них), но они завершаются за 25 секунд. Так почему же эти утверждения (в буквальном смысле) навсегда связаны с nullable = false?

Ответы [ 2 ]

1 голос
/ 06 февраля 2010

Вам нужен Каскад? Все дочерние объекты обновляются на вставках?

0 голосов
/ 06 февраля 2010

Вуду? Узнайте, как выполнить трассировку Oracle. Ваш администратор базы данных должен помочь.

С помощью файла трассировки вы можете посмотреть события ожидания Oracle. Это расскажет вам, что делала база данных, когда «производительность ужасна». Это может быть ожидание на замке, это может быть чтение таблицы ....

Когда вы знаете, почему это медленно, решение часто становится очевидным.

Я рекомендую этот технический документ в качестве инструкции для разработчиков по работе с базами данных.

...