5 ms·

>What do you reckon the cost of doing this would be? That is indeed the key question. I tried to find out before commenting but the information I found is very

>What do you reckon the cost of doing this would be? That is indeed the key question. I tried to find out before commenting but the information I found is very vague. Internet Archive spends millions per year, but their index is updated far too slowly for a search engine. I have no idea what it costs to create a Google-size index. Do you think the Mojeek index is good enough to compete with Google?

marginalia_nu 3y ago
> Do you think the Mojeek index is good enough to compete with Google? As a back-end for something like Kagi, it's sure getting there. Most of what sets Google apart is their exceptional level of user profiling. The actual indexing technology is likely on par with most of their competition. Of course very little of that enters into API queries.
neurostimulant 3y ago
Internet archive snapshot the whole page while google only index the first few kb of text data on every page (forgot the number, was it 100kb max per page?), so maybe it'll cost lower to build a search engine index compared to an internet preservation project? Assuming they'll need to index 820 billion pages (the number of pages preserved in the internet archive), at 100kb each, and assuming they use a database with 0.3x text data compression efficiency, they'll need at least 24600 TB to store those text data. Assuming $300 per 16TB disk, then they'll need to spend at least $7,380,000 for disk alone. This is a lot of money just for storage and we haven't included stuff like replication and backup, indexing metadata overhead, etc.
- DeathArrow 3y ago
  > Internet archive snapshot the whole page while google only index the first few kb of text data Is that a good way to build an index?
- ricardo81 3y ago
  >100kb max per page? They changed that limit somewhere in the mid-2000s. Just as well, there's some CMS's out there where there's several hundred kilobytes of inline JS and CSS before any body text.
- marginalia_nu 3y ago
  A search engine doesn't index the HTML code. You're looking at a few Kb per document. You also don't need multiple historical snapshots of the document like WM retains. So you're looking at maybe 20 bn docs, 4 Kb each. 100 Tb, before compression.
  - fauigerzigerk 3y ago
    True, but then Google doesn't just download the page source and index that. They run JavaScript in some cases to get to the actual content. This must come at a significant cost. Their index is enormous as well: "The Google Search index contains hundreds of billions of web pages and is well over 100,000,000 gigabytes in size." https://www.google.com/intl/en_uk/search/howsearchworks/how-search-works/organizing-information https://www.google.com/intl/en_uk/search/howsearchworks/how-... Doesn't mean you have to be as big as Google to do something useful of course.
    - marginalia_nu 3y ago
      Sure, download and run the javascript, but then you can snapshot the DOM, grab the text, and discard all the rest. The HTML and js is of little practical value for the index after that point. Google's index is likely very large because they don't have any real economic incentives to keeping it small.
      - fauigerzigerk 3y ago
        >... but then you can snapshot the DOM, grab the text, and discard all the rest Yes, absolutely, I didn't mean to imply otherwise. But first you have to figure out what you can discard beyond the HTML tags themselves to avoid indexing all the garbage that is on each and every page. When I tried to do this I came to the conclusion that I needed to actually render the page to find out where on the page a particular piece of text was, what font size it had, if it was even visible, etc. And then there's JavaScript of course. So what I'm saying is that storing a couple of kilobytes is probably not the most costly part of indexing a page.
- leoedin 3y ago
  This seems like a good use case for some sort of spam filtering. Maybe the web is that big, but what percentage of it is data someone will ever care about? I wonder if you could make a good-enough search with agressive filtering of pages before they enter the index.
- DeathArrow 3y ago
  >so maybe it'll cost lower to build a search engine index compared to an internet preservation project? An index is just hashmap of words and list of urls. So you have to parse the page, and add the urls and word frequencies to the list. In terms of storage is cheaper, in terms of computing power is more expensive.
  - marginalia_nu 3y ago
    A hash table is not a good backing structure for a search engine. Hash tables almost guarantee worst case disk read patterns. You use something like a skip list or a b-tree, since that's makes much better use of the hardware, and on top of that allows you to do incredibly fast joins.
    - DeathArrow 3y ago
      That's true, but I was referring to a hash table as a mere mental model, not an actual implementation. A better name would be a dictionary instead of hash table.
      - fomine3 3y ago
        Perl culture here.
ColinHayhurst 3y ago
Google started becoming an answer engine from ~2015 with the introduction of "People Also Ask", and arguably earlier than that [0]. Mojeek.com is a (information retrieval) search engine, and we resist the temptation to also become an answer engine. So you might say we do not compete with Google. afte all we have a very different business model and proposition. As for the index; this underpins mojeek.com and our API; which customers use for search and/or AI. Common Crawl is ~3.5 billion pages and underpins LLMs. Our index is ~7 billion. Who knows what (else) Google, and Bing, do with their index ;) ? [0] https://blog.mojeek.com/2023/05/generative-ai-threatens-diversity-and-hyperlinks.html https://blog.mojeek.com/2023/05/generative-ai-threatens-dive...
- fauigerzigerk 3y ago
  >Google started becoming an answer engine from ~2015 with the introduction of "People Also Ask", and arguably earlier than that [0]. Mojeek.com is a (information retrieval) search engine, and we resist the temptation to also become an answer engine. So you might say we do not compete with Google. I'm sure you know your users well after so many years in the search engine business, but having read your article I must say I find your approach risky. You seem to be betting on search engines and answer engines continuing to be complementary rather than substitutes. But we are not the ones making this decision. Users will be making the decision in light of the newly available AI capabilities, and they will be making it with complete disregard for the health of the web, as is their nature :) The "funny" thing is that big publishers are as happy right now as I haven't seen them in the past 25 years, because it is so completely obvious that chat AIs will destroy the web unless big tech starts making big payments to big publishers. As you rightly say, small businesses and publishers will be collateral damage. But how do you make sure you're not collateral damage as well?
  - marginalia_nu 3y ago
    It's basically the safest position you could be in. An LLM to digest results of a classic search index is greater than the sum of its parts. An LLMs that is not permitted to brush up on the relevant literature before answering a question generally doesn't produce very good answers, is prone to hallucinations etc. A pure LLM design isn't even a serious contender in the answer engine space.

marginalia_nu 3y ago

> Do you think the Mojeek index is good enough to compete with Google? As a back-end for something like Kagi, it's sure getting there. Most of what sets Google apart is their exceptional level of user profiling. The actual indexing technology is likely on par with most of their competition. Of course very little of that enters into API queries.

neurostimulant 3y ago

Internet archive snapshot the whole page while google only index the first few kb of text data on every page (forgot the number, was it 100kb max per page?), so maybe it'll cost lower to build a search engine index compared to an internet preservation project? Assuming they'll need to index 820 billion pages (the number of pages preserved in the internet archive), at 100kb each, and assuming they use a database with 0.3x text data compression efficiency, they'll need at least 24600 TB to store those text data. Assuming $300 per 16TB disk, then they'll need to spend at least $7,380,000 for disk alone. This is a lot of money just for storage and we haven't included stuff like replication and backup, indexing metadata overhead, etc.

DeathArrow 3y ago
> Internet archive snapshot the whole page while google only index the first few kb of text data Is that a good way to build an index?
ricardo81 3y ago
>100kb max per page? They changed that limit somewhere in the mid-2000s. Just as well, there's some CMS's out there where there's several hundred kilobytes of inline JS and CSS before any body text.
marginalia_nu 3y ago
A search engine doesn't index the HTML code. You're looking at a few Kb per document. You also don't need multiple historical snapshots of the document like WM retains. So you're looking at maybe 20 bn docs, 4 Kb each. 100 Tb, before compression.
- fauigerzigerk 3y ago
  True, but then Google doesn't just download the page source and index that. They run JavaScript in some cases to get to the actual content. This must come at a significant cost. Their index is enormous as well: "The Google Search index contains hundreds of billions of web pages and is well over 100,000,000 gigabytes in size." https://www.google.com/intl/en_uk/search/howsearchworks/how-search-works/organizing-information https://www.google.com/intl/en_uk/search/howsearchworks/how-... Doesn't mean you have to be as big as Google to do something useful of course.
  - marginalia_nu 3y ago
    Sure, download and run the javascript, but then you can snapshot the DOM, grab the text, and discard all the rest. The HTML and js is of little practical value for the index after that point. Google's index is likely very large because they don't have any real economic incentives to keeping it small.
    - fauigerzigerk 3y ago
      >... but then you can snapshot the DOM, grab the text, and discard all the rest Yes, absolutely, I didn't mean to imply otherwise. But first you have to figure out what you can discard beyond the HTML tags themselves to avoid indexing all the garbage that is on each and every page. When I tried to do this I came to the conclusion that I needed to actually render the page to find out where on the page a particular piece of text was, what font size it had, if it was even visible, etc. And then there's JavaScript of course. So what I'm saying is that storing a couple of kilobytes is probably not the most costly part of indexing a page.
leoedin 3y ago
This seems like a good use case for some sort of spam filtering. Maybe the web is that big, but what percentage of it is data someone will ever care about? I wonder if you could make a good-enough search with agressive filtering of pages before they enter the index.
DeathArrow 3y ago
>so maybe it'll cost lower to build a search engine index compared to an internet preservation project? An index is just hashmap of words and list of urls. So you have to parse the page, and add the urls and word frequencies to the list. In terms of storage is cheaper, in terms of computing power is more expensive.
- marginalia_nu 3y ago
  A hash table is not a good backing structure for a search engine. Hash tables almost guarantee worst case disk read patterns. You use something like a skip list or a b-tree, since that's makes much better use of the hardware, and on top of that allows you to do incredibly fast joins.
  - DeathArrow 3y ago
    That's true, but I was referring to a hash table as a mere mental model, not an actual implementation. A better name would be a dictionary instead of hash table.
    - fomine3 3y ago
      Perl culture here.

ColinHayhurst 3y ago

Google started becoming an answer engine from ~2015 with the introduction of "People Also Ask", and arguably earlier than that [0]. Mojeek.com is a (information retrieval) search engine, and we resist the temptation to also become an answer engine. So you might say we do not compete with Google. afte all we have a very different business model and proposition. As for the index; this underpins mojeek.com and our API; which customers use for search and/or AI. Common Crawl is ~3.5 billion pages and underpins LLMs. Our index is ~7 billion. Who knows what (else) Google, and Bing, do with their index ;) ? [0] https://blog.mojeek.com/2023/05/generative-ai-threatens-diversity-and-hyperlinks.html https://blog.mojeek.com/2023/05/generative-ai-threatens-dive...

fauigerzigerk 3y ago
>Google started becoming an answer engine from ~2015 with the introduction of "People Also Ask", and arguably earlier than that [0]. Mojeek.com is a (information retrieval) search engine, and we resist the temptation to also become an answer engine. So you might say we do not compete with Google. I'm sure you know your users well after so many years in the search engine business, but having read your article I must say I find your approach risky. You seem to be betting on search engines and answer engines continuing to be complementary rather than substitutes. But we are not the ones making this decision. Users will be making the decision in light of the newly available AI capabilities, and they will be making it with complete disregard for the health of the web, as is their nature :) The "funny" thing is that big publishers are as happy right now as I haven't seen them in the past 25 years, because it is so completely obvious that chat AIs will destroy the web unless big tech starts making big payments to big publishers. As you rightly say, small businesses and publishers will be collateral damage. But how do you make sure you're not collateral damage as well?
- marginalia_nu 3y ago
  It's basically the safest position you could be in. An LLM to digest results of a classic search index is greater than the sum of its parts. An LLMs that is not permitted to brush up on the relevant literature before answering a question generally doesn't produce very good answers, is prone to hallucinations etc. A pure LLM design isn't even a serious contender in the answer engine space.