Architecture - pritykovskaya/UniRank GitHub Wiki

Diagram

Используемые технологии:

  • Сборщик: Ant
  • Индексация: Lucene
  • База данных: MySQL, JDBC
  • Admin interface: SQuirrel
  • Backend: Spring, Jetty
  • Frontend: xslt

Параметры нагрузки:

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

Основной сценарий работы системы:

Данные собираются из интернета и складываются в сыром виде в базу raw. Далее происходит унификация, кластеризация и ранжирование данных. Результат складывается в базу main. После этого indexer собирает из данных main поколение, состоящее из локальной базы данных и Lucene индекса. Это поколение помещается на backend, который обрабатывает запросы frontend'а. Frontend отвечает на запросы пользователей. Формирует запрос к backend'у и на основе полученных данных с помощью xslt преобразования получает результирующий html. Кроме этого пользователь может оставлять отзывы по университетам, которые отправляются frontend'ом на reviewBackend, который в свою очередь складывает эти отзывы в базу данных reviewDB. Данные из reviewDB используются в процессе ранжирования.

Понимание этапов развития системы:

  1. Сделать так, чтобы проект работал в холостую, т.е. вместо автоматического сбора - спецробот(ы) / webharvest, вместо сложных алгоритмов семантической обработки - просто заглушка перегоняюшая из одной базы в другую.

А вот процесс создания поколения(индексации), обработка запросов frontend'a backend'ом, взаимодействие frontend'a с пользователями должны быть реолизованы хорошо, чтобы в дальнейшем они изменялись по минимуму.

  1. А также, если мы действительно хотим добавить возможность пользователем оставлять свои отзывы, то этим надо также заняться на этом этапе, потому что потом будет сложнее вспомнить как взаимодействуют frontend c (Review)backend'ом, а также как (Review)backend c (Review)DB.

  2. После того как проект заведется, заняться в плотную усовершенствованием алгоритмамов сбора и обработки данных.

  3. Формула для ранжирования.

  4. Деление информации на группы.

  5. Составление персональных рейтингов с учетом выставленных пользоваелем весов.

Спектр работы системы:

масштабируемость, т.е. нужно чтобы мощность системы на всех стадиях могла увеличится за счет добавления новых хостов.

Точки отказа. Что может пойти не так? Как на это реагировать?

  • Интернет. Если происходит ошибка в сети (упал нужный нам сайт, отказано в доступе и т.п.), то она от нас никак не зависит. Возможным выходом из ситуации может быть работа с альтернативными источниками информации (дублировать источники, сделать так чтобы можно было одинаковую информацию добывать из разных мест)

  • Сбор. Если по каким-то причинами информация не была собрана (не распарсилась страница, не поступила в "сырую" базу), то можно воспользоваться тем, что этот процесс не зависит от деятельности пользователя, выполняется в "фоновом" режиме и почти постоянно (либо с определенной частотой). Будем с не меньшей частотой проверять наличие данных (во втором случае).

  • Хранение. Если падает БД, это плохо - наш сервис подразумевает всегда свежие и актуальные данные. Выход - хранить данные распределенно и дублировать.

  • Обработка. Если вдруг что-то не обработалось или не проанализировалось, то либо у нас не верный алгоритм, либо данные не в том формате. В первом случае виноваты руки, и поможет может наличие менее эффективных, но более стабильных заглушек, срабатывающих в случае ошибок. Во втором - надо бежать в БД (или вообще в сборщик или парсер) и смотреть, что там произошло.