Архитектура приложений типа datanyze.com?

Question

[Twindo]

Как организованна архитектура в таких проектах как www.datanyze.com (приложение занимается тем, что обходит миллионы сайтов ежедневно и собирает информацию по технологиям, которая на этих сайтах используется) и т.п.

Интересует как архитектура в целом, так и конкретные моменты: работа с сетью (используются ли iocp (for windows)или epoll (для *nix) или какие-либо другие технологии), работа с БД (какая БД лучше подойдет для таких задач), фрэймворки для организации заданий и их мониторинг, перезапуск заданий после аварийного завершения и т.п.

Если у кого-то есть примеры, вообще было бы здорово.

Answer 1

[Виталий Пухов]

не понятно кому такая информация нужна " в виде сервиса", ну собрали один раз.. в год , выложили в виде картинки с графиками дальше сервис теряет смысл, но если очень хочется задача не особо сложная, сбор данных в 99% случаев простейший парсинг по "отпечаткам" "технологий", с хранением проблем тоже нет ибо "миллионы сайтов" это 1 табличка с несколькими миллионами строк, любая БД это скушает и не подавится, фрэймвор нужно определять только после того как будет определено что именно он будет делать, для абстрактного коня в вакууме такое не советуют, в простейшем случае для своего фреймворка достаточно написать отдельный класс в управляемой среде (Java\.net), который будет держать выполняемое задание в блоке try и тогда "аварийное завершение" будет невозможно впринципе, т.к. любой крэш будет отлавливаться на уровне менеждера задач, на C# подобный написан строк в 50 максимум.

Comments

[Twindo]

Насчет нужности такой информации можно глянуть хотябы пример кейса из статьи на хабре habrahabr.ru/company/cloverr/blog/217117 (Компания KISSmetrics, и у них главный конкурент – компания Mixpanel. Ребята из KISSmetrics каждый день отслеживали, кто начинал использовать Mixpanel и просто звонил всем тем и предлогали рассмотреть их продукт.) Это всего лишь один из кейсов на самом деле их гораздо больше. Но не об этом речь.

Конечно можно написать простенький код обхода миллиона сайтов, к примеру, в 200-350 потоков и сохранять все в бд изпользуюя пул. Но, как мне кажется, подобные стартапы явно разрабатывают не так. Да и одной таблицей там тоже не обойтись. Ведь приложение должно проектироваться с расчетом на изменение требований: что если сайтов станет не миллион а 100 миллионов, признаков для фингерпринта более 10,000 и т.д. Под аварийным завершением я подразумевал скорее проблемы на аппаратном уровне (сбой сети, и т.п.). Потоковая модель так же со временем может упереться в ограничения железа, поэтому возможно нужно смотреть в сторону iocp для widows или epoll для *nix систем, но тогда между парсером и базой должна, я думаю, появиться прослойкак в виде очереди. Так как с таким потоком дисковая подсистема может не справится. DNS резолвинг тоже может стать одной из проблем при работе с огромным кол-вом доменов. Ну, и т.д. и т.п.

Хотелось услышать именно об этих тонкостях.

[Виталий Пухов]

Twindo: мысль понял, выходит это фактически услуга "поиска заинтерисованных клиентов". Все вышеперечисленное универсально я думаю решить нельзя, но на уровне проектирования решается легко.
Для легкой масштабируемости нужно отделить массив сайтов от массива результатов, далее пишется процедура, которая "резервирует" часть массива для отработки и передает их одному из серверов кластера, отдельный сервер отрабатывает свою "порцию данных" и складывает в отдельный массив, сервер результатов собирает данные с массивов и концентрирует у себя. В целом получается комплекс из N серверов обработки, и 2 или более серверов хранения, либо кластеров SQL. Все этапы отработки независимы между собой и практически не вызывают конфликта доступа. Реализуется легко например на платформе Azure, масштабирование получается "из коробки".