I've got experience doing large scale web crawling. Its a
interesting, but time consuming endeavor. In the long term, its
better to write your own crawler and have your own db. But depending
on the size of your team, that could take a year by itself. If you're
in the prototyping stage, Matt's advice to use search API's definitely
makes the most sense.
-Abuna
Crawling random blogs and comments is going to be a Hard Problem
(TM). If you can pick a site like Blogger.com, and decide to scrape
that, it becomes a bit easier, but you're still talking about scraping
and indexing millions of web pages. You might be better off setting
up Google alerts for the specific terms that you're looking for, and
then scraping the results that come up and indexing those.
Mind you, if you're well funded, and don't mind spinning up a bunch of
EC2 instances to do that kind of crawling, that becomes a big issue.
Indexing those results rapidly becomes a Big Data problem. If you
think of a web page being 20kb of text x 1,000,000 blog posts a day ==
20GB of data a day that you're just crawling and then indexing. After
8 months, you have a Terabyte of data that you're having to deal with
and move around.
You're also probably looking at using Cassandra, or Hadoop/Hbase as a
back end for a data store. You're also looking at using a lot of map/
reduce to do the indexing for you.
It sounds like an interesting problem, however. I'm tackling a
similar problem in that I want to search and index financial news for
http://Newsley.com. I'm going to be pulling RSS feeds, and running
them through an http://OpenCalais.com api, however.
I'd love to hear more about what you're doing.
Best,
Jonathan