Solr Power FTW: Powering NoSQL the World Over
0 likes445 views
The document presents a presentation by Alex Pinkin on the use of Solr as a NoSQL solution, highlighting its capabilities in handling large-scale user-generated content at Bazaarvoice, such as processing over 20,000 queries per second. It covers key aspects of Solr, including its non-relational model, horizontal scaling, performance tuning, and deployment challenges. The discussion emphasizes Solr's strengths, weaknesses, and essential configuration settings to optimize performance.
Solr Power FTW: Powering NoSQL the World Over
- 1. Solr Power FTW Alex Pinkin @apinkin #solrnosql
- 2. What Will I Cover? ● Who I am ● What Bazaarvoice does ● SOLR and NoSQL ● Can SOLR handle 20K queries per second? ● Lessons learned: large scale multi data center deployment ● Conclusion
- 3. Alex Pinkin ● Software Engineering Lead, Data Infrastructure team, Bazaarvoice ● Loves to play with SQL and NoSQL @apinkin
- 4. Bazaarvoice ● Bazaarvoice is a software as a service company powering user generated content such as ratings and reviews on thousands of web sites ● 5 billion page views per month ● 230 billion impressions ● 75 million UGC
- 5. NoSQL ?
- 6. SQL vs NoSQL
- 7. NoSQL is Not Only SQL ● Departs from relational model ● No fixed schema ● No joins ● Eventual consistency is OK ● Scale horizontally
- 8. Types of NoSQL ● Key-value (Redis, Riak, Voldemort) ● Document (MongoDB, CouchDB) ● Graph (Neo4J, FlockDB) ● Column family (Cassandra, HBase)
- 9. SOLR as NoSQL ● Non-relational model - Check ● No fixed schema - Check (dynamic fields) ● No joins - Check (denormalization) ● Horizontal scaling - Check (with work)
- 10. SOLR stats - Bazaarvoice Documents 250 MM Index size 200 GB QPS, avg 2,350 QPS, max 10,200 Response time, avg 12 ms Servers 6+20
- 11. SOLR Case Study
- 12. SOLR Case Study
- 13. Life Before SOLR ● Indexes for sorting and filtering ● Aggregate tables for stats ● Nightly jobs ● Bugs...
- 14. Enter SOLR ● Index content and product catalog ● De-normalization ● Filtering and sorting ● Index every 15 minutes (20 seconds NRT)
- 15. SOLR - Statistics ● COUNT, SUM, AVG, MIN, MAX (StatsComponent) ● Stored fields ● Whenever content changes, re-calc stats for all affected subjects
- 16. Scaling reads - Replication
- 17. Replication - Multiple Data Centers
- 18. Replication - Multiple Data Centers Chatty if using multiple cores Relay ● Core auto-warming disabled ● Connection wait and read timeouts increased ● Replication poll interval increased (15 min) ● Compression enabled ... <str name="httpConnTimeout">20000</str> <str name="httpReadTimeout">65000</str> <str name="pollInterval">00:15:00</str> <str name="compression">internal</str> ...
- 19. SOLR Cloud - Bazaarvoice version ● Multiple cores (100+ per server) ● Re-balance indexes across cores and servers ○ Automatic ○ Manual ● Deployment map stored in MySQL ○ Host - Core - Partition ○ Statistics ● Partition lifecycle
- 20. Schema Changes Re-indexing is time consuming for large indexes Process 1. Full re-index off-line 2. Incremental indexing prior to release 3. Incremental indexing after the release Bottleneck: reading from MySQL Goal: Transparent re-indexing
- 21. Performance Tuning ● Heap size ● Cache sizing ● Auto-warming ● Stored fields ● Merge factor ● Commit frequency ● Optimize frequency Process: Simulate and measure ● Replay logs ● Analyze metrics ● Monitor GC
- 22. Performance Tuning - GC # Java memory usage settings # Force the NewSize to be larger than the JVM typically allocates. # In practice, the JVM has been allocating an extremely small Young generation which objects to be prematurely promoted to the Tenured generation JAVA_MEM_OPTS="-Xms27g -Xmx27g -XX:NewRatio=8" # -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps --> Turn on GC Logging # -XX:+UseConcMarkSweepGC --> Use the concurrent collector # -XX:+CMSIncrementalMode --> Incremental mode for the concurrent collector # -XX:+CMSIncrementalPacing --> Let the JVM adjust the amount of incremental collection JAVA_GC_OPTS="-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX: +UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=55 -XX: ParallelGCThreads=8 -XX:SurvivorRatio=4"
- 23. SOLR Performance - Summary ● SOLR loves RAM! ● Log replay SOLR ● Same config, same hardware ● Get the most out of one instance
- 24. Conclusion - SOLR Strengths ● Lightning fast given enough RAM ● Good scale out support including multi-data center ● Great community
- 25. Conclusion - SOLR's Gaps ● Not fully elastic ● Real time takes work ● Secondary data store = sync overhead ● Schema changes
- 26. Questions @apinkin