Любой способ заставить JPA сохранять объекты быстрее? - PullRequest
Новая
       4

Любой способ заставить JPA сохранять объекты быстрее?

0 голосов
/ 02 февраля 2020

с использованием JPA, Hibernate / MVC / Servlets, я пытаюсь загрузить файл .csv в свою базу данных. Файл имеет длину 90 КБ + строки. То, что мне удалось получить, это загрузить .csv с сервлетом, прочитать каждую строку и разбить строки, чтобы вставить в виде столбцов. В то время как я oop я создаю EntityManager, вставляю данные в новый объект, сохраняю и фиксирую. Я работаю, но прошло около 5 часов, чтобы пройти через все данные. Я могу что-нибудь изменить? Я относительно новичок в программировании. Вот мой код: 

Scanner s = new Scanner(myCSVasInputStream).useDelimiter("\\n");
while(s.hasNext()) {
try{
EntityManager em = JPAUtils.createEntityManager();
em.getTransaction().begin();
String row = s.next();
String[] column = row.split(;);
myEntity m = new myEntity();
m.setValue(column[0]);
em.persist(m);
em.getTransaction().commit();
} catch (Excepltion e) {
system.out.print("I think i need to catch exception for duplicate rows");
}
}

1 Ответ

0 голосов
/ 02 февраля 2020

Даже старые компьютеры 2010 года с жестким диском легко вставляют 1000 строк в секунду c. Но вы должны избегать плохого программного обеспечения / алгоритмов.

контрольный список:

a) дважды проверьте настройку БД. Например, режим разработки mysql - это дрянная ссылка на реальный сервер. Она имеет крошечные буферы, пулы и т. Д. c ... Виртуальная машина linux импортирует mysqldump в 10 раз быстрее windows ... просто в качестве примера ... Подготовьте сервер к тяжелой работе.

b) если бы вы поместили @Transactional на все, возможно, вы бы проходили много java стековых фреймов для каждой строки. Проверьте, ограничены ли вы процессором. Вы должны быть нормально связаны для такой вставки. Здесь вы делаете TXN для каждой строки ...

c) также не пытайтесь выполнить одну транзакцию из 90000 строк, это просто глупо. Я знаю, что нет, так держать. Возможно, просто полностью избегайте TXN, так как я не вижу выгоды для вашего случая.

Если вы можете избежать спящего режима, у вас есть несколько вариантов:

d) явно подготовленная на стороне сервера выписка предпочтительнее.

e) поверх подготовленного выписки используйте пакетное выражение (для начала можно набрать 20-100 раз, найдите подходящее место).

f) если вы действительно не унывая, и никто на вашем пути не будет жаловаться на то, что они не понимают, и блокирует ваш запрос на получение доступа в проклятом обзоре кода (!), вы можете mysql читать CSV напрямую, с готовой загрузкой файлы (ЗАГРУЗКА ДАННЫХ INFLE https://dev.mysql.com/doc/refman/8.0/en/load-data.html). У Postgress есть нечто эквивалентное. Большинство поставщиков должны. Как правило, вам придется хранить готовый файл CSV (правильные разделители и кавычки) на самом сервере БД, так что это, возможно, даже невозможно на удаленных БД. Но это удивительно быстро. Для этого почти стоит поставить микросервис загрузки файлов на экземпляр БД.

Надеюсь, это поможет.

...