Как влияет удаление @GeneratedValue из идентификатора на производительность - PullRequest
Новая
       11

Как влияет удаление @GeneratedValue из идентификатора на производительность

0 голосов
/ 05 июня 2018

Я работаю над RCP-приложением, которое связывается с Tomcat-сервером, используя Rest.Поскольку мы получаем все больше и больше данных, процедуры загрузки / копирования медленно, но безнадежно устаревают.Иногда мне требуется несколько минут, чтобы выполнить какую-либо операцию копирования.Поэтому я ищу несколько советов, как ускорить мои процедуры.

Вот технологии, которые я использую:

  1. RCP-Client (e4-plattform)
  2. Tomcat8-Server
  3. Oracle-DB
  4. JDBC как API с Hibernate
  5. Rest

Первым делом первым.Я проверил сущности, и почти все они выглядят как код, приведенный ниже 

@Entity
@SequenceGenerator(name = "CHECKITEM_SEQ", sequenceName = "CHECKITEM_SEQ", allocationSize = 1)
public class CheckItem extends AbstractTreeNode implements Serializable,Cloneable {...}

Я вычислил путем копирования данных (которые в большинстве случаев превышают 200 КБ на операцию), поскольку я использую их в качестве первичного ключа, 

@Id
@GeneratedValue(generator = "CHECKITEM_SEQ", strategy = GenerationType.SEQUENCE)
    public Integer getId() {
        return id;
    }

БД должна генерировать для каждого объекта последовательность и проверять ограничение на нее, поэтому мне было интересно, какую производительность я получу, если уберу последовательность, поскольку я действительно не использую / не нуждаюсь в них вDB.Теперь мои вопросы:

  1. Есть что-нибудь, что говорит против удаления ограничения (первичного ключа в данном конкретном случае) в БД?
  2. Есть ли у кого-нибудь еще / лучшие предложения, как повысить производительностьБД для таких операций?
  3. Могу ли я иметь учебник или документ, который может помочь мне в этом процессе?

Надеюсь, я был достаточно ясен, и я буду признателен за любой видпомощиуже спасибо.

1 Ответ

0 голосов
/ 05 июня 2018

Проблема с использованием идентификаторов @GeneratedValue заключается в том, что для того, чтобы Hibernate поместил новый объект в контекст постоянства (кэш первого уровня), он должен знать идентификатор.Поэтому, когда вы используете идентификаторы на основе IDENTITY или SEQUENCE, это может повлиять на способность драйвера JDBC адекватно пакетировать операции вставки.

Например, вы показали, что большинство ваших сущностей используют следующеегенерация последовательности: 

@SequenceGenerator(
   name = "CHECKITEM_SEQ", 
   sequenceName = "CHECKITEM_SEQ", 
   allocationSize = 1)

Таким образом, когда бы ни происходила постоянная операция для объекта, вы указываете генератору последовательности генерировать только одно значение, поэтому связь JDBC выглядит следующим образом: 

1. Get Next Sequence
2. Insert
3. Get Next Sequence
4. Insert
5. Get Next Sequence
6. Insert

Как видно здесь, мы не можем пакетировать операции вставки, потому что мы должны извлечь идентификатор для каждой операции вставки, прежде чем операция вставки может произойти.Одним из решений, позволяющих минимизировать это влияние и справиться с пакетными вставками, является использование большего allocationSize. 

1. allocationSize=10 -> Get Next 10 sequences
2 - 11. Perform 10 inserts in batch
Repeat

. Как вы видите, драйвер может выполнить 10 вставок в пакете, Hibernate распределяет последовательности в пакетахна 10 и так вставки могут происходить намного быстрее.

Очевидно, что это имеет небольшой недостаток, если вы выделяете 10 последовательностей, но оставшемуся пакету нужно только вставить 6 сущностей;вы потратили 4 значения последовательности, но вы получаете производительность благодаря возможности выполнения пакетных вставок jdbc.

Следующим логическим шагом будет определение того, можете ли вы исключить использование @GeneratedValue все вместе какэто дало бы вам максимальную производительность с пакетными вставками для ваших операций копирования;однако это может быть невозможно с вашей моделью данных.В прошлом, когда я имел дело с перемещением больших объемов данных, я пытался определить первичный ключ на основе естественных ключей из данных, не используя суррогатный ключ, если это возможно.

Не стесняйтесь читать больше о пакетных операциях JDBC здесь .

...