Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 69821 invoked from network); 3 Apr 2009 19:45:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Apr 2009 19:45:40 -0000 Received: (qmail 78361 invoked by uid 500); 3 Apr 2009 19:45:40 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 78300 invoked by uid 500); 3 Apr 2009 19:45:40 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 78290 invoked by uid 99); 3 Apr 2009 19:45:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Apr 2009 19:45:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ryanobjc@gmail.com designates 209.85.217.164 as permitted sender) Received: from [209.85.217.164] (HELO mail-gx0-f164.google.com) (209.85.217.164) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Apr 2009 19:45:33 +0000 Received: by gxk8 with SMTP id 8so2719049gxk.5 for ; Fri, 03 Apr 2009 12:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Xxse9cLX/wsTxVYxGY4Qds1HSSZEuJ42RomMHNqaxjA=; b=fefpW+hQwkwej5HXkmDcfrdQBVOER6QbrJrag48v7PcPOTd+rDoPs2w/NfvSs2RMT2 0aLjxxRlNomxgZuHBvEl/4phKOea7CzM684Y7ZIeDtiCGN21VAtMwCclCI8x8mDF/hOk pcDIog3NwFTSyMdMlQWuL7vClXhfETJy1WMCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OFo7FNvgeU47hqlRVC0l/OINqJgup5ZXREF7OpPd5O2sSNXu0HHF58Sv6ychzIX5ck sFFphsbS6KOzZ+hAAA+wx4a5xmiVpphSunXaqiE91JHouI8PNpQ8W4ja4m191iOwYbS6 w0fr6wpB28Feg2ia3g8r3G3Mu4xVZpasWzja0= MIME-Version: 1.0 Received: by 10.151.150.13 with SMTP id c13mr2831634ybo.174.1238787912718; Fri, 03 Apr 2009 12:45:12 -0700 (PDT) In-Reply-To: <78568af10904031241h3d73844cv5ef85febd92ff12c@mail.gmail.com> References: <74f4d40b0904031046i1a0b2fe2u3e90f08956a9b3d8@mail.gmail.com> <78568af10904031241h3d73844cv5ef85febd92ff12c@mail.gmail.com> Date: Fri, 3 Apr 2009 12:45:12 -0700 Message-ID: <78568af10904031245u8f914c7u8567c46223263c58@mail.gmail.com> Subject: Re: Number of versions to fetch in one get call. From: Ryan Rawson To: hbase-dev@hadoop.apache.org Content-Type: multipart/alternative; boundary=00151750da787d5b6e0466abc961 X-Virus-Checked: Checked by ClamAV on apache.org --00151750da787d5b6e0466abc961 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've heard of people theorizing storing thousands of versions in a cell. I'm not sure the time dimention is the best way to actually store time series data. Its substandard query mechanism would make it hard to do date range queries. I think the time dimension is best left to versioning. In which case, the question is will the range -128 to 127 store enough data for version queries? Basically limit us to "return all or 254 versions." On Apr 3, 2009 11:01 AM, "Erik Holstad" wrote: For the new client server implementation I'm currently using 1 byte to store the number of versions to get, that can of course be changed to whatever number. Would just be nice to hear in what order we should put this limit and how actually versions should be used and thought of. Regards Erik --00151750da787d5b6e0466abc961--