Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 25 Feb 2015 19:19:05 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12777463.1424857044000.13753.1424891945862@Atlassian.JIRA>
In-Reply-To: <JIRA.12777463.1424857044000@Atlassian.JIRA>
References: <JIRA.12777463.1424857044000@Atlassian.JIRA>
 <JIRA.12777463.1424857044326@arcas>
Subject: [jira] [Commented] (HBASE-13099) Scans as in DynamoDB
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-13099?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D143=
37017#comment-14337017 ]=20

Enis Soztutar commented on HBASE-13099:
---------------------------------------

I think we may have to keep at least some state in the server, even if we d=
o a cell-based scanner. Our contract is per-row atomicity, so we have to ke=
ep track of:=20
1. read point while scanning inside a row.=20
2. low watermark for the read points across all "open" scanners for the reg=
ion.=20

(1) can even be extended to be a region based contract if we consider atomi=
c updates cross-row using the MultiRowMutationEndpoint. (2) is needed for e=
ffectively getting rid of seqId's of cells in hfiles.=20

We keep (1) in the server side right now, and we use the row-based scanner =
contract for (1). The client either gets the whole row, or not. The scanner=
 can be restarted across rows, which changes the scanner read point, but it=
 is fine since there is no guarantees across rows for visibility (excluding=
 single region multi-row transactions).=20

>From a semantics point of view, (1) can be achieved with sending the read p=
oint to the client everytime a scan is started within a region. The client =
will keep track of 1 read point per region. Any subsequent scans performed =
from the client in the region will also send this read point to the server =
so that the scan does not see partial data. (2) can be solved by either not=
 deleting seqId's of cells in hfiles (which we do to optimize disk usage), =
or keeping track of all open scanners' read points which requires still som=
e state (even though very small) in the server.=20

> Scans as in DynamoDB
> --------------------
>
>                 Key: HBASE-13099
>                 URL: https://issues.apache.org/jira/browse/HBASE-13099
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: Client, regionserver
>            Reporter: Nicolas Liochon
>
> cc: [~saint.ack@gmail.com] - as discussed offline.
> DynamoDB has a very simple way to manage scans server side:
> ??citation??
> The data returned from a Query or Scan operation is limited to 1 MB; this=
 means that if you scan a table that has more than 1 MB of data, you'll nee=
d to perform another Scan operation to continue to the next 1 MB of data in=
 the table.
> If you query or scan for specific attributes that match values that amoun=
t to more than 1 MB of data, you'll need to perform another Query or Scan r=
equest for the next 1 MB of data. To do this, take the LastEvaluatedKey val=
ue from the previous request, and use that value as the ExclusiveStartKey i=
n the next request. This will let you progressively query or scan for new d=
ata in 1 MB increments.
> When the entire result set from a Query or Scan has been processed, the L=
astEvaluatedKey is null. This indicates that the result set is complete (i.=
e. the operation processed the =E2=80=9Clast page=E2=80=9D of data).
> ??citation??
> This means that there is no state server side: the work is done client si=
de.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)