couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Partition query endpoints in CouchDB 4.0
Date Tue, 21 Apr 2020 21:01:37 GMT
On Adam's point that the partitioned query api encourages good choices ("discourages hot spots"),
that's only true for folks that read the documentation, which in my experience is a low percentage
of folks. I've encountered a heavy user of partitioned dbs that had precisely four partitions
in mind, for millions of docs (They chose "doc_type" as their partition value).

My view for 4.0 is;

1) ignore the partitioned flag when creating databases
2) the "partitioned" property no longer reported in GET /dbname
3) the various _partition endpoints still work
4) all views work either "global" or "partitioned" depending on the endpoint used.

for 5.0 I'm +0 on removing the _partition endpoints, but we can take that vote at the time
based on contemporary feedback.

B.

> On 21 Apr 2020, at 21:35, Robert Samuel Newson <rnewson@apache.org> wrote:
> 
> Hi,
> 
> Good points on both sides of this. One thing we can hopefully get agreement on is the
?partitioned=true flag on creation and, deeper, the lack of distinction between the two "types"
of database going forward?
> 
> B.
> 
>> On 21 Apr 2020, at 18:51, Garren Smith <garren@apache.org> wrote:
>> 
>> I'm on the fence when it comes to removing it. In terms of the original
>> plan of making querying faster by querying fewer shards that obviously
>> isn't needed. But I think it does create a nice mental model/design pattern
>> when building an application in CouchDB.  Splitting your data into
>> partitions that contain similar documents makes sense. And once we on FDB
>> it would be awesome to see if we could have a changes feed per partition.
>> That would be a really nice feature.
>> 
>> Cheers
>> Garren
>> 
>> On Tue, Apr 21, 2020 at 5:51 PM Adam Kocoloski <kocolosk@apache.org> wrote:
>> 
>>> I think it’s difficult to make a call when 3.0 is still so new.
>>> 
>>> The case for deprecation here is basically less code to maintain, right?
>>> It’s not like a user of partitioned databases is causing pain for an
>>> FDB-based CouchDB; if anything, there’s a second-order benefit because the
>>> partitioning discourages hot spots from forming in the (range-partitioned)
>>> FDB keyspace.
>>> 
>>> Cheers, Adam
>>> 
>>>> On Apr 20, 2020, at 11:51 PM, Kyle Snavely <kjsnavely@gmail.com> wrote:
>>>> 
>>>> My two cents is the same. Let's allow 3.* users migrate to 4.* without
>>>> needing to e.g. change the PQ part of their application and remove the PQ
>>>> endpoints in 5.0.
>>>> 
>>>> Best,
>>>> Kyle
>>>> 
>>>> On Mon, Apr 20, 2020, 4:16 PM Ilya Khlopotov <iilyak@apache.org> wrote:
>>>> 
>>>>> Given that it unlikely that there are too many people using it and it
is
>>>>> being noop in FDB world. I think we should deprecate and remove
>>> _partition
>>>>> endpoint.
>>>>> 
>>>>> On 2020/04/20 21:04:58, Robert Samuel Newson <rnewson@apache.org>
>>> wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> I'd like to get views on whether we should preserve the _partition
>>>>> endpoints in CouchDB 4.0 or remove them. In CouchDB 4.0 all _view and
>>> _find
>>>>> queries will automatically benefit from the same performance boost that
>>> the
>>>>> "partitioned database" feature brings, by virtue of FoundationDB.
>>>>>> 
>>>>>> If we're preserving it, are we also deprecating it (so it's gone
in
>>> 5.0)?
>>>>>> 
>>>>>> If we're ditching it, what will the endpoint return instead (404
Not
>>>>> Found, 410 Gone?)
>>>>>> 
>>>>>> Thoughts welcome.
>>>>>> 
>>>>>> B.
>>>>> 
>>> 
>>> 
> 


Mime
View raw message