0
Realtime Search
Infrastructure
sphinx at craigslist
!
Jeremy Zawodny
@jzawodn
https://github.com/jzawodn
http://blog.zawod...
About Me
at craigslist since mid-2008!
first major project: “fix search”!
Perl, search, MySQL, redis, MongoDB, data,
backend...
About craigslist
engineering culture!
no product managers or marketing!
< 50 employees!
self-hosted infrastructure we own ...
Search
Outline
challenges!
history of search at craigslist!
lessons!
questions?
Challenges
indexing rate (incoming volume)!
thousands of postings per minute!
churn and half-life!
traffic (always increasi...
History
search 1.0: Perl + DBM (2000-2002)!
search 2.0: MySQL Full-Text (2002-2008)!
search 3.0: sphinx master/slave (2008...
Evolution
needs and desires are changing!
sphinx is improving!
hardware is more capable!
learn from previous mistakes!
it’...
MySQL Full-Text
MySQL Full-Text
used up until late 2008!
manual sharding!
performance was poor (easy to DoS)!
often fell off a cliff!
limi...
Sphinx
Sphinx
awesome!
speaks MySQL
protocol!
amazingly fast
indexing!
very fast queries!
easy to understand!
programmer
friendly...
Sphinx Tools
searchd: the sphinx server process!
multi-threaded or pre-forking!
indexer: build batch indexes off-line!
ind...
Master/Slave Sphinx
one index per city!
growth by sharding into 2 then 3 clusters!
masters build indexes every 10 minutes!...
Master/Slave Sphinx
master slave2
slave1
slave3
Postings DB
web1
web2
web3
web4
web5
web6
Hardware Upgrade!
Autonomous Sphinx
24 cores, 72GB RAM, 300GB SSD!
combine master and slave onto single node!
eliminate SPOF!
no replication...
Autonomous Sphinx
Autonomous Sphinx
slave2
slave1
slave3
Postings DB
web1
web2
web3
web4
web5
web6
Real-Time Sphinx
RT indexes in sphinx have matured!
reduce overhead from the searchd restart!
reduce time to search from p...
Sphinx Clusters
Live: what you use!
highest traffic, volume, churn!
Team: what we use!
lowest traffic, lots of extra data!
F...
Ram & Disk Chunks
Indexes begin as “ram chunks”!
rt_mem_limit caps their size!
once too large, they become “disk chunks”!
...
Lessons
stopwords: google has spoiled users!
MONITOR ALL THE THINGS!!1!!
Mind your rt_mem_limit!
Keep it all in RAM!
Make ...
Questions?
While you ask, keeping in mind...!
craigslist is hiring!
front-end developers!
systems and network admins!
back...
Upcoming SlideShare
Loading in...5
×

Realtime Search Infrastructure at Craigslist (OpenWest 2014)

8,121

Published on

A brief history of search infrastructure at craigslist with an emphasis on our recent transition to using realtime (RT) indexing in Sphinx.

Published in: Engineering, Technology
1 Comment
22 Likes
Statistics
Notes
No Downloads
Views
Total Views
8,121
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
84
Comments
1
Likes
22
Embeds 0
No embeds

No notes for slide

Transcript of "Realtime Search Infrastructure at Craigslist (OpenWest 2014)"

  1. 1. Realtime Search Infrastructure sphinx at craigslist ! Jeremy Zawodny @jzawodn https://github.com/jzawodn http://blog.zawodny.com/ Jeremy@Zawodny.com
  2. 2. About Me at craigslist since mid-2008! first major project: “fix search”! Perl, search, MySQL, redis, MongoDB, data, backend services! previously: Yahoo! and Marathon Oil! wrote 1st edition of High Performance MySQL
  3. 3. About craigslist engineering culture! no product managers or marketing! < 50 employees! self-hosted infrastructure we own & manage! no “cloud” or virtualization! multi-datacenter! driven by user needs and feedback
  4. 4. Search
  5. 5. Outline challenges! history of search at craigslist! lessons! questions?
  6. 6. Challenges indexing rate (incoming volume)! thousands of postings per minute! churn and half-life! traffic (always increasing)! peak over 4,000 queries/second! query multipliers (new features)! spreading the load! sharding and partitioning
  7. 7. History search 1.0: Perl + DBM (2000-2002)! search 2.0: MySQL Full-Text (2002-2008)! search 3.0: sphinx master/slave (2008-2011)! search 4.0: autonomous sphinx (2011-2013)! search 5.0: realtime sphinx (2013 - today)
  8. 8. Evolution needs and desires are changing! sphinx is improving! hardware is more capable! learn from previous mistakes! it’s fun to do new things :-)! searching > browsing
  9. 9. MySQL Full-Text
  10. 10. MySQL Full-Text used up until late 2008! manual sharding! performance was poor (easy to DoS)! often fell off a cliff! limited query syntax! MyISAM corruption
  11. 11. Sphinx
  12. 12. Sphinx awesome! speaks MySQL protocol! amazingly fast indexing! very fast queries! easy to understand! programmer friendly! open source! great support! stable
  13. 13. Sphinx Tools searchd: the sphinx server process! multi-threaded or pre-forking! indexer: build batch indexes off-line! indextool: check indexes and get details! search: diagnostic tool for simple searches
  14. 14. Master/Slave Sphinx one index per city! growth by sharding into 2 then 3 clusters! masters build indexes every 10 minutes! used indexer and perl scripts to generate XML! build versioning and rollback mechanism! slaves pull indexes via rsync and reload! used pre-forking config! hardware was dual proc, dual core AMD Opterons with 32GB RAM
  15. 15. Master/Slave Sphinx master slave2 slave1 slave3 Postings DB web1 web2 web3 web4 web5 web6
  16. 16. Hardware Upgrade!
  17. 17. Autonomous Sphinx 24 cores, 72GB RAM, 300GB SSD! combine master and slave onto single node! eliminate SPOF! no replication delay! simplify codebase! better utilization of hardware
  18. 18. Autonomous Sphinx
  19. 19. Autonomous Sphinx slave2 slave1 slave3 Postings DB web1 web2 web3 web4 web5 web6
  20. 20. Real-Time Sphinx RT indexes in sphinx have matured! reduce overhead from the searchd restart! reduce time to search from posting going live! goal < 10 seconds! eliminate XML generation code! use MySQL protocol
  21. 21. Sphinx Clusters Live: what you use! highest traffic, volume, churn! Team: what we use! lowest traffic, lots of extra data! Forums: yes, we have threaded discussions! low volume, low traffic! Archive: posting more than a few months old! terabytes of indexes, constantly growing
  22. 22. Ram & Disk Chunks Indexes begin as “ram chunks”! rt_mem_limit caps their size! once too large, they become “disk chunks”! obviously, disk is slower than RAM! the more chunks, the more docs to check! query times fall, CPU use rises...
  23. 23. Lessons stopwords: google has spoiled users! MONITOR ALL THE THINGS!!1!! Mind your rt_mem_limit! Keep it all in RAM! Make re-indexing easy! Automate cloning
  24. 24. Questions? While you ask, keeping in mind...! craigslist is hiring! front-end developers! systems and network admins! back-end developers! send me your resume: z@craigslist.org! https://www.craigslist.org/about/craigslist_is_hiring
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×