Владимир Смирнов

Мне кажется, Вы теплое с мягким перепутали. Вы понимаете, что такое JSF, и что такое RMI, для чего они нужны, и где их применяют?

Про текст и JSF вроде понятно, про файлики и RMI вроде не понятно.

Советую сначала разобраться что такое web, как он работает, как клиент (браузер) общается с сервером. Как можно отправлять данные на сервер (формы). Как эти данные на сервере обрабатывать. А уже потом, когда разберетесь, можно размышлять про JSF и RMI.

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

Это одно из соглашений для класса, что бы он мог использоваться как Java Bean

Свойства класса должны быть доступны через get, set и другие методы (так называемые методы доступа), которые должны подчиняться стандартному соглашению об именах. Это легко позволяет инструментам автоматически определять и обновлять содержание bean’ов.

.

+ на данном соглашении работают куча различных сериализаторов xml/json, JPA

+ простые приставки к методам get и set сразу говорят для чего эти методы.

З.Ы.
По честному, ручное прописывание getter-ов и setter-ов давно всем надоело и избыточно, потому в современных JVM языках, типа Groovy или Scala методы доступа генерируются автоматически компилятором. Для Java есть фреймверк Lombok, он позволяет автоматически генерировать методы доступа к полям.

Как парсить

Как обычно - читаем и разбираем. Размер тут большого значения не играет.

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

Java - лидер в толстом и жирном энтерпрайзе. Go молодой ЯП и ещё не особо обкатанный

Если проект с серьезным бюджетом, то кусочек дата-центра, балансировщик нагрузки в виде железки от f5 (https://f5.com/products/platforms/appliances). В программной части nginx - проверенное решение (если распределить его на 20 нодах с балансировкой, то нагрузка вытекает 12000 * 20). Что будет за фронтендом полностью зависит от архитектуры Вашего приложения (там может быть шардинг, еще один балансировщик и т.п.).
Если бюджет не позволяет, можете забыть о 10000rps (Вам в любом случае надо либо нанимать очень крутых программистов-спецов по высокой нагрузке, либо см. вариант выше). Берете любой облачный сервис (Amazon, Jelastic, etc) и разворачиваете виртуальную структуру там. Тамошняя производительность будет целиком зависеть от облака и вашего кода.

По поводу БД, не торопитесь, выбрасывать реляционные базы. Ознакомьтесь с опытом, например здесь www.sarahmei.com/blog/2013/11/11/why-you-should-ne... Не для каждой архитектуры подходят NoSQL.

Epam Luxoft они всегда в поисках негров. Но опыт дают хороший для начала.

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

Вы только подумайте:
Для каждого юзера нужно создавать аккаунт, систему авторизации, восстановление пароля и пр.;
Необходимо разграничить права доступа для каждого юзера - кто что может делать со своим блогом, а что с чужим;
При загрузке изображений необходимо предусмотреть загрузку как с компьютера, так и со сторонних ресурсов, нужен ресайз и подгонка под определенные размеры, контроль типа загружаемого файла, удобный просмотр фотографий и т.д., и т.п.;
Не только создание, но и редактирование и удаление как постов лога, так и фотографий;
Администрирование всего этого добра (мало ли кто и что начнет заливать);
...
И много-много еще всяческих нюансов учесть, описание которых составит не одну страницу.

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

Программы на C/C++ работают быстрее за счёт отказа от контроля всего и вся (расхода памяти, переполнения стека, корректности указателей), за счёт явной и жёсткой типизации переменных, за счёт меньшего количества обёрток вокруг типов данных. Но это позволяет программисту выстрелить себе в ногу таким количеством способов, которые в Java и не снились.

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

executeQuery вызывается для SELECT запросов, которые возвращают результирующие наборы.
В вашем случае нужно использовать executeUpdate, который предназначен для команд UPDATE INSERT DELETE, которые результирующие наборы не возвращают.

Поделюсь взглядом со стороны программиста.

Вот мы делаем проект командой из 3-5 человек. Проект длинный, больше года. В итоге каждый отвечает только за свою часть, в чужой ничего не понимает. Некоторые вещи реализуются независимо два, а то и три(!) раза, потом с матами приходится рефакторить всё к единому виду.
Программисты не смотрят код друг-друга, потому что времени на это нет. Начальство ждёт продвижения по плану работ, на встрече тебя спрашивают: успеешь сделать вот это за N дней? Ты прикидываешь на пальцах, умножаешь время на pi, как положено, и говоришь «да успею». В итоге даже успеваешь, но посмотреть чужой код времени не остаётся почти.
Из плюсов совместной разработки: если один человек уходит в отпуск, другой сможет хотя бы собрать билд. Плюсов можно найти больше, если среди программистов найдётся человек, которому не пофиг. Тогда даже может появиться какая-никакая документация. Если всем пофиг, то без разницы, сколько человек будет работать над проектом — документация не появится. Извинте, наболело.

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

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