Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastMail's Email Search Architecture

blog.fastmail.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: FastMail's Email Search Architecture

#11

Post by brongondwana »

brongondwana wrote: post #10

An obvious question that I didn't hit on in the blog is "what about host crashes"? The nice thing is, every index knows exactly which messages it covers - and we can quite quickly (within an hour or so for an entire server) scan all mailboxes and index the missing messages - it's more efficient than doing it in a real time, because you are often indexing multiple messages in the same mailbox. Once the indexes are up…

(during a clean shutdown, we copy all the indexes over to the SSD, and they get compacted to data in the next day's compact run)

Re: FastMail's Email Search Architecture

#12

Post by robn_fastmail »

alfiedotwtf wrote: post #9
ams6110 wrote: post #5

Earlier quoted context omitted.

For me it would be the use of Java. I've just had too much bad luck with it. Admittedly that's not really very objective reasoning.

From memory (sorry, it was a while back) we actually started with Elasticsearch, but it was way to heavy and looked for an alternative solution. Even with a single user it was consuming way too much memory.

Sorry Alfie, your memory fails. We started with Sphinx.

We use Elasticsearch elsewhere (ELK stack), but not for mail search.

Re: FastMail's Email Search Architecture

#13

Post by brongondwana »

kolev wrote: post #8

Although in the past I've implemented Xapian [1] over Sphinx [2], Sphinx today seems to be much better, but both Xapian and Sphinx are under-appreciated compared to Solr [3] and Elasticsearch [4]. [1] http://xapian.org/ [2] http://sphinxsearch.com/ [3] http://lucene.apache.org/solr/ [4] http://www.elasticsearch.org/

All of those last three are awesome if you either put all the user's search indexes into a single engine, or have a shit-ton of memory.

With sphinx, we found we had to start and stop daemons all over the place to manage memory, and it was just unworkable. It was either that or run one big index per machine, but there are operational reasons I'd rather not be doing that. We try to keep everything user-sized.

That said, there's still stub Sphinx code in there. Both engines are have GPL licensing on them, which means compiling against Cyrus (BSD licensed) causes a non-BSD licensed end result. Not an issue for us, since we publish all our Cyrus code anyway.

There is talk of building an Elasticsearch backed into Cyrus as well - feel free, it's all open source. We'd definitely take the patch if it's good code (he says with his Cyrus Project Board Member hat on rather than his FastMail Director hat on)

Re: FastMail's Email Search Architecture

#14

Post by microtonal »

ams6110 wrote: post #3

If you want Xapian search on a local maildir, I highly recommend notmuch[1]. Adding new mail and updating the index can take noticable time, but searching is super fast, it allows easy custom tagging, and search results are better than gmail in my experience. I use it from the emacs notmuch mode. [1] http://notmuchmail.org/

I use notmuch, but mu should also be mentioned in the same breath :):

http://www.djcbsoftware.nl/code/mu/ http://www.djcbsoftware.nl/code/mu/mu4e.html

Re: FastMail's Email Search Architecture

#15

Post by gregnbanks »

ams6110 wrote: post #3

If you want Xapian search on a local maildir, I highly recommend notmuch[1]. Adding new mail and updating the index can take noticable time, but searching is super fast, it allows easy custom tagging, and search results are better than gmail in my experience. I use it from the emacs notmuch mode. [1] http://notmuchmail.org/

I never used notmuch, but I was much inspired by it when I saw a talk about it at linux.conf.au a few years back. Later I ended up stealing several ideas from notmuch about how to interface with Xapian, like the one-letter prefixes.

Re: FastMail's Email Search Architecture

#16

Post by gregnbanks »

pmoriarty wrote: post #6
ams6110 wrote: post #3

If you want Xapian search on a local maildir, I highly recommend notmuch[1]. Adding new mail and updating the index can take noticable time, but searching is super fast, it allows easy custom tagging, and search results are better than gmail in my experience. I use it from the emacs notmuch mode. [1] http://notmuchmail.org/

Can notmuch do regular expression searches?

Xapian supports a query syntax which uses a trailing '*', but it's not a true wildcard/regexp, it's a range search on an ordered index. Notmuch allows you to use that syntax, see http://notmuchmail.org/searching/

Re: FastMail's Email Search Architecture

#18

Post by gregnbanks »

brongondwana wrote: post #13
kolev wrote: post #8

Although in the past I've implemented Xapian [1] over Sphinx [2], Sphinx today seems to be much better, but both Xapian and Sphinx are under-appreciated compared to Solr [3] and Elasticsearch [4]. [1] http://xapian.org/ [2] http://sphinxsearch.com/ [3] http://lucene.apache.org/solr/ [4] http://www.elasticsearch.org/

All of those last three are awesome if you either put all the user's search indexes into a single engine, or have a shit-ton of memory. With sphinx, we found we had to start and stop daemons all over the place to manage memory, and it was just unworkable. It was either that or run one big index per machine, but there are operational reasons I'd rather not be doing that. We try to keep everything user-sized. That said…

Sphinx also had a bunch of really bad bugs around server startup and shutdown, and some ugly code. I ended re-writing some of their pthreads code and submitting patches, I have no idea if they ever used them or not because their development tree is internal and not visible outside their company.

Solr (well, Lucene) has awesome natural language stemming abilities, many more languages supported than Xapian. In particular it's much smarter than Xapian about Chinese. But a) the memory requirement makes running multiple shards on the same machine hard, and b) nobody in the company wanted to learn how to handle Java operationally.

EDIT: since 2012 Sphinx appear to have made a public mirror of their internal tree at https://code.google.com/p/sphinxsearch/source/checkout

Re: FastMail's Email Search Architecture

#19

Post by darklajid »

ams6110 wrote: post #3

If you want Xapian search on a local maildir, I highly recommend notmuch[1]. Adding new mail and updating the index can take noticable time, but searching is super fast, it allows easy custom tagging, and search results are better than gmail in my experience. I use it from the emacs notmuch mode. [1] http://notmuchmail.org/

I'm always a bit jealous when I see this setup (or mu).

But I don't use emacs, and that seems to lead to subpar support and crazy hacks to get something up and working, unfortunately.

Re: FastMail's Email Search Architecture

#20

Post by microtonal »

darklajid wrote: post #19
ams6110 wrote: post #3

If you want Xapian search on a local maildir, I highly recommend notmuch[1]. Adding new mail and updating the index can take noticable time, but searching is super fast, it allows easy custom tagging, and search results are better than gmail in my experience. I use it from the emacs notmuch mode. [1] http://notmuchmail.org/

I'm always a bit jealous when I see this setup (or mu). But I don't use emacs, and that seems to lead to subpar support and crazy hacks to get something up and working, unfortunately.

But I don't use emacs,

Me neither, but mutt-kz had built-in support for notmuch. Not the hacky kind that calls 'notmuch', but it actually links against libnotmuch.

http://kzak.redcrew.org/doku.php?id=mutt:start

Post reply on HN