Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения. / 25 сообщений из 68, страница 1 из 3
  1  все
02.07.2012, 02:00:02
    #37862299
Кореец
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
Возможно боян.
Возможно это из-за моего небольшого опыта с 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:18:54
    #37862303
Кореец
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
сервер glassfish 3

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

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

Создать транзакцию, вставить запись и закоммитить. Вот что у вас получается в JPA.
http://stackoverflow.com/questions/448181/batch-inserts-with-jpa-ejb3
почитайте про batch update
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.07.2012, 08:40:46
    #37862360
пролетевший
пролетевший
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
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, 09:50:35
    #37862414
Кореец
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
pavel_nvВ JDBC commit после каждой записи?

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

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


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

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

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

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

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

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


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

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

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

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

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

В 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:11:37
    #37862431
GKS_Samara
GKS_Samara
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
Добрый день!
>> ну дак посмотри, что отправляется на сервер.
> а как это посмотреть?
>
> В 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, 11:29:58
    #37862601
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
Корееца JPA может работать с NoSQL?
- пока нет, но на JavaOne сказали что EclipseLink движется в этом направлении. Возможно если в EclipseLink все получится внесут в спецификацию.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.07.2012, 11:39:23
    #37862617
ShSerge
ShSerge
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JPA vs JDBC для высоконагруженного приложения.
Кореец,

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

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

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

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

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

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

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

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

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

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

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

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

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

1024Простая структура ноСКЛ является минусом а не плюсом. Подойдёт только в очень простых случаях работы с данными. Отчёты не являются простым случаем.
От части с вами соглашусь, не все структуры можно и нужно переводить на NoSQL. Но есть задачи которые отлично ложатся в архитектуру NoSQL. Гемор с построением отчетов я вижу только в неправильном выборе архитектуры.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения. / 25 сообщений из 68, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 433ms
Закрыть
start [/forum/topic.php?fid=59&mobile=1&tid=2131428]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 34ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 290ms
total:  433ms
x
x
Закрыть


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