Где хранить данные веб-искателя?

У меня есть простой веб-искатель, который начинается с root (данный url) загружает html корневой страницы, затем сканирует гиперссылки и обходит их. В настоящее время я храню html-страницы в базе данных SQL. В настоящее время я столкнулся с двумя проблемами:

Похоже, что обход достигает узкого места и не способен быстрее сканировать, я где-то читал, что создание многопоточных HTTP-запросов на страницы может заставить сканер сканировать быстрее, но я не уверен в как это сделать.
Вторая проблема: мне нужна эффективная структура данных для хранения html-страниц и возможность запуска их операций с данными (в настоящее время с использованием базы данных SQL хотелось бы услышать другие рекомендации)

Я использую .Net framework, С# и MS SQL

Ответ 1

Итак, в первую очередь, я бы не стал беспокоиться о том, чтобы попасть в распределенное сканирование и хранение, потому что, как следует из названия, для этого требуется приличное количество машин для получения хороших результатов. Если у вас нет фермы компьютеров, то вы не сможете извлечь из этого выгоду. Вы можете создать искатель, который получает 300 страниц в секунду и запускает его на одном компьютере с подключением 150 Мбит/с.

Следующая вещь в списке - определить, где ваше узкое место.

Контрольная точка вашей системы

Попробуйте устранить MS SQL:

Загрузите список, скажем, 1000 URL-адресов, которые вы хотите обходить.
Определите, как быстро вы можете их обходить.

Если 1000 URL-адресов не дают вам достаточно большой обход, то получите 10000 URL-адресов или 100 тыс. URL-адресов (или если вы чувствуете себя храбрыми, то получите Alexa top 1 млн.). В любом случае, попытайтесь установить базовую линию с максимально возможными исключениями.

Определить узкое место

После того, как у вас есть базовая линия для скорости сканирования, попробуйте определить, что вызывает замедление. Кроме того, вам нужно будет начать использовать многоуровневое управление, потому что вы привязаны к i/o, и у вас есть много свободного времени между извлечением страниц, которые вы можете потратить на извлечение ссылок и выполнение других действий, таких как работа с базой данных.

Сколько страниц в секунду вы получаете сейчас? Вы должны попробовать и получить более 10 страниц в секунду.

Улучшить скорость

Очевидно, следующий шаг - как можно больше настроить ваш искатель:

Попытайтесь ускорить работу своего искателя, чтобы он преодолел жесткие ограничения, например, вашу пропускную способность.
Я бы рекомендовал использовать асинхронные сокеты, так как они МНОГО быстрее, чем блокирующие сокеты, WebRequest/HttpWebRequest и т.д.
Используйте более быструю библиотеку разбора HTML: начинайте с HtmlAgilityPack, и если вы чувствуете себя храбрым, попробуйте Majestic12 HTML Parser.
Используйте встроенную базу данных, а не базу данных SQL и воспользуйтесь хранилищем ключей/значений (хешируйте URL-адрес ключа и храните HTML-код и другие соответствующие данные как значение).

Go Pro!

Если вы освоили все вышеперечисленное, я бы предложил попробовать попробовать! Важно, чтобы у вас был хороший алгоритм выбора, который имитирует PageRank, чтобы сбалансировать свежесть и охват: OPIC в значительной степени является последним и самым большим в этом отношении (AKA Adaptive Расчет эффективности страниц в Интернете). Если у вас есть вышеуказанные инструменты, вы должны иметь возможность реализовать OPIC и запускать довольно быстрый искатель.

Если вы гибки на языке программирования и не хотите слишком далеко отклоняться от С#, тогда вы можете попробовать сканеры уровня предприятия на основе Java, такие как Nutch. Nutch интегрируется с Hadoop и всеми другими масштабируемыми решениями.

Ответ 2

Это то, для чего был разработан Google BigTable. HBase - популярный клон с открытым исходным кодом, но вам нужно иметь дело с Java и (возможно) с Linux. Cassandra также написан на Java, но работает в Windows. Оба позволяют .NET-клиенты.

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

Если вам не нравится инфраструктура Java, вы можете посмотреть в Microsoft Azure Table Storage для аналогичных характеристик. Это решение для хостинга/облака, хотя вы не можете запускать его на своем собственном оборудовании.

Как для обработки данных, если вы идете на HBase или Cassandra, вы можете использовать Hadoop MapReduce. MR был популяризирован Google точно для задачи, которую вы описываете, - обрабатывая огромное количество веб-данных. Короче говоря, идея состоит в том, что вместо того, чтобы запускать ваш алгоритм в одном месте и передавать все данные через него, MapReduce отправляет вашу программу на работу на машинах, где хранятся данные. Он позволяет запускать алгоритмы в основном неограниченном количестве данных, предполагая, что у вас есть оборудование для него.