Return-Path: X-Original-To: apmail-gora-dev-archive@www.apache.org Delivered-To: apmail-gora-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 72A05108D9 for ; Thu, 26 Feb 2015 20:18:08 +0000 (UTC) Received: (qmail 13873 invoked by uid 500); 26 Feb 2015 20:18:08 -0000 Delivered-To: apmail-gora-dev-archive@gora.apache.org Received: (qmail 13841 invoked by uid 500); 26 Feb 2015 20:18:08 -0000 Mailing-List: contact dev-help@gora.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@gora.apache.org Delivered-To: mailing list dev@gora.apache.org Received: (qmail 13824 invoked by uid 99); 26 Feb 2015 20:18:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2015 20:18:08 +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 lewis.mcgibbney@gmail.com designates 209.85.223.176 as permitted sender) Received: from [209.85.223.176] (HELO mail-ie0-f176.google.com) (209.85.223.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2015 20:17:43 +0000 Received: by iecat20 with SMTP id at20so20485666iec.12; Thu, 26 Feb 2015 12:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2f7deB4PFz5QOOw8VYvrULma8vLSyYmP0fnKNbjatiU=; b=SWqlw8DBw6gR7lvQrR7h4uC9tNH4ZOCae8YlJYJBQQ2ChdqGBf8WlObQlZ8dig+6VV tOHuKaPvfvht/Cq3Fy86UbxhL9y9bU/IVG2ofleUzh3108dXWbenRyhy9bDTia0gdNV2 N9GONZmJS2pp6lWMVMdYkmla+qCPtAj6agYN4jrrkBYGm3iFtZ+MZ2QoYovDWktCDsKY YNW6dI94bg0gxpSnRsb1ulbTTtWGMyOJ7crZMcrJxz92JKUhDPPUFlNXg1eY2Axhrt+m F5H67MbAlsak17SurbKLI48rlftYvDE/Z13aN3SmrP9HLJfvVmfd2l+2FEWmrPRxgDzZ yr5Q== MIME-Version: 1.0 X-Received: by 10.107.47.216 with SMTP id v85mr13861964iov.86.1424981816288; Thu, 26 Feb 2015 12:16:56 -0800 (PST) Received: by 10.36.95.212 with HTTP; Thu, 26 Feb 2015 12:16:56 -0800 (PST) Date: Thu, 26 Feb 2015 12:16:56 -0800 Message-ID: Subject: Re: Dynamically generating HBase columns From: Lewis John Mcgibbney To: dev-digest@gora.apache.org Cc: "" Content-Type: multipart/alternative; boundary=001a11351bc6f8bc690510036e30 X-Virus-Checked: Checked by ClamAV on apache.org --001a11351bc6f8bc690510036e30 Content-Type: text/plain; charset=UTF-8 Hi Alfonso, On Tue, Feb 24, 2015 at 10:27 PM, wrote: > > In my use cases I always need a mix between static and dynamic columns. > In my first week I tried to mix a Map over a column family overlapped with > static columns. Didn't work because Gora was not prepared for that (and > indeed needs thinking about it further). > Yeah. I've logged the following focus to deal with it https://issues.apache.org/jira/browse/GORA-413 > > What I do is separate the static columns in one column family (or serveral) > from the dynamic stuff (that goes in a map). One Map is mapped to one > column family in which each column:value is key=>value in the map. > I have several maps depending on my needs, but can be just one big one with > key=column. > Can you please show this graphically so I am absolutely clear on what you are doing? > > What I don't fully understand is the timestamp you talk about, since we > don't handle HBase timestamps. Do you specifically need it? > Yes, please read comment on GORA-413 > > I'm not quite sure if I answer you :S > We will clarify it soon. Don;t worry ;) > > Something important to ask is much columns will you store in the column > family? > Well dynamic columns will be added with every incoming chunk of data. > Since we removed the StateManager, when you modify a map it deletes the > column familiy and sends all the data again to be written ( > > https://github.com/apache/gora/blob/master/gora-hbase/src/main/java/org/apache/gora/hbase/store/HBaseStore.java#L289 > ), > so adding/removing just one column can be quite killing when persisting > several huge maps. About what volume and write pattern are we talking? > The volume of data will not be so large however it is concerning that entire column families are deleted and re-written. It seems like a waste of time and resources which we should address in an effort to make this a more efficient process. Thanks, lets take the discussion over to GORA-413 --001a11351bc6f8bc690510036e30--