Серверный скрипт организации сложной структуры нескольких СУБД

[Человек_Борща]

Добрый день!

Планирую создать пользовательский сервис с высокой нагрузкой.

При регистрации, пользователь получит БД(именно БД) в своё пользование и место на ЖД. В последующем пользователь может купить ещё несколько БД к своему аккаунту.

<Серверная часть>
На чем лучше всего писать серверное приложение/скрипт который будет управлять базами данных максимально быстро?
На чем лучше всего писать скрипт распределения места на ЖД, под пользователей?

Что почитать об организации такой сложной архитектуры?

Чем лучше всего все это связать с Web(конечный пользователь, администратор)?

Какую БД взять?
Требования к БД:
- Транзакции
- Хранимые процедуры
- Сильное шифрование канала передачи данных
- Многопользовательский доступ одного клиента из разных мест так, чтоб всего открытые им сессии не умерли(если такое реально)

По серверному ПО думаю, что будет весьма быстро писаться Java(JSP) как web-интерфейс так и серверная часть на Comcat(не силен в этой части, если не прав, рассудите).

Сервера: Unix однозначно

По нагрузке... ну скажем, оцениваю старт проекта в 20 тыс. простых клиентов(макс. 40 тыс.)(1 СУБД, 10 гб на лицо). и 10 тыс. премиум клиентов(2-5 СУБД, ~50 гб на лицо)
Сетевая активность: 15 тыс. одновременно(простых), (2-3 тыс. премиум)

Все числа примерно с потолка расцениваются как возможная, максимальная загрузка серверов.

Начну естественно всего с одного сервера дома на 1-2 Тб и 25 Мбит линию от провайдера.

Это не соц. сеть да и вопрос не об этом.

Подскажите знающие, кто чего может

Ещё интересен момент облочных технологий как для СУБД так и для размещения файлов.

[Utkin]

СУБД обычные? В смысле реляционные?

[Stilet]

Требования к БД:
- Транзакции
- Хранимые процедуры
- Сильное шифрование канала передачи данных
- Многопользовательский доступ одного клиента из разных мест так, чтоб всего открытые им сессии не умерли(если такое реально)

Я только Lotus Domino знаю из всех что под твои требования подходят...
Причем она есть и под никсы и имеет возможность выходя через вебинтерфейс.

[Utkin]

FireBird, только про шифрование не уверен. Зато бесплатно.

[Человек_Борща]

СУБД обычные? В смысле реляционные?

Вот уж не знаю. Данные в СУБД неразрывно связаны с файлами на ЖД.
т.е. запись в БД ссылается на файл.

Если в БД нет ссылки на файл на ЖД, а файл есть - файл удаляется т.к. не используется/потерян.

Файлы - преимущественно изображения(png), не высокого качества.

И вот что будет лучше с точки зрения производительности? Хранить на ЖД отдельно и класть в BLOB-ы? И какой риск представляет последнее?

Я только Lotus Domino знаю из всех что под твои требования подходят...
Причем она есть и под никсы и имеет возможность выходя через вебинтерфейс.

врядли лотус - то что надо. Там авторизация 1 раз и пользуйся, открывай 100500 чего угодно, но 2 раза 1 аккаунтом не зайти. Хотя могубыть не правым. В общем лотус не совсем то, переодически им пользуюсь
Последним требованием могу пренебречь.

Шифрование канала передачи данных, многопользовательский доступ к 1 БД с разных аккаунтов - очень необходимо.

FireBird - гляну сегодня По описанию он вкусный.

[Аватар]

При регистрации, пользователь получит БД(именно БД) в своё пользование

В чем смысл именно БД?

[Stilet]

но 2 раза 1 аккаунтом не зайти.

А это смотря как агента написать
Ту дело то такое - в других СУБД тоже авторизоваться по сто раз не требуется.
А вот

Шифрование канала передачи данных, многопользовательский доступ к 1 БД

Это лотус хорошо умеет. Так хорошо что я даже иногда "достаюсь" авторизоваться по всякой мелочи.
И шифрование там на уровне RSA кажись. Плюс HTTPS поддерживает. Короче СУБД вполне весомая для таких дел.

[Человек_Борща]

В чем смысл именно БД?

В том же, в чем смысл и остальных СУБД.
Хранить информацию, которую пользователь туда передает в/из источник(а).

[Аватар]

Сообщение от Человек_Борща

В том же, в чем смысл и остальных СУБД.
Хранить информацию, которую пользователь туда передает в/из источник(а).

Это понятно. Зачем каждому отдельную базу?

[Человек_Борща]

Это понятно. Зачем каждому отдельную базу?

Чтобы 1 пользователь никогда и никак не увидет базу другого пользователя или базу в целом. В целях безопасности.