[jira] [Comment Edited] (SOLR-13101) Shared storage support in SolrCloud

["Yonik Seeley (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942890#comment-16942890 ] 

Yonik Seeley edited comment on SOLR-13101 at 10/2/19 3:10 PM:
--------------------------------------------------------------

bq. How far do you think is it complete? Do you forsee a lot of more work going in here? Or, do you suggest we start reviewing it and attempt to merge it soon (in a week or so?).

I think it's got a bit more to go.  It would be nice if the behavior matched normal solr semantics a little closer... would be easier to get better test coverage by reusing existing tests and changing the replica type.  Some things off the top of my head:
 - a commit doesn't cause latest changes to be visible on replicas (a query on a non-leader replica actually causes an async pull from blob of the latest index)
 - there are currently some concurrency issues with index pushing
 - I *think* one still needs to specify a commit to get a push to blob... this needs to be implicit (commit=true,openSearcher=false) for data durability by default
I need to dig into the code in general more... as you can see from the commits on the branch, this work was all done by my colleagues, not me.  But we're working on encouraging more open development!



was (Author: yseeley@gmail.com):
bq. How far do you think is it complete? Do you forsee a lot of more work going in here? Or, do you suggest we start reviewing it and attempt to merge it soon (in a week or so?).

I think it's got a bit more to go.  It would be nice if the behavior matched normal solr semantics a little closer... would be easier to get better test coverage by reusing existing tests and changing the replica type.  Some things off the top of my head:
 - a commit doesn't cause latest changes to be visible on replicas (a query on a non-leader replica actually causes an async pull from blob of the latest index)
 - there are currently some concurrency issues with index pushing
 - I 
I need to dig into the code in general more... as you can see from the commits on the branch, this work was all done by my colleagues, not me.  But we're working on encouraging more open development!


> Shared storage support in SolrCloud
> -----------------------------------
>
>                 Key: SOLR-13101
>                 URL: https://issues.apache.org/jira/browse/SOLR-13101
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>            Reporter: Yonik Seeley
>            Priority: Major
>          Time Spent: 4h
>  Remaining Estimate: 0h
>
> Solr should have first-class support for shared storage (blob/object stores like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, etc).
> The key component will likely be a new replica type for shared storage.  It would have many of the benefits of the current "pull" replicas (not indexing on all replicas, all shards identical with no shards getting out-of-sync, etc), but would have additional benefits:
>  - Any shard could become leader (the blob store always has the index)
>  - Better elasticity scaling down
>    - durability not linked to number of replcias.. a single replica could be common for write workloads
>    - could drop to 0 replicas for a shard when not needed (blob store always has index)
>  - Allow for higher performance write workloads by skipping the transaction log
>    - don't pay for what you don't need
>    - a commit will be necessary to flush to stable storage (blob store)
>  - A lot of the complexity and failure modes go away
> An additional component a Directory implementation that will work well with blob stores.  We probably want one that treats local disk as a cache since the latency to remote storage is so large.  I think there are still some "locking" issues to be solved here (ensuring that more than one writer to the same index won't corrupt it).  This should probably be pulled out into a different JIRA issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org