ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
68 сообщений из 68, показаны все 3 страниц
  все  
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
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863029
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024пропущено...


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



это не дань моде. Это очередные грабли. SQL слишком сложен для большинства, в результате модными стали простейшие структуры данных а вся мощь SQL отброшена. Типа десяток сджойненных таблиц в запросе который сам соптимизирует и выполнит мгновенно это хуже чем самому городить сбор данных по убогим наборам ключ-значение и пытаться добиться производительности над которой в Oracle работали десятки лет.
...
Рейтинг: 0 / 0
02.07.2012, 14:55:31
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863058
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024это не дань моде. Это очередные грабли. SQL слишком сложен для большинства, в результате модными стали простейшие структуры данных а вся мощь SQL отброшена. Типа десяток сджойненных таблиц в запросе который сам соптимизирует и выполнит мгновенно это хуже чем самому городить сбор данных по убогим наборам ключ-значение и пытаться добиться производительности над которой в Oracle работали десятки лет.
У вас есть опыт работы с NoSQL?
...
Рейтинг: 0 / 0
02.07.2012, 15:11:51
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863065
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024это не дань моде. Это очередные грабли. SQL слишком сложен для большинства, в результате модными стали простейшие структуры данных а вся мощь SQL отброшена. Типа десяток сджойненных таблиц в запросе который сам соптимизирует и выполнит мгновенно это хуже чем самому городить сбор данных по убогим наборам ключ-значение и пытаться добиться производительности над которой в Oracle работали десятки лет.
У вас есть опыт работы с NoSQL?

есть. Я старенький.
...
Рейтинг: 0 / 0
02.07.2012, 15:16:19
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863076
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024ТимоНпропущено...

У вас есть опыт работы с NoSQL?

есть. Я старенький.
А с чем именно?
...
Рейтинг: 0 / 0
02.07.2012, 15:23:04
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863080
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024пропущено...


есть. Я старенький.
А с чем именно?

с разными. Не мало ли у тебя постов для экзаменов? Шутка.
...
Рейтинг: 0 / 0
02.07.2012, 15:26:07
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863096
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024с разными.
А что именно вам не понравилось в NoSQL БД которые вы использовали?
1024Не мало ли у тебя постов для экзаменов? Шутка.
До вас конечно далеко, я больше для обмена опытом интересуюсь )
...
Рейтинг: 0 / 0
02.07.2012, 15:35:02
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863109
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024с разными.
А что именно вам не понравилось в NoSQL БД которые вы использовали?

см. 12803536
...
Рейтинг: 0 / 0
02.07.2012, 15:43:53
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863118
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024ТимоНпропущено...

А что именно вам не понравилось в NoSQL БД которые вы использовали?

см. 12803536
Ок, и как JOIN упростит выборку? А что если размер файла хранить в описании файла?
...
Рейтинг: 0 / 0
02.07.2012, 15:46:54
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863220
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
ТимоН1024пропущено...


см. 12803536
Ок, и как JOIN упростит выборку? А что если размер файла хранить в описании файла?

джойн никак не упростит выборку.

Выборку упростит движок скл сервера который по джойнам построит оптимизированный запрос к нормализованным данным. Что такое нормализация можно посмотреть в вики.
...
Рейтинг: 0 / 0
02.07.2012, 16:23:57
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863221
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ShSerge
Участник
ТимоН...как JOIN упростит выборку?...
Джойн не упрощает выборку - это и есть выборка.
...
Рейтинг: 0 / 0
02.07.2012, 16:23:59
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863229
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ТимоНА что если размер файла хранить в описании файла?
ну ясен пень. Будем Модель подгонять под Выборку ))))
...
Рейтинг: 0 / 0
02.07.2012, 16:26:58
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863234
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ShSerge
Участник
За последний десяток лет, не написал ни одного селекта с меньше, чем тремя приджойненными таблицами. Исключая, ясен перец, справочник полов - Мужской(М), Женский(Ж), Неопределённый(Н). Кстати, последний иногда тоже имеет место быть.
...
Рейтинг: 0 / 0
02.07.2012, 16:28:13
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863237
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
Petro123ТимоНА что если размер файла хранить в описании файла?
ну ясен пень. Будем Модель подгонять под Выборку ))))
А что в этом плохого? Разве размер файла не может быть полем сущности?
...
Рейтинг: 0 / 0
02.07.2012, 16:29:04
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863250
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
1024джойн никак не упростит выборку.

Выборку упростит движок скл сервера который по джойнам построит оптимизированный запрос к нормализованным данным. Что такое нормализация можно посмотреть в вики.

Если честно, не до конца понял пример про файловую систему. Объясните что вы имели ввиду?
...
Рейтинг: 0 / 0
02.07.2012, 16:33:25
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863267
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ТимоННо в NoSQL ведь другая структура хранения данных, по идее не должно быть вообще join'ов. Может структура сущностей виновата?
ну ведь известно, что ОРМ или объектная модель хороша для CRUD систем.
А РСУБД успешно делает соединения множеств\кортежей.
JOIN это соединения.
Без него, в ООБД - прямая точечная нотация....
Ну не катит она в сложных выборках. Что тут спорить?
...
Рейтинг: 0 / 0
02.07.2012, 16:42:16
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863273
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
Petro123Ну не катит она в сложных выборках. Что тут спорить?
Я и не спорил, наоборот я говорил что не для всех задач можно использовать NoSQL. Спор пошел дальше, "NoSQL в общем - зло". С этим я не согласен.
...
Рейтинг: 0 / 0
02.07.2012, 16:45:00
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863302
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
ТимоНСпор пошел дальше, "NoSQL в общем - зло". С этим я не согласен.
Про "зло", вроде, никто не писал. А то что это "дань моде", то это правда. Сначала общественность для себя "открыла", что Key-Value хранилище быстрее чем SQL, начали жужжать об этом на всех сайтах. Соответсвтенно в куче контор отыскался CEO, который спустил вниз указание "NoSQL" быстрее, значит его и используем. Сейчас, вроде, волна спала. Кажется стали понимать что NoSQL не панацея. Но с сабжем это, ведь, вообще никак не связано. Зачем зацепились?
...
Рейтинг: 0 / 0
02.07.2012, 16:56:12
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863317
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
BlazkowiczТимоНСпор пошел дальше, "NoSQL в общем - зло". С этим я не согласен.
Про "зло", вроде, никто не писал. А то что это "дань моде", то это правда. Сначала общественность для себя "открыла", что Key-Value хранилище быстрее чем SQL, начали жужжать об этом на всех сайтах. Соответсвтенно в куче контор отыскался CEO, который спустил вниз указание "NoSQL" быстрее, значит его и используем. Сейчас, вроде, волна спала. Кажется стали понимать что NoSQL не панацея. Но с сабжем это, ведь, вообще никак не связано. Зачем зацепились?
Ну с сабжем вроде разобрались. А мне стал интересен опыт других людей работы с NoSQL и странная нелюбовь к направлению в общем. А там пошло/поехало ...
Мне предстоит собирать небольшую аналитику по активности пользователей на сайте с использованием NoSQL. Вот и интерес мой отсюда.
...
Рейтинг: 0 / 0
02.07.2012, 17:01:55
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863382
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
Сначала общественность для себя "открыла", что Key-Value хранилище быстрее чем SQL, начали жужжать об этом на всех сайтах

За счет чего?
Вот например бенчмарк:
http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html
Postgres - 350000 rps. Кому может быть нужно больше?
...
Рейтинг: 0 / 0
02.07.2012, 17:35:38
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863396
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Йуный джавистЪЗа счет чего?

За счет накладных расходов на SQL.

Йуный джавистЪВот например бенчмарк:
http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html
Postgres - 350000 rps. Кому может быть нужно больше?
Это не единственный пример. Уже ходила статья про плагин к MySQL, который в режиме получения данных NoSQL разрывает любые популярные NoSQL решения. Там самое сложное добиться от системы IO нужной скорости. :)
Так что это вопрос к Penkov Vladimir, почему он считает SQL несовместимым с highload.
...
Рейтинг: 0 / 0
02.07.2012, 17:43:23
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863403
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GKS_Samara
Участник
Добрый день, Petro123!

> ну ясен пень. Будем Модель подгонять под Выборку ))))

В этом и есть прелесть NoSQL.
Когда варианты выборок строго ограничены, то можно построить модель
данных, которая будет работать очень быстро и SQL не нужен.
Когда выборки вариантны- NoSQL не подходит.
Кстати, NoSQL - отличный кэш для SQL.

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.07.2012, 17:48:48
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863410
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
GKS_SamaraКстати, NoSQL - отличный кэш для SQL.

Да, ну? А мы думали EhCache в Hibernate как-то по другому работает.
...
Рейтинг: 0 / 0
02.07.2012, 17:53:39
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863411
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
GKS_SamaraДобрый день, Petro123!

> ну ясен пень. Будем Модель подгонять под Выборку ))))

В этом и есть прелесть NoSQL.
Когда варианты выборок строго ограничены, то можно построить модель
данных, которая будет работать очень быстро и SQL не нужен.
Когда выборки вариантны- NoSQL не подходит.
Кстати, NoSQL - отличный кэш для SQL.

--
Алексей
JID: alxt@ya.ru


так тебе об этом и говорят - модель можно подогнать под одну выборку и она (выборка) будет выполняться очень быстро. А любая другая выборка будет выполняться очень медленно, просто перебором будут сканиться все данные.

В случае SQL любая выборка будет выполняться быстро.
...
Рейтинг: 0 / 0
02.07.2012, 17:53:39
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863414
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
1024так тебе об этом и говорят - модель можно подогнать под одну выборку и она (выборка) будет выполняться очень быстро. А любая другая выборка будет выполняться очень медленно, просто перебором будут сканиться все данные.

В случае SQL любая выборка будет выполняться быстро.
В точку!
...
Рейтинг: 0 / 0
02.07.2012, 17:54:24
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863420
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
BlazkowiczЭто не единственный пример. ...
Правильно ли проводить такие бенчмарки? Что он показывает? То что SQL выбирает данные из таблички быстрее чем NoSQL решения? Это же не о чем не говорит.
А если запустить похожий бенчмарк но с выборкой какой нибудь сущности размазанной по нескольким таблицам и допустим документ из NoSQL?
...
Рейтинг: 0 / 0
02.07.2012, 17:57:01
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863427
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
BlazkowiczТак что это вопрос к Penkov Vladimir, почему он считает SQL несовместимым с highload.

потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули
...
Рейтинг: 0 / 0
02.07.2012, 18:04:37
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863428
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
Penkov VladimirBlazkowiczТак что это вопрос к Penkov Vladimir, почему он считает SQL несовместимым с highload.

потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули

+ от 100кк уникальных ключей
...
Рейтинг: 0 / 0
02.07.2012, 18:05:51
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863548
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули

О каких сложениях идет речь?
...
Рейтинг: 0 / 0
02.07.2012, 20:06:30
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863571
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
А если запустить похожий бенчмарк но с выборкой какой нибудь сущности размазанной по нескольким таблицам и допустим документ из NoSQL?

Документы (то есть блобы) можно напихать в традиционную СУБД. Можно при желании индексировать по отдельным полям в блобах (postgres hstore, oracle index-by tables). В оракле есть cluster - данные физически хранятся в prejoined виде, но логически выглядят как обычные таблички.
По скорости NoSQL проиграет. Например, в MongoDb есть один глобальный лок на всю базу ( http://stackoverflow.com/questions/7506124/is-it-true-that-mongodb-has-one-global-read-write-lock).
Также предлагаю сравнить документацию по бэкапу в Postgres:
http://www.postgresql.org/docs/9.1/static/continuous-archiving.html
и в MongoDb:
http://www.mongodb.org/display/DOCS/Backups
...
Рейтинг: 0 / 0
02.07.2012, 20:31:32
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863613
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
- не совсем понял о чем дискуссия? очередное сравнение слона и кита? Когда говорят о производительности NoSQL речь идет о производительности на больших объемах данных, о таких объемах на которых применение РСУБД либо экономически не выгодно, либо технологически проблематично. Т. е. NoSQL - это нишевое решение, которое не конкурирует с РСУБД.
...
Рейтинг: 0 / 0
02.07.2012, 21:25:28
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863643
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
Йуный джавистЪпотому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули

О каких сложениях идет речь?
взять число по ключу, прибавить 1, записать обратно. если ключа нет - создать.
...
Рейтинг: 0 / 0
02.07.2012, 22:10:08
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863644
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
Йуный джавистЪНапример, в MongoDb есть один глобальный лок на всю базу ( http://stackoverflow.com/questions/7506124/is-it-true-that-mongodb-has-one-global-read-write-lock).
Также предлагаю сравнить документацию по бэкапу в Postgres:
http://www.postgresql.org/docs/9.1/static/continuous-archiving.html
и в MongoDb:
http://www.mongodb.org/display/DOCS/Backups


из всех noSQL решений вы выбрали худшее и сравнили с лидерами )))
сравните с hbase тогда уж
...
Рейтинг: 0 / 0
02.07.2012, 22:11:18
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863674
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кореец
Участник
Penkov Vladimirвзять число по ключу, прибавить 1, записать обратно. если ключа нет - создать.

хитрый апдейт на 200 000 записей в секунду?
а кроме этого в табличке какие еще поля?
запись на диск или все таки только в память?

на какой машине это все делалось?
какая именно NoSQL? случайно не редис?
...
Рейтинг: 0 / 0
02.07.2012, 22:57:14
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863694
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
postgres=# drop sequence if exists test;
NOTICE:  sequence "test" does not exist, skipping
DROP SEQUENCE
postgres=# create sequence test;
CREATE SEQUENCE
postgres=#
postgres=#
postgres=# create or replace function seqtest() returns void as $$
postgres$# begin
postgres$# for i in 1..2000000 loop
postgres$# perform nextval('test');
postgres$# end loop;
postgres$# end;
postgres$# $$ language plpgsql;
CREATE FUNCTION
postgres=# \timing on
Timing is on.
postgres=# select seqtest();
 seqtest
---------

(1 row)


Time: 13072,983 ms
postgres=#


Это в один поток.
...
Рейтинг: 0 / 0
02.07.2012, 23:24:49
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863822
JavaPhpLover
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JavaPhpLover
Участник
1024ТимоНпропущено...

Складывается ощущение что вы ошибаетесь. Вы серьезно думаете что это просто дань моде?



это не дань моде. Это очередные грабли. SQL слишком сложен для большинства, в результате модными стали простейшие структуры данных а вся мощь SQL отброшена. Типа десяток сджойненных таблиц в запросе который сам соптимизирует и выполнит мгновенно это хуже чем самому городить сбор данных по убогим наборам ключ-значение и пытаться добиться производительности над которой в Oracle работали десятки лет.

плюсую, но это верно только для случая, когда sql может работать с террабайтами данных - а таких решений два, может три на всю планету
...
Рейтинг: 0 / 0
03.07.2012, 02:38:53
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863873
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
Йуный джавистЪ
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
postgres=# drop sequence if exists test;
NOTICE:  sequence "test" does not exist, skipping
DROP SEQUENCE
postgres=# create sequence test;
CREATE SEQUENCE
postgres=#
postgres=#
postgres=# create or replace function seqtest() returns void as $$
postgres$# begin
postgres$# for i in 1..2000000 loop
postgres$# perform nextval('test');
postgres$# end loop;
postgres$# end;
postgres$# $$ language plpgsql;
CREATE FUNCTION
postgres=# \timing on
Timing is on.
postgres=# select seqtest();
 seqtest
---------

(1 row)


Time: 13072,983 ms
postgres=#



Это в один поток.


я нифига в этом не понял, что тут происходит?

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


у нас hbase был, с таким объемом он слег.
написали свою memory based БД, она вроде работает
...
Рейтинг: 0 / 0
03.07.2012, 08:23:17
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863874
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
Кореец
на какой машине это все делалось?
какая именно NoSQL? случайно не редис?

там hbase в кластере
...
Рейтинг: 0 / 0
03.07.2012, 08:24:16
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863887
Garrick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Garrick
Участник
ShSergeЗа последний десяток лет, не написал ни одного селекта с меньше, чем тремя приджойненными таблицами. Исключая, ясен перец, справочник полов - Мужской(М), Женский(Ж), Неопределённый(Н). Кстати, последний иногда тоже имеет место быть.
привильно писать "оно ещё не определилось "
...
Рейтинг: 0 / 0
03.07.2012, 08:37:22
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37863894
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GKS_Samara
Участник
Добрый день, Blazkowicz!

>> Кстати, NoSQL - отличный кэш для SQL.
> Да, ну? А мы думали EhCache в Hibernate как-то по другому работает.

Ну так можно рассматривать EhCache как NoSQL БД :)

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.07.2012, 08:49:10
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37864166
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Penkov Vladimirя нифига в этом не понял, что тут происходит?
он 2 миллиона раз увеличил sequence на 1
...
Рейтинг: 0 / 0
03.07.2012, 11:56:43
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37864271
Фотография Penkov Vladimir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Penkov Vladimir
Участник
chpashaPenkov Vladimirя нифига в этом не понял, что тут происходит?
он 2 миллиона раз увеличил sequence на 1

а sequence всего 1? нужно много их
...
Рейтинг: 0 / 0
03.07.2012, 12:55:23
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37864470
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Penkov Vladimirchpashaпропущено...

он 2 миллиона раз увеличил sequence на 1

а sequence всего 1? нужно много их
х.з. что хотел сказать автор
...
Рейтинг: 0 / 0
03.07.2012, 14:26:46
| Ответить | Цитировать | Написать  
JPA vs JDBC для высоконагруженного приложения.
    #37864790
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
а sequence всего 1? нужно много их

Создайте много сиквенсов, по одному на каждого пользователя.
х.з. что хотел сказать автор

Я хотел сказать, что для такой задачи надо использовать сиквенсы, а не столбцы таблиц.
...
Рейтинг: 0 / 0
03.07.2012, 16:20:32
| Ответить | Цитировать | Написать  
68 сообщений из 68, показаны все 3 страниц
  все  
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=59&tid=2131428]:
 0ms
get settings:
 17ms
get forum list:
 20ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 38ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 77ms
get tp. blocked users:
 2ms
others: 371ms
total:  550ms
созд. / загр.: 550ms
x
x
Закрыть


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