Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 188D710F76 for ; Mon, 9 Feb 2015 21:40:11 +0000 (UTC) Received: (qmail 82718 invoked by uid 500); 9 Feb 2015 21:40:10 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 82662 invoked by uid 500); 9 Feb 2015 21:40:10 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 82652 invoked by uid 99); 9 Feb 2015 21:40:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2015 21:40:10 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of billie.rinaldi@gmail.com designates 209.85.216.43 as permitted sender) Received: from [209.85.216.43] (HELO mail-qa0-f43.google.com) (209.85.216.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2015 21:39:44 +0000 Received: by mail-qa0-f43.google.com with SMTP id bm13so8925189qab.2 for ; Mon, 09 Feb 2015 13:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=q46+godpMcrl+pMN/eBfZFw5A2qaBRhA/KB34WLw0ls=; b=J5SbwU7fgx/vuATLZIEV+Mh3jrXGBgiG/8F07mavNgoYOuP/zVuAY2GH3t5ufg2ec6 btgsqg2ir/vbZlfaUlTsHpm11EMgTdoY4rk7LUoScAl8E4JcKSdccpAB0kSopgv/rshO lossBh6SvOsM98Jt16yVQM93JFnjH/O4uPmyK1N9i9eZnLg62O3geLq6TQOUtleb2rrQ fVd3dUM0ejrO2JG0eOlOvBr7Z62YO/j7plZTkRYgr8Yupw+rCSFHD9+bcnu1tSJV6uq/ Jma6rfjHm9Cl7xWUxXGn+SXNdCbLn6m8I2vjZYHg6+qkFNHZheq/48uKNF2luaBEdPv0 75yQ== MIME-Version: 1.0 X-Received: by 10.224.171.130 with SMTP id h2mr26113287qaz.78.1423517847140; Mon, 09 Feb 2015 13:37:27 -0800 (PST) Received: by 10.140.36.178 with HTTP; Mon, 9 Feb 2015 13:37:27 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 13:37:27 -0800 Message-ID: Subject: Re: Keys with identical timestamps From: Billie Rinaldi To: "user@accumulo.apache.org" Content-Type: multipart/alternative; boundary=047d7b2e7c009c45df050eae9374 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2e7c009c45df050eae9374 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 9, 2015 at 1:04 PM, Adam Fuchs wrote: > Hi Dave, > > As long as your combiner is associative and commutative both of the > values should be represented in the combined result. The > non-determinism is really around ordering, which generally doesn't > matter for a combiner. > Yes. However, do not attempt to insert identical keys in a single mutation. Only one will be kept, whether versioning is enabled or not. Billie > > Adam > > On Mon, Feb 9, 2015 at 3:49 PM, Dave Hardcastle > wrote: > > Hi, > > > > Could someone clarify whether the following statement from the manual - > "If > > two inserts are made into Accumulo with the same rowID, column, and > > timestamp, then the behavior is non-deterministic" - applies even if the > > versioning iterator is off? Is the non-determinism the fact that the > order > > is undetermined if two identical inserts are made and all versions are > kept? > > > > I have an application where the key corresponds to an object and a time > > range, and the value is properties of the object over that time range. > The > > time range is stored in the column qualifier, but I also put the end of > the > > time range as the timestamp of the key. I frequently get data late, and > so > > create a key and insert that, but that key may already exist in the > table. > > When multiple identical versions get put in, the values are aggregated > using > > a combiner. This seems to be working fine. But maybe I shouldn't be > assuming > > that Accumulo won't silently drop one of the two keys? > > > > Thanks, > > > > Dave. > --047d7b2e7c009c45df050eae9374 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 9, 2015 at 1:04 PM, Adam Fuchs <afuchs@apache= .org> wrote:
Hi Dave,

As long as your combiner is associative and commutative both of the
values should be represented in the combined result. The
non-determinism is really around ordering, which generally doesn't
matter for a combiner.

Yes.=C2=A0 Howev= er, do not attempt to insert identical keys in a single mutation.=C2=A0 Onl= y one will be kept, whether versioning is enabled or not.

Billie
=C2=A0

Adam

On Mon, Feb 9, 2015 at 3:49 PM, Dave Hardcastle
<hardcastle.dave@gmail.com<= /a>> wrote:
> Hi,
>
> Could someone clarify whether the following statement from the manual = - "If
> two inserts are made into Accumulo with the same rowID, column, and > timestamp, then the behavior is non-deterministic" - applies even= if the
> versioning iterator is off? Is the non-determinism the fact that the o= rder
> is undetermined if two identical inserts are made and all versions are= kept?
>
> I have an application where the key corresponds to an object and a tim= e
> range, and the value is properties of the object over that time range.= The
> time range is stored in the column qualifier, but I also put the end o= f the
> time range as the timestamp of the key. I frequently get data late, an= d so
> create a key and insert that, but that key may already exist in the ta= ble.
> When multiple identical versions get put in, the values are aggregated= using
> a combiner. This seems to be working fine. But maybe I shouldn't b= e assuming
> that Accumulo won't silently drop one of the two keys?
>
> Thanks,
>
> Dave.

--047d7b2e7c009c45df050eae9374--