Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC out of memory / 23 сообщений из 23, страница 1 из 1
24.07.2007, 11:42:14
    #34679445
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Всем привет!
У меня возникла следующая проблема, но я даже не знаю в какую сторону копать.

Есть метод, который производит выгрузку результата работы запроса в plain-text файл.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
PreparedStatement stmt = session.getSession().connection().prepareStatement(sql);
...
rs = stmt.executeQuery();
...
 while (rs.next())
{
	 for  ( int  i =  1 ; i < rs.getMetaData().getColumnCount()+ 1  ; ++i)
	{
		s = rs.getString(i);
		bw.write(s);
	}
	bw.write('\n');
}

Всё отлично работает, до тех пор пока я не стал получать в результате запроса много данных. На данный момент это 1,5М строк по 800 байт каждая.
В этом случае вызов
Код: plaintext
rs = stmt.executeQuery();
приводит к Out of Memory error
На сколько я понимаю он пытаеться подтянуть все данные на клиент, чем и убивает JVM.
Можно ли как-то заставить JDBC открыть курсор на стороне БД, и считывать данные непосредственно при вызове, например, rs.next() ?

Спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 12:09:20
    #34679563
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
А что мешает оптимизировать SQL запрос, чтобы он возвращал ограниченное количество результатов?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 12:22:22
    #34679621
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Мне нужны все эти строки.
Или я Вас не правильно понял?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 12:25:50
    #34679636
expp
expp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
а по кусочкам запрашивать слабо ?

ну и можно с типами курсоров поигратьсо. хотя всё от конкретного драйвера зависит
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 12:30:56
    #34679655
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
По кусочкам слабо, так как чтоб запрашивать по кусочкам мне придется каждый раз сортировать выборку. А это достаточно медленно. Тем более если делать это часто.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 12:34:42
    #34679673
Хрюхрюшкин.
Хрюхрюшкин.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13По кусочкам слабо, так как чтоб запрашивать по кусочкам мне придется каждый раз сортировать выборку. А это достаточно медленно. Тем более если делать это часто.
Пробовали
Код: plaintext
1.
preparedStatement.setFetchSize(...);
?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 13:04:36
    #34679807
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
- а что за база?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 13:05:43
    #34679818
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Хрюхрюшкин. preparedStatement.setFetchSize(...);
Попробовал. Результат тот-же. мои JDBC драйвера (Pоstgres 8.2) вообще ИМХО не реагируют на этот параметр :(
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 13:19:38
    #34679872
Ekshibarov Vladimir
Ekshibarov Vladimir
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13 Хрюхрюшкин. preparedStatement.setFetchSize(...);
Попробовал. Результат тот-же. мои JDBC драйвера (Pоstgres 8.2) вообще ИМХО не реагируют на этот параметр :(

Сделай autocommit у соединения в false.

http://jdbc.postgresql.org/documentation/82/query.html
Смотри секцию "Getting results based on a cursor".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 13:48:08
    #34680003
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13По кусочкам слабо, так как чтоб запрашивать по кусочкам мне придется каждый раз сортировать выборку. А это достаточно медленно. Тем более если делать это часто.

LIMIT, OFFSET и COUNT
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:02:54
    #34680654
Dan Black
Dan Black
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov Angel13По кусочкам слабо, так как чтоб запрашивать по кусочкам мне придется каждый раз сортировать выборку. А это достаточно медленно. Тем более если делать это часто.

LIMIT, OFFSET и COUNT очень плохой вариант

ИМХО курсоры - это то, что нужно
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:20:10
    #34680731
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Dan Blackочень плохой вариант
- чем плохой? по моему, простой и надежный и вполне подходящий к задаче, а поддержка курсоров сильно зависит от реализации драйвера.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:23:28
    #34680746
Хрюхрюшкин.
Хрюхрюшкин.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov
- чем плохой? по моему, простой и надежный и вполне подходящий к задаче, а поддержка курсоров сильно зависит от реализации драйвера.
Лучше использовать курсоры. Я думаю, что драйвер их должен поддерживать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:29:55
    #34680777
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov- чем плохой? по моему, простой и надежный и вполне подходящий к задаче, а поддержка курсоров сильно зависит от реализации драйвера.

Плохой тем, что если у меня в таблице 20 записей и я пишу

Код: plaintext
1.
select * from dummy
offset  1  limit  10

а потом

Код: plaintext
1.
select * from dummy
offset  10  limit  20

то нет никакой гарантии что полученные наборы будут равны :

Код: plaintext
1.
select * from dummy
offset  1  limit  20

Чтобы такого не было нужно сортировать - а это на больших данных очень дорого.
Плюс ко всему за промежуток время между считываниями данные могут уже поменяться.

Ekshibarov Vladimir http://jdbc.postgresql.org/documentation/82/query.html
Смотрю, похоже то, что нужно...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:31:07
    #34680784
Dan Black
Dan Black
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov- чем плохой? по моему, простой и надежный и вполне подходящий к задаче, а поддержка курсоров сильно зависит от реализации драйвера.
плох по ресурсоёмкости при больших и сложных выборках
+ результат при такой выборке может изменяться другими параллельно работающими запросами, то есть конечное количество строк в итоге неопределено
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 16:33:48
    #34680804
carper
carper
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13Всем привет!
У меня возникла следующая проблема, но я даже не знаю в какую сторону копать.
Всё отлично работает, до тех пор пока я не стал получать в результате запроса много данных. На данный момент это 1,5М строк по 800 байт каждая.
В этом случае вызов
Код: plaintext
rs = stmt.executeQuery();
приводит к Out of Memory error
На сколько я понимаю он пытаеться подтянуть все данные на клиент, чем и убивает JVM.
Можно ли как-то заставить JDBC открыть курсор на стороне БД, и считывать данные непосредственно при вызове, например, rs.next() ?
Спасибо.

IMHO если не использовать обновляемые и двунаправленные курсоры, то ничего на клиента тянутся без спроса (ну разве что + fetch size) не будет.

Попробуйте, может тут собака порылась?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 17:07:26
    #34680974
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13Чтобы такого не было нужно сортировать - а это на больших данных очень дорого.
Плюс ко всему за промежуток время между считываниями данные могут уже поменяться.

- на запросе SELECT * без доп. условий, данные уже отсортированы - по ключу

- гарантией неизменности данных будет использование транзакций (кстати почему Вы думаете что использование курсора гаранирует неизменность данных? опять же это сильно зависит от реализации драйвера)

Dan Blackплох по ресурсоёмкости при больших и сложных выборках
- возможно, но запрос один и тот же и если использовать preparedStatement возможно (зависит от реализации драйвера и возможностей базы) проблем не будет. Кроме того точно не будет проблем с памятью в JVM. Т. е. тут надо определиться кому должно быть "плохо": приложению или БД :)


Dan Black
результат при такой выборке может изменяться другими параллельно работающими запросами, то есть конечное количество строк в итоге неопределено
- транзакции
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 17:33:31
    #34681090
Dan Black
Dan Black
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Курсоры и подразумевают транзакции.
preparedStatement больше зависит от возможностей базы и выигрыш от его использования в теории не сравнится с выигрышом от использования курсоров. К тому же речь идёт об определенной БД, поэтому ссылаться на возможности и фишки других баз данных не имеет смысла.

Код: plaintext
1.
----------------------------
 Verba volent, scripta manent
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 18:02:26
    #34681211
Angel13
Angel13
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov - на запросе SELECT * без доп. условий, данные уже отсортированы - по ключу

Совсем нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 18:38:26
    #34681329
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13 Kachalov - на запросе SELECT * без доп. условий, данные уже отсортированы - по ключу

Совсем нет.
- Вы правы
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 18:39:17
    #34681334
Timm
Timm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Angel13 Kachalov - на запросе SELECT * без доп. условий, данные уже отсортированы - по ключу

Совсем нет.
+1.
Причем это написано в той сцылке которую ты дал.
Kachalov- гарантией неизменности данных будет использование транзакций (кстати почему Вы думаете что использование курсора гаранирует неизменность данных? опять же это сильно зависит от реализации драйвера)
По дефолту результаты выборки из курсора консистентны на момент его открытия (по крайней мере при беглом осмотре доки PostgreSQL, я это понял так). В случае использования нескольких запросов - такого не будет.
Kachalov- транзакции
Наверно стоит вначале что-нибудь о них почитать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 19:02:12
    #34681382
Kachalov
Kachalov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Timm Angel13 Kachalov - на запросе SELECT * без доп. условий, данные уже отсортированы - по ключу

Совсем нет.
+1.

- и Вы правы

Timm
Kachalov- транзакции
Наверно стоит вначале что-нибудь о них почитать.
- что то грубовато и смысла не много, но Вы правы - почитать о транзакциях стоит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.07.2007, 19:11:21
    #34681401
Timm
Timm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JDBC out of memory
Kachalov
- что то грубовато
Нет, не думаю.
Kachalov
и смысла не много
Аргумент "- транзакции" аналогично.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC out of memory / 23 сообщений из 23, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 609ms
Закрыть
start [/forum/topic.php?fid=59&mobile=1&tid=2145073]:
 0ms
get settings:
 20ms
get forum list:
 25ms
check forum access:
 7ms
check topic access:
 7ms
track hit:
 68ms
get topic data:
 23ms
get forum data:
 6ms
get page messages:
 105ms
get tp. blocked users:
 3ms
others: 345ms
total:  609ms
x
x
Закрыть


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