Дапустим у меня есть продукты которые имеют некоторые параметры (размер, цвет, цена и т.д.). Люди могут подписаться на новости, в которых пишеться что появился новий продукт по его за ранее описанным параметрам. Вот я подумал если таких подписчеков пару тысяч (даже на один и тотже продук (подумал про оптимизацю)), то мне кажется при инсерте селектить тысячеи людеи запросы и смотреть, подходит ли им етот продукт и высылать тогда на мыло инфы слишком неоптимално (например если наже я использую hibernate StatelessSession). Как реализуються похожее?

А нафига тут вообще массовый insert? Появился продукт в продаже: записал в ToDo табличку: оповестить всех подписавшихся, что появился продукт Х. Потом придет какой нибудь фоновый поток, прочтет эту ToDo-шку, выполнит один select, получит всех подписавшихся и пойдет слать им письма. Как закончит ToDo-шку удалит.

создают скедулер, который к примеру раз в сутке делает рассылку

Добавлено через 2 минуты и 30 секунд
вот есть такой вот фреймворк для этих целей

Да, но етот селект должен будет выбрать с базы данных всех подписчиков, которие хотят палучить инфо про продукт которого параметар1 равнается х, параметар2 равнается y .... В селекте палучется длинний WHERE. Или просто всех селектить и виберать уже в jave каму слать а каму нет ?


Знаем и ползуемся всегда 

Ну вообще-то если база сделана по уму, то у тебя должна быть кросс таблица где указанно, пользователь с ID таким-то, подписался на товар с ID такими-то. Так что все данные можно выбрать, одним запросом.

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

Если типы этих параметров заранее известны, то в принципе можно составить такой запрос, хотя он возможно будет монстровым. Ну а если нет, то что еще остается, кроме как просто пробежаться по позовательским фильтрам и проверять попадает товар под них или нет?

Я про такой вариант тоже думаю. Он хороший при неболших (например до 10000) ползователей. А если их 100000 ? Думал может какието речения есть, вплот до математики, например графы ? 

Ну я бы сделал, предварительную выборку по неким основным полям (цена, категория и т.п.), а дальше уже бы просто проходился бы и проверял оставшиеся на соответствие.

Я думал по типу продукта. А болле конкретно например по цене неполучится, а вдруг будет ползователь котораму без разницы какя цена, но важен цвет ?

Ну смысл в том, чтобы взять параметры которые указывают большинство пользователей и которые наиболее общие. Так чтобы минимизировать выборку.

Вот с ценой, все просто: есть верхняя граница и есть нижняя (если не заданы, то можно просто вставлять в таблицу -1 и MAX_VALUE). И по таким параметрам сделать выборку очень просто.

А вот с типом продукта сложнее, человек может сразу подписаться на несколько типов продукта. И тут возникает вопрос, как этот набор значений хранить? Как несколько подписок, как связанная таблица и т.п.

Продукт известен потому что мы создаем новый продукт конкретного типа, и при его создании оповешаем подписчеков на етот продукт. Получаем всех подписчиков на етот продукт и уже в програме филтрируем, подходит ли новий продукт дла подписчика. Толко тогда вопрос, если часто появлаются продукты, то несличком ли часто будет запускатся такая прочедура, например если продукт появлается раз в 2 секунды?

Как настроишь, так и будет. И собственно в чем проблема? Она вообще может непрерывно работать в фоне, поскольку она завязана на сеть, то 100 процентов ресурсов она не отожрет.