Значит есть следующая задача.

1) Нужна нескольких сайтов собирать некоторую информацию.
2)Собранную информацию нужно показать пользователем этой системы. Приём не всю информацию а только ту что пользователь затребует. Тоесть должны существовать пользовательские фильтры.
3) Сбор, фильтрация и показ информации должны происходить максимально быстро => стремиться к реальному времени.


Вот в принципе и всё. 
Самое проблемное место у меня это пункт 3. 
я думал с начало всё завидовать в базу а потом запросами по базе предоставлять информацию, но это очень долго.

У кого какие мнения по этому поводу?

Что именно долго?  
Сбор информации будет проходить через специальный "программный" интерфейс или через парсинг html странички?
Если через парсинг html странички то это единственный вариант. Заполнение базы, да будет долгим, а вот запросы думаю будут быстро проходить. Тут и вариантов других нет. Правда базу надо будет периодически обновлять.

Если через специальный "программный" интерфейс то запросы можно просто переадресовывать.

Но в любом случае для сбора реалтайма не будет. Интернет штука медленая,  да и здесь все зависит от сервера от которого надо ждать ответ.

Збор инф. будет проходить через парсинг html, скажем будут работать параллельный парсеры, парсить и передавать инфу в бизнес логику.
А вот дальше хотелось бы обойтись без базы, ну или базы но в памяти. просто информация которая пришла скажем минут через 10 уже не интересна, и её не надо хранить, надо хранить только то что пользователи сами выберут.

Так как это должен быть веб, вот ешё один вопрос, возможно чтобы не пользоватиль спрашивал сервер есть ли у тебя инфа, а на оборот, как только она появилась то сервер сообщил об этом пользователям?

Не вижу в этом смысла. Я бы делал так: ввел бы поле "Дата внесения данных" и запустил бы поток (задачу, демона и т.п.) который бы через определеный интервал производил бы чистку базы. В памяти хранить бы не советовал. Почему? Появиться дополнительные проблемы с перезапуском системы, выключением и экстренным выключением (выдернули шнур с розетки).
Почему вы так боитесь базы данных? Не такая уж она медленная, как вам кажеться. Возьмите MySQL - вполне быстрая и надежная СУБД. Кроме того СУБД решит за вас проблемы синхронизации при изменении данных несколькими потоками.


Через веб такое не получится. Тут должен быть java-script которые периодически опрашивает сервер (а есть что-либо новое?) и если есть то подгружает это новое, но это уже в сторону Ajax-а смотреть надо. 

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

Если же произойдёт отключение сети, то в этом нет ничего страшного если потеряются уже не актуальные данные.

Если же как-то(я пока вообще не знаю возможно ли такое) реализовать базу в памяти, чтобы воспользоваться всеми преимуществами базы(синхронизацией, SQL- запросми, кешированием), тоесть уйти от жесткого диска, и предоставлять пользователям информацию так сказать из "памяти", то время от полевения инфы на сайте, до получение этой же инфы пользователем стремиться к "0".

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



Это сообщение отредактировал(а) unkis - 8.7.2009, 13:35

У вас есть конкретные проблемы с производительностью или это ваши мысли?
"Не пытайтесь оптимизировать то чего нет."
Привидите объемы инфы (кол-во записей) и колличество запросов в минуту.



Без базы если хотите можно обойтись. Просто реализовать объектную модель данных с необходимыми методами поиска, обновления инфы ну и т.д. Посмотрите в сторону списков и коллекций. Только не забудте вашы классы сразу сделать Serializable, в дальнейшем вам это может пригодиться. Но в данном случае все вопросы синхронизации (многопоточность) переходят на ваши плечи.

каждые 10 секунд нужно обработать до 500 записей. что это значит.
Это значит распарсить, привести в внутренний формат и показать пользователю.
если работать с БД, то это означает, разложить эти 500 записей по различным таблицам, навскидку их должно быть около 10, тоесть 500*10 = 5000 инсертов за 10 секунд.
При этом нужно успевать отрабатывать запросы пользователей, а их примерно будет около 1000, причем запросы не простые а с join, и в среднем будет задействовано около 5 таблиц.

И вот в принципе такая вот нагрузка. Поэтом я не уверен что скорость жесткого диска позволит всё это проделать.



А что не существует разве баз, которые позволят разворачивать таблицы в памяти, чтобы работать с базой и иметь почти все её преимущества, также как если бы она была развёрнута на HDD?

Вопрос - для всех пользователей загружается одинаковая информация (позже обрезается фильтрами этого пользователя) или для каждого отдельно взятого пользователя изначально загружаемая информация уникальна? Мне кажется, наиболее узкое место тут именно загрузка. Если загружающих потоков будет много, тормоза неизбежны. Если у этих сайтов есть RSS Feed, лучше загружать его - он значительно меньше по объему и выражен правильным XML.

Я не думаю, что даже при плохом канале загрузка / парсинг займут больше нескольких секунд, что вполне терпимо.


Да, возможно. Изучите, как работает, например, Facebook Connect. Грубо говоря, открывается соединение с определенным URL, которое остается висеть в ожидании данных в течении разумного интервала времени (где-то 1 минуту обычно). Если в течении этого времени у сервера появились какие-либо данные, которые нужно передать клиенту, он пошлет их уже в рамках этого ожидающего соединения. При получении данных клиент снова открывает ждущее соединение. Если в течении минуты у сервера не появилось данных для этого клиента, он просто разрывает соединение и клиент открывает его вновь. 

Под клиентом в вашем случае подразумевается браузер клиента, а все описанное с клиентской стороны может быть реализовано средствами JavaScript.

Это сообщение отредактировал(а) mantracoder - 8.7.2009, 15:07

Да, для всех загружается одинаковая информация а потом обрезается фильтрами.



то что мне нужно, а нет ли уже готовых framework-ов?

я думаю использовать для этого seam +gwt, a вы что по этому поводу думаете?

Многие базы данных имеют туеву хучу настроек производительность. За все БД не скажу, но в PostgreSQL их очень много. 
Можно просто в конфиге выделить достаточно много под кэш и данные не будут читаться с диска, а браться из памяти в 99% случаев.
Еще, в том же конфиге можно отключить сброс журнала транзакций на диск, т.к. вам потеря данных в случае аварийного завершения не критична, а это сильно увеличит скорость вставки данных. 
Да и вообще, в Postgres достаточно много настроек, касательно памяти и дисков на все случаи жизни. Думаю, в других БД их тоже достаточно.

MySQL:

13.4. The MEMORY (HEAP) Storage Engine

The MEMORY storage engine creates tables with contents that are stored in memory. Formerly, these were known as HEAP tables. MEMORY is the preferred term, although HEAP remains supported for backward compatibility.
13.4. The MEMORY (HEAP)

HSQLDB
Persistence:
In-memory tables for fastest operation
hsqldb - 100% Java Database

Это сообщение отредактировал(а) Skynin - 9.7.2009, 12:24

с базой вроде разобрался, теперь разбираюсь с клиентской частью, думаю на чём писать.

Сейчас склоняюсь в сторону JBoss + Seam+GWT.

Но хочу технологию Comet, но она по моему в GWT не поддерживается.

rocket-gwt - это comet.

Ребята, а есть ли что-то, чтобы мой парсер как-то задеплоить на сервер.

Парсер должен работать всегда, тоесть он конектится к сайтам и забирает информацию.

В случаи десктопного приложение здесь все понятно, есть main метод из которого я могу вызвать всё что мне надо, а как с этим обстоит в ЕЕ?

Например, Quartz в последнее время часто проскакивает.

Добавлено через 10 минут и 51 секунду
Еле вспомнил:
EJB Timer service.