GIDS2014: SolrCloud: Searching Big Data
โขDownload as ODP, PDFโข
1 likeโข1,767 views
These slides were presented at the Great Indian Developer Summit 2014 at Bangalore. See http://www.developermarch.com/developersummit/session.html?insert=ShalinMangar2 "SolrCloud" is the name given to Apache Solr's feature set for fault tolerant, highly available, and massively scalable capabilities. SolrCloud has enabled organizations to scale, impressively, into the billions of documents with sub-second search!
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to GIDS2014: SolrCloud: Searching Big Data
Similar to GIDS2014: SolrCloud: Searching Big Data (20)
Recently uploaded
Recently uploaded (20)
GIDS2014: SolrCloud: Searching Big Data
- 1. SolrCloud: Searching Big Data Shalin Shekhar Mangar
- 2. Subset of o ptio nal featuresin Solr to enableand simplify horizontal scaling asearch index using sharding and replication. Goals performance, scalability, high-availability, simplicity, and elasticity What is SolrCloud?
- 3. Terminology โ ZooKeeper: Distributed coordination servicethat providescentralized configuration, cluster state management, and leader election โ Node: JVM processbound to aspecific port on amachine; hoststheSolr web application โ Collection: Search index distributed acrossmultiple nodes; each collection hasaname, shard count, and replication factor โ Replication Factor: Number of copiesof adocument in acollection
- 4. โข Shard: Logical sliceof acollection; each shard hasaname, hash range, leader, and replication factor. Documentsareassigned to oneand only oneshard per collection using ahash-based document routing strategy โข Replica: Solr index that hostsacopy of ashard in acollection; behind thescenes, each replicaisimplemented asaSolr core โข Leader: Replicain ashard that assumesspecial dutiesneeded to support distributed indexing in Solr; each shard hasoneand only oneleader at any timeand leadersareelected using ZooKeeper Terminology
- 6. Collection == Distributed Index A collection isa distributed index defined by: โข named configuration stored in ZooKeeper โข number of shards: documents are distributed across N partitions of the index โข document routing strategy: how documents get assigned to shards โข replication factor: how many copiesof each document in thecollection
- 7. Collections API: http://localhost:8983/solr/admin/collections? action=create&name=logstash4solr&replicationFactor= 2&numShards=2&collection.configName=logs Collection == Distributed Index
- 8. โ Collection has a fixed number of shards - existing shardscan besplit โ When to shard? - Largenumber of docs - Largedocument sizes - Parallelization during indexing and queries - Datapartitioning (custom hashing) Sharding
- 9. โ Each shard coversahash-range โ Default: Hash ID into 32-bit integer, map to range - leadsto balanced (roughly) shards โ Custom-hashing (examplein afew slides) โ Tri-level: app!user!doc โ Implicit: no hash-rangeset for shards Document Routing
- 10. โข Why replicate? - High-availability - Load balancing โ How does it work in SolrCloud? - Near-real-time, not master-slave - Leader forwards to replicas in parallel, waits for response - Error handling during indexing is tricky Replication
- 13. 1. Get cluster statefrom ZK 2. Routedocument directly to leader (hash on doc ID) 3. Persist document on durable storage(tlog) 4. Forward to healthy replicas 5. Acknowledgewrite succeed to client Distributed Indexing
- 14. โ Additional responsibilitiesduring indexing only! Not a master node โ Leader isareplica(handlesqueries) โ Acceptsupdaterequestsfor theshard โ Incrementsthe_version_ on thenew or updated doc โ Sendsupdates(in parallel) to all replicas Shard Leader
- 15. Distributed Queries 1. Query client can beZK awareor just query viaaload balancer 2. Client can send query to any nodein the cluster 3. Controller nodedistributesthequery to areplicafor each shard to identify documentsmatching query 4. Controller nodesortstheresultsfrom step 3 and issuesasecond query for all fieldsfor apageof results
- 16. Scalability / Stability Highlights โ All nodesin cluster perform indexing and execute queries; no master node โ Distributed indexing: No SPoF, high throughput via direct updatesto leaders, automated failover to new leader โ Distributed queries: Add replicasto scale-out qps; parallelizecomplex query computations; fault-tolerance โ Indexing / queriescontinueso long asthereis1 healthy replicaper shard
- 17. SolrCloud and CAP โ A distributed system should be: Consistent, Available, and Partition tolerant โ CAPsayspick 2 of the3! (slightly morenuanced than that in reality) โ SolrCloud favorsconsistency over write-availability (CP) โ All replicasin ashard havethesamedata โ Activereplicasetsconcept (writesaccepted so long asa shard hasat least oneactivereplicaavailable)
- 18. SolrCloud and CAP โข No toolsto detect or fix consistency issuesin Solr โ Reads go to one replica; no concept of quorum โ Writes must fail if consistency cannot be guaranteed (SOLR-5468)
- 19. ZooKeeper โ Isavery good thing ... clustersareazoo! โ Centralized configuration management โ Cluster statemanagement โ Leader election (shard leader and overseer) โ Overseer distributed work queue โ LiveNodes โ Ephemeral znodesused to signal aserver isgone โ Needs3 nodesfor quorum in production
- 20. ZooKeeper: Centralized Configuration โ Storeconfig filesin ZooKeeper โ Solr nodespull config during coreinitialization โ Config setscan beโsharedโ acrosscollections โ Changesareuploaded to ZK and then collectionsshould bereloaded
- 21. ZooKeeper: State Management โ Keep track of /live_nodesznode โ Ephemeral nodes โ ZooKeeper client timeout โ Collection metadataand replicastatein /clusterstate.json โ Every corehaswatchersfor /live_nodesand /clusterstate.json โ Leader election โ ZooKeeper sequencenumberson ephemeral znodes
- 22. Overseer โ What doesit do? โ Persistscollection statechangeeventsto ZooKeeper โ Controller for Collection API commands โ Ordered updates โ Oneper cluster (for all collections); elected using leader election โ How doesit work? โ Asynchronous(pub/sub messaging) โ ZooKeeper asdistributed queuerecipe โ Automated failover to ahealthy node โ Can beassigned to adedicated node(SOLR-5476)
- 23. Custom Hashing โ Routedocumentsto specific shardsbased on ashard key component in thedocument ID โ Send all log messagesfrom thesamesystem to the sameshard โ Direct queriesto specific shards: q=...&_route_=httpd { "id" : โhttpd!2", "level_s" : โERROR", "lang_s" : "en", ... }, Hash: shardKey!docID
- 24. Custom Hashing Highlights โ Co-locatedocumentshaving acommon property in thesame shard - e.g. docshaving IDshttpd!21 and httpd!33 will bein thesameshard โข Scale-up thereplicasfor specific shardsto addresshigh query and/or indexing volumefrom specific apps โข Not asmuch control over thedistribution of keys - httpd, mysql, and collectd all in same shard โข Can split unbalanced shards when using custom hashing
- 25. โข Can split shards into two sub-shards โข Live splitting! No downtime needed! โข Requests start being forwarded to sub-shards automatically โข Expensive operation: Use as required during low traffic Shard Splitting
- 26. Other features / highlights โข Near-Real-Time Search: Documentsarevisiblewithin a second or so after being indexed โข Partial Document Update: Just updatethefieldsyou need to changeon existing documents โข Optimistic Locking: Ensureupdatesareapplied to thecorrect version of adocument โข Transaction log: Better recoverability; peer-sync between nodes after hiccups โข HTTPS โข Use HDFS for storing indexes โข UseMapReduce for building index (SOLR-1301)
- 27. More? โข Workshop: Apache Solr in Minutes tomorrow โข https://cwiki.apache.org/confluence/display/solr/Ap ache+Solr+Reference+Guide โข shalin@apache.org โข http://twitter.com/shalinmangar โข http://shal.in
- 28. Attributions โข Tim Potter's slides on โIntroduction to SolrCloudโ at Lucene/Solr Exchange 2014 โ http://twitter.com/thelabdude โข Erik Hatcher's slides on โSolr: Search at the speed of lightโ at JavaZone 2009 โ http://twitter.com/ErikHatcher