ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
25 сообщений из 68, страница 1 из 3
  1  все
JPA vs JDBC для высоконагруженного приложения.
    #37862299
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
Возможно боян.
Возможно это из-за моего небольшого опыта с Java EE технологиями.
Чур ногами не бить.))

Хочу понять. Почему такая большая разница для операции INSERT между JPA и JDBC ?
Последняя выигрывает в 200 раз по скорости.


Дано: Объект из 3 полей - число(ПК) + дата + число
База: MySQL - InnoDB. табличка с автоинкрементом.

Тест такой ( он конечно тупой и в жизни именно так никто делать не будет, но хочу просто знать куда такие расходы):
Просто в цикле инсерчу 10000 объектов.
В JDBC сделал коннект и простым PrepareStatement в цикле прогнал insert.
В EJB в сервлете кидаю параметры в session bean и в нем менеджером делаю persists для нужного Entity. В сервлете тот же самый цикл.

Разница по скорости в 200раз. В пользу JDBC.

я понимаю что маппинг, контексты, менеджеры, датасорсы и т.п. берут на себя часть времени. Но неужели в такой пропорции? На
что именно такие расходы?

Как поведет себя такое EJB приложение в высоконагруженных проектах, например в интернете когда пользователями создается в минуту тысячи новых однотипных объектов.

За счет чего оно будет держать нагрузку при таких исходных данных.

Спасибо дрУги.
...
Рейтинг: 0 / 0
02.07.2012, 02:00:02
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862303
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
сервер glassfish 3

Еще интересно знать, а в Spring + Hibernate - также будет или там это решается лучше?
...
Рейтинг: 0 / 0
02.07.2012, 02:18:54
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862324
pavel_nv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavel_nv
Участник
В JDBC commit после каждой записи?
...
Рейтинг: 0 / 0
02.07.2012, 05:23:12
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862352
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
high load + sql?? No way!

гугли nosql
...
Рейтинг: 0 / 0
02.07.2012, 08:18:00
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862356
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Penkov Vladimirhigh load + sql?? No way!
гугли nosql
Отчеты на NoSQL писали когда-нибудь?
...
Рейтинг: 0 / 0
02.07.2012, 08:36:59
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862359
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
КореецРазница по скорости в 200раз. В пользу JDBC.

Создать транзакцию, вставить запись и закоммитить. Вот что у вас получается в JPA.
http://stackoverflow.com/questions/448181/batch-inserts-with-jpa-ejb3
почитайте про batch update
...
Рейтинг: 0 / 0
02.07.2012, 08:40:22
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862360
пролетевший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
пролетевший
Участник
pavel_nvВ JDBC commit после каждой записи?
+100.
По умолчанию, методы Session Bean транзакционные. Каждый вызов из сервлета открывает транзакцию, EntityManager сохраняет значение в базе и по выходу транзакция комиттится. Причем это XA транзакции, с поддержкой распределенных ресурсов. Правда, JDCB по умолчанию тоже каждый статемент оборачивает в транзакцию так что надо знать как соединение открывается ( есть ли auto commit ).
Еще вариант есть ли кеширование Prepared Statement в пуле соединений. Каждый вызов EJB будет брать новое соединение и создавать Prepared Statement для вставки. Если нет кеширования, тоже будут дополнительные расходы.
Накладные расходы на обертку EJB милисекунды, но они тоже есть. Для такой массовой вставки лучше делать пакетами. Если драйвер поддерживает batch update, то JPA может использовать его.
P.S. Если надо просто вставку в одну таблицу, то JDBC будет лучше. А вот если структура сложная, с кучей связанных даблиц, то orm имеет смысл.
...
Рейтинг: 0 / 0
02.07.2012, 08:40:46
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862414
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
pavel_nvВ JDBC commit после каждой записи?

нет. коммит один после всей пачки.
но пробовал и с автокоммитом - все равно jdbc быстрее на порядки.
...
Рейтинг: 0 / 0
02.07.2012, 09:50:35
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862416
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
Кореецpavel_nvВ JDBC commit после каждой записи?

но пробовал и с автокоммитом - все равно jdbc быстрее на порядки.


беру свои слова назад.

версия с автокоммитом тестилась не на 10000 записях, а вообще на одной. потом сразу убрал автокоммит. как-то спонтанно.

сейчас проверил с автокоммитом для 10000 скорость такая же как и у EJB.

Это радует)))

Спасибо!
...
Рейтинг: 0 / 0
02.07.2012, 09:55:12
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862418
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Кореецpavel_nvВ JDBC commit после каждой записи?
нет. коммит один после всей пачки.
но пробовал и с автокоммитом - все равно jdbc быстрее на порядки.
ну дак посмотри, что отправляется на сервер.
По любому, любой JPA реализацию надо тюнить и настраивать.
Нет волшебства в ОРМ.
...
Рейтинг: 0 / 0
02.07.2012, 09:56:56
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862419
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
Penkov Vladimir,

а JPA может работать с NoSQL?
...
Рейтинг: 0 / 0
02.07.2012, 09:57:59
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862424
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
Petro123ну дак посмотри, что отправляется на сервер.


а как это посмотреть?
есть стандартное средство трассировки того что отправляется в СУБД?

у меня же там просто em.persist(Объект)

придется нырять дебагером за Объектом?

кстати дебагер сходу вызвать не получилось. не становится на брекпойнт в сервлете даже когда запускают сервер в режиме debug
...
Рейтинг: 0 / 0
02.07.2012, 10:01:37
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862430
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GKS_Samara
Участник
Добрый день, Кореец!

>> ну дак посмотри, что отправляется на сервер.
> а как это посмотреть?

В persistence.xml допиши
Код: sql
1.
2.
3.
4.
    <properties>
      <property name="hibernate.show_sql" value="false"/>
      <property name="hibernate.use_sql_comments" value="true"/>
     ...



--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.07.2012, 10:10:24
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862431
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GKS_Samara
Участник
Добрый день!
>> ну дак посмотри, что отправляется на сервер.
> а как это посмотреть?
>
> В persistence.xml допиши
>
Код: sql
1.
2.
>     <properties>
>       <property name="hibernate.show_sql" value="false"/>


Блин! true, конечно. Выдернул из рабочего кода, где отключено (но готово
к включению)

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.07.2012, 10:11:37
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862601
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Корееца JPA может работать с NoSQL?
- пока нет, но на JavaOne сказали что EclipseLink движется в этом направлении. Возможно если в EclipseLink все получится внесут в спецификацию.
...
Рейтинг: 0 / 0
02.07.2012, 11:29:58
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862617
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ShSerge
Участник
Кореец,

По сабжу:
Сравнил ...у... с пальцем. :)
...
Рейтинг: 0 / 0
02.07.2012, 11:39:23
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862651
Фотография schwa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schwa
Участник
КореецPenkov Vladimir,

а JPA может работать с NoSQL?
С кассандрой может скорее всего т.к. у нее есть JDBC драйвер.
...
Рейтинг: 0 / 0
02.07.2012, 11:58:21
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862725
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
BlazkowiczPenkov Vladimirhigh load + sql?? No way!
гугли nosql
Отчеты на NoSQL писали когда-нибудь?
О, а можно подробнее? В скором времени предстоит.
...
Рейтинг: 0 / 0
02.07.2012, 12:33:38
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862737
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
ТимоНBlazkowiczОтчеты на NoSQL писали когда-нибудь?
О, а можно подробнее? В скором времени предстоит.
Могу лишь посочувствовать. NoSQL отлично подходит для ряда задач, где персистенс можно свести к хранилищу ключ-значение.
Но вот, к примеру, в ERP, где на десяток связаных таблиц приходится два десятка отчетов, эксплуатирующих ассоциации в совершенно разных и невероятных комбинациях, без SQL - никак.
...
Рейтинг: 0 / 0
02.07.2012, 12:38:49
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862765
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
BlazkowiczТимоНпропущено...

О, а можно подробнее? В скором времени предстоит.
Могу лишь посочувствовать. NoSQL отлично подходит для ряда задач, где персистенс можно свести к хранилищу ключ-значение.
Но вот, к примеру, в ERP, где на десяток связаных таблиц приходится два десятка отчетов, эксплуатирующих ассоциации в совершенно разных и невероятных комбинациях, без SQL - никак.
У меня богатый опыт построения отчетов запросами типа > 10 таблиц. Но в NoSQL ведь другая структура хранения данных, по идее не должно быть вообще join'ов. Может структура сущностей виновата?
...
Рейтинг: 0 / 0
02.07.2012, 12:50:27
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862820
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоНBlazkowiczпропущено...

Могу лишь посочувствовать. NoSQL отлично подходит для ряда задач, где персистенс можно свести к хранилищу ключ-значение.
Но вот, к примеру, в ERP, где на десяток связаных таблиц приходится два десятка отчетов, эксплуатирующих ассоциации в совершенно разных и невероятных комбинациях, без SQL - никак.
У меня богатый опыт построения отчетов запросами типа > 10 таблиц. Но в NoSQL ведь другая структура хранения данных, по идее не должно быть вообще join'ов. Может структура сущностей виновата?

наличие джойнов это не плохо а наоборот хорошо.

Простейший случай - файловая система.
Легко получить доступ к файлам по имени и пути в дереве.
Сделать выборку всех фалов с диска размером >10мб очень сложно, нужно лопатить весь диск. Хоть информация о размере файлов вполне себе хранится, быстрого доступа к ней нет.
...
Рейтинг: 0 / 0
02.07.2012, 13:15:27
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862870
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024наличие джойнов это не плохо а наоборот хорошо.

В NoSQL? Вы ничего не путаете?
...
Рейтинг: 0 / 0
02.07.2012, 13:32:34
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37862927
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
BlazkowiczPenkov Vladimirhigh load + sql?? No way!
гугли nosql
Отчеты на NoSQL писали когда-нибудь?

конечно. у нас пишется куча статы в самых разных разрезах с join-ом на sql БД
...
Рейтинг: 0 / 0
02.07.2012, 13:59:47
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863001
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024наличие джойнов это не плохо а наоборот хорошо.

В NoSQL? Вы ничего не путаете?

я говорю про разницу между нормальными скл-серверами и устаревшими ещё в 80-х но ставшими модными сейчас движками типа ноСКЛ.

Простая структура ноСКЛ является минусом а не плюсом. Подойдёт только в очень простых случаях работы с данными. Отчёты не являются простым случаем.
...
Рейтинг: 0 / 0
02.07.2012, 14:44:41
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863018
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024ТимоНпропущено...

В NoSQL? Вы ничего не путаете?

я говорю про разницу между нормальными скл-серверами и устаревшими ещё в 80-х но ставшими модными сейчас движками типа ноСКЛ.
Складывается ощущение что вы ошибаетесь. Вы серьезно думаете что это просто дань моде?

1024Простая структура ноСКЛ является минусом а не плюсом. Подойдёт только в очень простых случаях работы с данными. Отчёты не являются простым случаем.
От части с вами соглашусь, не все структуры можно и нужно переводить на NoSQL. Но есть задачи которые отлично ложатся в архитектуру NoSQL. Гемор с построением отчетов я вижу только в неправильном выборе архитектуры.
...
Рейтинг: 0 / 0
02.07.2012, 14:51:10
| Ответить | Цитировать | Написать  
25 сообщений из 68, страница 1 из 3
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=37862820&tid=2131428]:
 0ms
get settings:
 15ms
get forum list:
 25ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 41ms
get topic data:
 17ms
get forum data:
 4ms
get page messages:
 102ms
get tp. blocked users:
 2ms
others: 314ms
total:  530ms
созд. / загр.: 530ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]