ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
25 сообщений из 68, страница 2 из 3
  2  все
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
| Ответить | Цитировать | Написать  
25 сообщений из 68, страница 2 из 3
  2  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA vs JDBC для высоконагруженного приложения.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&startmsg=37863029&tid=2131428]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 44ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 274ms
total:  420ms
созд. / загр.: 420ms
x
x
Закрыть


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