You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by David Allsopp <dn...@gmail.com> on 2011/07/28 13:55:54 UTC
NotFoundException thrown for get(), but not get_slice() with a
column_names predicate
If I try to retrieve a column that is not present, using get(), then I'll
get a NotFoundException.
If (for efficiency's sake) I try to retrieve several named columns using
get_slice, with a column_names predicate (i.e. a list of columns) then I
won't get the exception if one of those columns is missing, I think?
This seems inconsistent - would it make sense for get_slice to throw the
exception too, or perhaps have an option to require all columns to be
present?
The reason this came up is that I write and read with CL.ONE, and retry at
the client side in case of (very occasional) failures, with the aim of
improving availability and performance by avoiding CL.QUORUM etc.
This is easy in the get() case - I can just retry a few times if I get a
NotFoundException. I normally only need to retry once, in less than 0.1% of
cases.
For the get_slice case I'd need to retrieve all the columns again (might be
wasteful) or check which ones were returned and form a new request (seems
overly complex) or give up using get_slice and just use individual get()
calls (seems inefficient).
See also https://issues.apache.org/jira/browse/CASSANDRA-518
Thanks,
David.
Re: NotFoundException thrown for get(), but not get_slice() with a
column_names predicate
Posted by David Allsopp <dn...@gmail.com>.
On 28 July 2011 16:23, Sylvain Lebresne <sy...@datastax.com> wrote:
> To be honest, collecting the names that were missing in the first name
> query and doing a new name query for those (if there is any) is so simple
> that I think it is a bit dishonest to say that "it pushes work to the
> clients".
>
>
It seems simple enough at least that it does not sound like a good idea to
> me to complicate the API.
>
> Fair point - I was forgetting that I need to implement basic retries
anyway, if I'm using CL.ONE, so the partial retries won't be much more
difficult, as you say. Though it does mean I need one kind of retry for
get() and another kind for get_slice(). Still getting used to eventual
consistency ;-)
> I'll also argue that throwing an exception is always inferior to the
> current
> behavior, because if you re-query the missing names and get nothing
> back again, you at least know what are the names that are not missing.
> If you throw an exception and you simply get the exception twice, you
> only know that "some" column(s) is(are) missing.
>
True - throwing an exception would be useful if you have large columns, need
all of the columns to do anything useful, and would rather not download 90%
of them only to throw them away for the lack of the last 10% (if some of the
columns may actually be absent as opposed to not-yet-consistent), but I
guess that's a pretty obscure edge case!!
Thanks,
David.
>
>
Re: NotFoundException thrown for get(), but not get_slice() with a
column_names predicate
Posted by Sylvain Lebresne <sy...@datastax.com>.
To be honest, collecting the names that were missing in the first name
query and doing a new name query for those (if there is any) is so simple
that I think it is a bit dishonest to say that "it pushes work to the clients".
It seems simple enough at least that it does not sound like a good idea to
me to complicate the API.
I'll also argue that throwing an exception is always inferior to the current
behavior, because if you re-query the missing names and get nothing
back again, you at least know what are the names that are not missing.
If you throw an exception and you simply get the exception twice, you
only know that "some" column(s) is(are) missing.
--
Sylvain
On Thu, Jul 28, 2011 at 4:53 PM, David Allsopp <dn...@gmail.com> wrote:
> I understand and agree for the case where the slice predicate is a range,
> but I'd expect the semantics to be different where the predicate is a list
> of column names (even if it's implemented using a range operation under the
> hood?)
>
> If I ask for columns "foo" and "bar", then usually I'm not trying to find
> out what's in a particular range - I actually want columns "foo" AND "bar",
> i.e. the semantics are basically those of a set of individual column get()
> calls.
>
> I could do these as individual get() calls, but want to minimise
> round-trips.
>
> I can of course check what column were returned and try again or give up,
> but this pushes work to the clients; in the worst case this could transfer
> large amounts of unusable data back to the client, which then has to discard
> it all (and perhaps retry and discard all over again) due to the absence of
> one small column. It would save a lot of bandwidth to abandon the operation
> immediately at the server if a 'missing' column is detected there.
>
> Of course, in some use cases one might want to get whichever of the columns
> names happen to exist ("foo" AND/OR "bar"), hence my suggestion that it
> should be possible to choose between these two semantics when using a
> column_names predicate (clearly, this doesn't make sense for a slice_range
> predicate).
>
> On 28 July 2011 13:45, Jonathan Ellis <jb...@gmail.com> wrote:
>>
>> No, the slice semantics are "give me whatever happens to exist between
>> start and end." It's valid for the answer to be "nothing."
>>
>> On Thu, Jul 28, 2011 at 6:55 AM, David Allsopp <dn...@gmail.com>
>> wrote:
>> > If I try to retrieve a column that is not present, using get(), then
>> > I'll
>> > get a NotFoundException.
>> >
>> > If (for efficiency's sake) I try to retrieve several named columns using
>> > get_slice, with a column_names predicate (i.e. a list of columns) then I
>> > won't get the exception if one of those columns is missing, I think?
>> >
>> > This seems inconsistent - would it make sense for get_slice to throw the
>> > exception too, or perhaps have an option to require all columns to be
>> > present?
>> >
>> >
>> > The reason this came up is that I write and read with CL.ONE, and retry
>> > at
>> > the client side in case of (very occasional) failures, with the aim of
>> > improving availability and performance by avoiding CL.QUORUM etc.
>> > This is easy in the get() case - I can just retry a few times if I get a
>> > NotFoundException. I normally only need to retry once, in less than 0.1%
>> > of
>> > cases.
>> >
>> > For the get_slice case I'd need to retrieve all the columns again (might
>> > be
>> > wasteful) or check which ones were returned and form a new request
>> > (seems
>> > overly complex) or give up using get_slice and just use individual get()
>> > calls (seems inefficient).
>> >
>> > See also https://issues.apache.org/jira/browse/CASSANDRA-518
>> >
>> > Thanks,
>> >
>> > David.
>> >
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>
>
Re: NotFoundException thrown for get(), but not get_slice() with a
column_names predicate
Posted by David Allsopp <dn...@gmail.com>.
I understand and agree for the case where the slice predicate is a range,
but I'd expect the semantics to be different where the predicate is a list
of column names (even if it's implemented using a range operation under the
hood?)
If I ask for columns "foo" and "bar", then usually I'm not trying to find
out what's in a particular range - I actually want columns "foo" AND "bar",
i.e. the semantics are basically those of a set of individual column get()
calls.
I could do these as individual get() calls, but want to minimise
round-trips.
I can of course check what column were returned and try again or give up,
but this pushes work to the clients; in the worst case this could transfer
large amounts of unusable data back to the client, which then has to discard
it all (and perhaps retry and discard all over again) due to the absence of
one small column. It would save a lot of bandwidth to abandon the operation
immediately at the server if a 'missing' column is detected there.
Of course, in some use cases one might want to get whichever of the columns
names happen to exist ("foo" AND/OR "bar"), hence my suggestion that it
should be possible to choose between these two semantics when using a
column_names predicate (clearly, this doesn't make sense for a slice_range
predicate).
On 28 July 2011 13:45, Jonathan Ellis <jb...@gmail.com> wrote:
> No, the slice semantics are "give me whatever happens to exist between
> start and end." It's valid for the answer to be "nothing."
>
> On Thu, Jul 28, 2011 at 6:55 AM, David Allsopp <dn...@gmail.com>
> wrote:
> > If I try to retrieve a column that is not present, using get(), then I'll
> > get a NotFoundException.
> >
> > If (for efficiency's sake) I try to retrieve several named columns using
> > get_slice, with a column_names predicate (i.e. a list of columns) then I
> > won't get the exception if one of those columns is missing, I think?
> >
> > This seems inconsistent - would it make sense for get_slice to throw the
> > exception too, or perhaps have an option to require all columns to be
> > present?
> >
> >
> > The reason this came up is that I write and read with CL.ONE, and retry
> at
> > the client side in case of (very occasional) failures, with the aim of
> > improving availability and performance by avoiding CL.QUORUM etc.
> > This is easy in the get() case - I can just retry a few times if I get a
> > NotFoundException. I normally only need to retry once, in less than 0.1%
> of
> > cases.
> >
> > For the get_slice case I'd need to retrieve all the columns again (might
> be
> > wasteful) or check which ones were returned and form a new request (seems
> > overly complex) or give up using get_slice and just use individual get()
> > calls (seems inefficient).
> >
> > See also https://issues.apache.org/jira/browse/CASSANDRA-518
> >
> > Thanks,
> >
> > David.
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>
Re: NotFoundException thrown for get(), but not get_slice() with a
column_names predicate
Posted by Jonathan Ellis <jb...@gmail.com>.
No, the slice semantics are "give me whatever happens to exist between
start and end." It's valid for the answer to be "nothing."
On Thu, Jul 28, 2011 at 6:55 AM, David Allsopp <dn...@gmail.com> wrote:
> If I try to retrieve a column that is not present, using get(), then I'll
> get a NotFoundException.
>
> If (for efficiency's sake) I try to retrieve several named columns using
> get_slice, with a column_names predicate (i.e. a list of columns) then I
> won't get the exception if one of those columns is missing, I think?
>
> This seems inconsistent - would it make sense for get_slice to throw the
> exception too, or perhaps have an option to require all columns to be
> present?
>
>
> The reason this came up is that I write and read with CL.ONE, and retry at
> the client side in case of (very occasional) failures, with the aim of
> improving availability and performance by avoiding CL.QUORUM etc.
> This is easy in the get() case - I can just retry a few times if I get a
> NotFoundException. I normally only need to retry once, in less than 0.1% of
> cases.
>
> For the get_slice case I'd need to retrieve all the columns again (might be
> wasteful) or check which ones were returned and form a new request (seems
> overly complex) or give up using get_slice and just use individual get()
> calls (seems inefficient).
>
> See also https://issues.apache.org/jira/browse/CASSANDRA-518
>
> Thanks,
>
> David.
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com