Twitter's New Search Architecture
Twitter launched a new backend for search on twitter.com during the last few weeks.
Twitters real-time search engine was, until very recently, based on the technology that Summize originally developed. However, scaling the old MySQL-based system had become increasingly challenging. About 6 months ago, Twitter decided to develop a new search architecture that is based on a highly efficient inverted index instead of a relational database. Twitter chose Lucene, a search engine library written in Java, as a starting point.
Twitter's demands on the new system are immense: With over 1,000 TPS (Tweets/sec) and 12,000 QPS (queries/sec) = over 1 billion queries per day (!) Twitter already put a very high load on our machines. In addition to these scalability requirements, Twitter also need to support extremely low indexing latencies (the time it takes between when a Tweet is tweeted and when it becomes searchable) of less than 10 seconds. Since the indexer is only one part of the pipeline a Tweet has to make it through, Twitter needed the indexer itself to have a sub-second latency.
However, Lucene has several shortcomings for real-time search. Thats why Twitter rewrote big parts of the core in-memory data structures, especially the posting lists, while still supporting Lucenes standard APIs. This allows Twitter to use Lucenes search layer almost unmodified. Some of the highlights of the changes include:
* significantly improved garbage collection performance
* lock-free data structures and algorithms
* posting lists, that are traversable in reverse order
* efficient early query termination
Twitter estimates that it is only using about 5% of the available backend resources. Twitter's new indexer could also index roughly 50 times more Tweets per second than Twitter currently gets.
The first difference users might notice is the bigger index, which is now twice as long -- without making searches any slower. And, maybe most importantly, the new system is versatile and extensible, which will allow Twitter to build new features faster and better.
Twitter's demands on the new system are immense: With over 1,000 TPS (Tweets/sec) and 12,000 QPS (queries/sec) = over 1 billion queries per day (!) Twitter already put a very high load on our machines. In addition to these scalability requirements, Twitter also need to support extremely low indexing latencies (the time it takes between when a Tweet is tweeted and when it becomes searchable) of less than 10 seconds. Since the indexer is only one part of the pipeline a Tweet has to make it through, Twitter needed the indexer itself to have a sub-second latency.
However, Lucene has several shortcomings for real-time search. Thats why Twitter rewrote big parts of the core in-memory data structures, especially the posting lists, while still supporting Lucenes standard APIs. This allows Twitter to use Lucenes search layer almost unmodified. Some of the highlights of the changes include:
* significantly improved garbage collection performance
* lock-free data structures and algorithms
* posting lists, that are traversable in reverse order
* efficient early query termination
Twitter estimates that it is only using about 5% of the available backend resources. Twitter's new indexer could also index roughly 50 times more Tweets per second than Twitter currently gets.
The first difference users might notice is the bigger index, which is now twice as long -- without making searches any slower. And, maybe most importantly, the new system is versatile and extensible, which will allow Twitter to build new features faster and better.
