Robby Grossman, Shareaholic's Tech Lead, spoke at the first Boston Riak Meetup on August 30, 2012. These are his slides.

1. Riak @
Robby Grossman
robby@shareaholic.com
@freerobby

2. Agenda
Shareaholic: Product & Tech
Why Riak: The Search for a Big Data Store
Transitioning to Riak
Riak Use Cases
Deploying to EC2

3. What’s ?

4. Browser Tools

5. Sharing Buttons

6. Recommendations

7. Social Analytics

8. Monthly @
Thousands of developers hitting API
Hundreds of thousands of publishers
Tens of millions of shares & clicks
Hundreds of millions of pageviews & events

9. Tech @
JRuby on Rails (via Torquebox)
MySQL (Master, Read Slave)
Elastic MapReduce (similar to Hadoop)
Redis
Formerly Mongo, Now Riak

10. Why Not Mongo?
Working set needs to fit in memory
Global write lock blocks all queries
despite not having transactions/joins
Standbys not “hot”

11. Why Riak?

12. Next @
Options: Goals:
HBase Linear scalability
Cassandra Full-text search
Riak Flexible indexing
Easier Devops

13. HBase
Pros Cons
Battle tested Complex
Architecture
High performance
SPOFs
Requires Hive for
Indexing/Querying
Expensive to deploy
at small scale

14. Cassandra
Pros Cons
Native secondary Known users all
indices domain experts
Linear scalability Search requires
Lucene
Tunable CAP
Heavy Weight
MapReduce

15. Riak
Pros Cons
Operationally simpler Multi-data center
replication requires
Linear scalability Enterprise product
Integrated search leveldb puts high
strain on CPU
Secondary indices
Tunable CAP
Vector clocks solve
time-sync problems

16. From Mongo to Riak

17. Migration Goals
No time where database goes “offline”
Product parity throughout migration

18. Migration Process
1. App writes to Mongo and Riak
2. Verify data integrity
3. Import historical data
4. App reads from Riak
5. Decommission Mongo

19. Use Cases

20. Share API
Save shared content
Uses MapReduce to
populate user dashboard

21. Recommendations
Sets of related pages
Generated on-demand

22. Publisher Analytics
Generated nightly via Hadoop
Typical stored “document” (JSON)
80kb-1Mb

23. Riak Successes

24. MapReduce
Handy for querying
Runs at “web page speed”.
Easy to re-reduce for complex queries
Easy to test via CURL

25. Tunable CAP @
Replication: primary/secondary authority
Read failure tolerance: speed/consistency
Write failure tolerance

26. Full Text Search
Built on Lucene
Make user content searchable
Make arbitrary keys queryable
“Just turn it on”
Hiccup: corrupt merge indexes

27. Query Example
Who’s our oldest user who’s shared something in the last minute?
curl -XPOST http://localhost:8098/mapred -H 'Content-Type: application/json' -d '{
"inputs": {
"bucket":"links",
"query":"timestamp:[1346350877 TO 1346350937}" //60 second period
},
"query":[
{"map":{"language":"javascript","source":"function(riakObject) {
return [[Riak.mapValuesJson(riakObject)[0].user_id]];
}"}},
{"reduce":{"language":"javascript",
"name":"Riak.reduceMin" // [[2],[5],[9],[13]] => [[2]]
}}
]
}'
[[2197]]

28. Riak on EC2

29. In a Nutshell
EC2 specs poorly proportioned for leveldb
Multiple AZs in one location works well
Scale vertically for better latency & consistency
Scale horizontally for more throughput/$

30. Benchmarks
Top Graph: c1.medium (1.7G, 5 CPU)
Middle: m1.large (7.5G, 4 CPU)
Bottom: cc1.4xlarge (23G, 33.5 CPU)

31. Throughput

32. Latency (Typical)

33. Latency (Worst Case)

34. Calculations
c1.medium (1.7G, 5 CPU)
1758 IOPS/$-hr
Worst 1% of queries: 300ms/800ms
m1.large (7.5G, 4 CPU)
1167 IOPS/$-hr
Worst 1% of queries: 110ms/200ms
cc1.4xlarge (23G, 33.5 CPU)
872 IOPS/$-hr
Worst 1% of queries: 47ms/139ms

35. Benchmark Takeaways
You can’t go “by spec”
IO is limiting factor
RAM never limiting factor for 1%
of keyspace to be in memory

36. Fin. Questions?
Thanks: We’re Hiring!
Tom Santero Robby Grossman
Justin Sheehy robby@shareaholic.com
Ryan Zezeski @freerobby
Reid Draper
#freenode riak crew

37. Fin.