Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-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 42EAF10370 for ; Fri, 31 Jan 2014 11:57:18 +0000 (UTC) Received: (qmail 27905 invoked by uid 500); 31 Jan 2014 11:57:14 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 27501 invoked by uid 500); 31 Jan 2014 11:57:13 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 27492 invoked by uid 99); 31 Jan 2014 11:57:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 11:57:12 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cptmauli@googlemail.com designates 74.125.82.46 as permitted sender) Received: from [74.125.82.46] (HELO mail-wg0-f46.google.com) (74.125.82.46) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 11:57:08 +0000 Received: by mail-wg0-f46.google.com with SMTP id x12so8450603wgg.1 for ; Fri, 31 Jan 2014 03:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xOuNcz7RqBxVBVYsEdZHG8p+FKsBYLDySXVu7Ax7HAM=; b=CJan8Ir7ZXwcp20oiti8ZD7o3xhnB77/enSyOl1J+fseLyqQd6AckP8dpIS9166OtM jbmoNpvEZt/tWZuuyC90ynOZtEIEpNKa+ytm+yzejs/wAtcBAfSgRklKWHTPazWk/WnD oabzq5/G40pDOe0+qVCuNgnfM4yceGSA486YRBvKn7s6x/TmzAB8hnscudJ+ZEefvKDO fqAImIG/coio0SJ9ZIdDkPX1tGG7uXGOXRlKTcFIjodeTqehLdx0WGfCWJ8P3CLrrsMR axbwYhgqX+uQyWzAcvSEOKjAW/nWqmVaD1BIlNMR23SXLI5M+9sozUkCmR6xw6Do4PLQ v57Q== X-Received: by 10.180.149.206 with SMTP id uc14mr13595379wib.10.1391169405637; Fri, 31 Jan 2014 03:56:45 -0800 (PST) Received: from ?IPv6:2001:a60:f10b:0:beae:c5ff:fe27:9667? (brisbane.muc.ibhmgt.de. [2001:a60:f10b:0:beae:c5ff:fe27:9667]) by mx.google.com with ESMTPSA id q15sm19209773wjw.18.2014.01.31.03.56.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 03:56:44 -0800 (PST) Message-ID: <52EB8F8E.5020101@googlemail.com> Date: Fri, 31 Jan 2014 12:57:02 +0100 From: =?ISO-8859-1?Q?J=FCrgen_Rose?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: user@hbase.apache.org Subject: How large can a hbase table actually grow? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, Would there be any reason to split a hbase table into smaller entities, or can it grow forever (assuming available disk space)? Background: We have realtime data (measurements), up to lets say 500,000/s, which consists essentially of timestamp, value, flags. If we distribute the values to different tables (for each tag), it would also mean to insert each of the entries individually, which is a performance killer. If we insert in bulk it is much faster. The question is, are there any downsides to having a hbase table with an extreme size? best regards J�rgen