Оригинал в ветке Оракла - но тут тоже думаю есть кому приложиться так сказать
===

Выношу на общественный суд предложенную архитектуру системы. Буду признателен за конструктивную критику (немного неконструктивной тоже можно, но в меру).

Ограничения:
1. Oracle XE - на первое время 11ГБ хватит за глаза, а там можно на СЕ1 переехать
2. ТОлько локальные диски пока (в перспективе SAN/FCoE/ISCSI)
3. Использование ЕС2 или схожего решения для облачного развертывания

Физическая конфигурация:
1. Сервер БД - 1.7G RAM (EC2 small instance) + 2*15GB диски ЕБС (striped with mdadm) для данных
OS: Oracle Linux 5/6
2. Веб/сервер приложений: 3.75GB RAM (EC2 medium instance) + 2*10GB диски ЕБС (striped)
OS: Oracle Linux 5/6
AppServer/WebServer: Oracle GlassFish 3.1
Дополнительно на этом же сервере: Apache ActiveMQ message broker
memcached server
Suggested RAM allocation: AS - 2.5GB
memcached - 768MB

Собственно вопрос:

Сайт будет позволять пользователям загружать картинки товаров, думаю не более 20 на пользователя. Картинки предполагается хранить в базе как БЛОБы. Периодически картинки выгружаются из базы на локальный диск и синхронизируются с хранилищем СДН (eg. Amazon CloudFront)

Предполагаемый подход:
1. Пользователь загружает картинку
2. Приложение сохраняет ее в базу, поле Extraction_Date = NULL
3. По крону или по планировщику Глассфиша запущаем либо бин либо PL-SQL скрипт для выгрузки невыгруженных картинок на диск
3.1 Допустимо чтобы картинка была выгружена в течение часа. Пользователю, загрузившему картинку, ее можно показать и из базы я думаю.
4. rsync синхронизирует локальный диск с хранилищем CDN
5. Программа генерирует ссылки на кратинке в формате необходимом для CDN

Где могут быть узкие места подобного подхода при наличии около 1000 одновременных пользователей в системе (на данном железе)?
На чем следует акцентировать внимание при формировании бюджета в будущем? Например за 5 килобаксов купить пролиант с 16ГБ памяти и ССД диски?

Буду благодарен опытным архитекторам и просто профессионалам за конструктивную критику и предложения по улучшению.

Petro123,

Не скажите, коллега. Вот допустим вам нужно определенное время отклика. Есть СДН, есть картинки. А вот как их синхронизировать, будет ли масштабироваться подход с пакетной выгрузкой, или сделать JMS очередь и слушаетеля для выгрузки для скорейшей обработки. Опять же, может букв и много, и громкий заголовок, но из блоков и собирается система, и при так сказать кривизне одного блока, другой должен быть так сказать впуклым :-) Интересует критика и потенциальные узкие места при росте числа пользователей и картинок. Для корпоративного сайта может скорость и не критична, но для пользователей допустим платного сервиса это реальное конкурентное преимущество. Так что пАпрашу Вас пролить свет на недостатки предложенного подхода.

Petro123,

Согласен, мне сейчас сложно оценит такой показатель. Поэтому и интересуют потенциальные проблемы предложенного подхода, чтобы в будущем избежать сложных изменений. Время простоя в будущем будет стоить денег, поэтому хочется определиться раньше нежели чем позже. Если у Вас кроме критики постановки вопроса и отсутствия в задаче некоторых вводных данных нет аргументов, меня это несказанно радует.

Kostya Ilyinov,

Согласен, данных для детального разбора подхода может недостаточно, но я поясню что я бы хотел услышать:

1. Предложенный подход будет тормозить доступ к картинкам, т.к. процессы оракла будут соревноваться за доступ к таблице с картинками (это пример, на самом деле гонки не должно быть ввиду хранения картинок допустим в отдельном табличном пространстве от самих данных о картинках - идентификатор товара и т.д.)
ИЛИ
2. Предложенный подход гавно, потому что картинки надо хранить на диске, я видел что Ашот так делает и это единственно верное решение

и т.д.

Petro123,

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

Petro123,

Т.е. предлагаете при загрузке картинки сразу писать 2 поля - большую и маленькую картинки? И на странице показывать маленькие, а при нажатии - большую? В том то и дело, что из базы хочется брать минимум - скажем так, метаданные. А картинку (любую) рендерить с веб/СДН сервера.

Petro123,

Вот это уже дело. Тут еще какая особенность имеется. В РФ скажем так подавляющее большинство целевой интернет-аудитории онлайн проекта сидит в Дефолт-сити или Питере. Тут (в Австралии) все несколько иначе - относительно крупных городов несколько (скажем 4-5), и все хотят быстрый сайт, избалованы фэйсбуком и его СДНами. Поэтому СДН - это скорее данность, он не требует больших затрат, и дает ощутимое преимущество при географическом распределении аудитории. А все из базы тянуть - да, проще, но рано или поздно что-то надо будет делать. Вот я и думаю, предложенное решение вроде навскид решает задачу, и масштабироваться должно неплохо (хехе, без тестов - только в теории). Поэтому и пляшу от СДНа так сказать. Картинки из базы ведь кэшироваться не будут (?), и это опять же дополнительные расходы по трафику и деньгам между узлами в облаке.

mayton,

Коллега, поясните пожалуйста. Кого задосят? СДН, сервер приложений или ?

mayton,

XE будет брать одно ядро по-моему. Допустим. Ну и как же быть в подобной ситуации? Ваши предложения в студию пожалуйста.

Petro123,

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

рубист,

Оргументируйте, коллега