Э, а где тут нагрузка?
Информация по 25 000 пользователей - это копейки, тут лучше просто реляционную БД поставить.
Даже если будут очень-очень активные пользователи , то получим где-то тысячу запросов в секунду в пиках, достаточно простых.
Реально же, подозреваю, и десятка операций в секунду в пике не наберется. Но тут надо посмотреть на задачу внимательно.

Я бы поставил
приличную реляционную БД (ну, например, DB2 Express C),
один сервер приложений (кэширование, бизнес-логика, работа с правами доступа и т.д.).
Если с железом плохо, а нагрузки очень большие - то java. Если все не так плохо - то можно и какой-нибудь python.
Ну и для веб-клиентов - еще и веб-сервис (тонкие клиенты ходят напрямую к серверу приложений).

В общем, все достаточно там просто, думать особо не надо, никаких извращений с Erlang и MongoDB не требуется.

Если нужна надежность - то средствами БД.
Масштабируемость - в основном на уровне сервера приложений и кэширования данных.

А вообще - можно хоть на PHP делать, взлетит...

Это дипломная работа или коммерческий проект? Если второе - то найдите консультанта с опытом. Денег потратите гораздо меньше, чем выкинете на всякие экзотические решения.

rustyhex,

Приличная - это с нормальным оптимизатором запросов и надежная.
Т.е. из большой тройки + Postgress + Informix. Может, еще кто-то справиться.

У DB2 очень хороший оптимизатор, очень хороший SQL, куча удобных для трехзвенки фенечек, при этом она проста в настройке и бесплатная версия дает достаточно функциональности (и без ограничения на объем БД).
Если же покупать годовую поддержку (2K$ в год, т.е. мелочи), то это еще и HADR и репликация.

По сравнению с Postgress - хороший оптимизатор, вылизанная репликация и HADR(аналог появился только в 9ке и опыта использования пока нет), простота администрирования, несколько очень специальных фенечек, удобных для трехзвенки.

Но если есть опыт использования Postgress - то стоит брать его. Если опыта работы с БД нет - то лучше DB2.

Про Java.
Не знаю, откуда вы услышали про тормознутость виртуальной машины Java, первый раз про такое слышу. Все остальные виртуальные машины - точно хуже, да и значительная часть компилированных языков дают производительность не лучше.
Основные плюсы Java - под нее уже есть много всякого хорошего, при этом язык стимулирует писать приличный код и популярна.
Erlang сам по себе, кстати, дает производительность меньше, нежели Java, выигрыш (в некоторых применениях) у приложений Erlang скорее за счет другой архитектуры решений.

Расскажите про задачу поподробнее, может там и есть подводные камни, которые требуют действительно экстремальной производительности.

rustyhexКлиенты проходят аутентификацию на сервере приложений

А как именно они аутентифицируются?

Шифроваться всё будет асимметричным алгоритмом шифрования (есть опасения насчёт загрузки CPU).

А чем https не устроил? Тогда и с CPU проблем не будет.

Сервер приложений скидывает всё это в БД

Без кэширования? И это все, что делает БД?
По идее, проверку прав тоже лучше делать на AppLayer. Как и кэширование данных по группам.

Ну для начала можно взять в 2 раза меньше - 12500 юзеров, а проблему их увеличения решить с помощью вертикального масштабирования. Т.е. будет 44 операции записи.

Операции записи очень плохо "вертикально масштабируются". И не стоит считать, что все действия среднего юзера в течении дня будут равномерно распределены по рабочему времени, стоит прикинуть нагрузку в пиках и подумать, что с ней делать.

Запросы несложные - будут сообщения юзеров, отсортированные по группам.
Несколько групп будут в одной учётной записи.
Клиентам надо выдавать новые сообщения в группе, но только тем, которые вошли и имеют право на доступ к данной группе.
Сами сообщения локально хранятся у клиентов и будут периодически синхронизироваться с базой.

Хм. А может взять какой-нибудь ejabberd и просто его настроить для этих задач? Ну или любой другой мессенджер. А то задача то стандартная неимоверно.

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

Глупость. Динамические запросы стоят заметно дороже (а в таком варианте придется делать именно динамический SQL).
Да и непонятно, а что в такой схеме вообще будет выигрываться.

И вопрос насчёт mysql, чем он плох? С xtradb (форк innodb) говорят хорош.
Э, а чем он хорош? Впрочем, пока нет цифр о требуемой надежности и безопасности, выбирать БД рановато. Но я бы с MySQL для этой задачи не связывался, делать на нем очереди довольно неудобно....

Пока такой вариант: клиент периодически подключается и проверяет по дате обновления группы время последней модификации.

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

Возьмет JMS - там реализация очередей с поддержкой персистентности сообщений (то что вам и надо) есть.

JMS - это, все-таки, стандарт на работу с очередями из Java. Реализаций JMS довольно много, можно найти подходящую.
Вообще, работу с очередями не так уж и сложно реализовать в БД (впрочем, в MySQL - сложно).

Ну а то, что там предлагали на .Net - это что-то совсем странное и для каких-то непонятных целей. Впрочем, так как проект так и не закончен и документации нет, то и смотреть туда не стоит.

ВМоисеев,

Ну как-бы так помягче сказать...
Распределенные нагруженные системы - вещь, на самом-то деле, довольно простая. И если за три года не удалось сделать рабочего прототипа и просчитать нагрузку - это говорит уже о многом.
Ну и почитав статьи - становится понятно, что представления о том, как делаются надежные, нагруженные и масштабируемые системы у автора нет. Многие существенные проблемы даже не рассматриваются, а вот всяким несущественным мелочам типа организации транспорта и низкоуровнего протокола придается большое значение.
Впрочем, .Net - не самый лучший инструмент для подобных задач.

iv_an_ruпристойную СУБД, желательно с HTTP-сервером в том же процессе
Ой, а в чем смысл HTTP-сервера в том же процессе?

iv_an_ru,

Хм, для подобной задачи, подозреваю, расходы на IPC будут, прямо скажем, не слишком заметны. Тут даже обмен в локальной сети с БД не окажет существенного влияния на скорость. Генерация html-контента и работа с жестким диском потребуют заметно больше ресурсов.

А где http-сервер встроен прямо в процесс БД? И как там решают проблемы безопасности этого процесса, например?

ВМоисеев,
Ну, например, http://download.yandex.ru/company/experience/rit2008/highload_philipp.pdf
Остальное, если нужно, сами найдете, занятие не сложное...

iscrafm,
Лучше найдите запись доклада, в инете где-то есть. Все-таки, слайды презентации - это только вспомогательный текст. А рассматриваемые системы - почти любые, где одновременно и (относительно) высокая нагрузка и сложная бизнес-логика. Из того, что запомнилось из сделаного лично - букмекерская система (с всевозможным риск-менеджментом, где как раз сложность в основном и живет). Но в докладе, понятное дело, не только мой опыт суммирован, темой то давно занимаюсь, так что поанализировать есть что.
Как раз про Web в докладе довольно мало (хотя по большей части интересная нагрузка вылезает именно в таких задачах (ну и в научных, разумеется - но вот тут как раз опыта нет).