Мы используем @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
?