Transaction Support?

[Harshada]

Hi,

I am new to this field. So, please pardon me if my questions are too
naive.

http://groups.google.com/group/hypertable-user/browse_thread/thread/a7c54f74d14b08b6/692881da5df525b4?lnk=gst&q=transaction+recovery#692881da5df525b4

tells us that Hypertable supports simple row/range level transactions.

My questions are:

1. Is it like the traditional transaction support- i.e. including
locking, logging, recovery etc? If yes, where can I find related files
in the source?
2. Is it similar/on the parallel lines of BigTable's tablet level
transaction support?

Thanks,

Harshada

[Doug Judd]

Hi Harshada,

Hypertable currently doesn't support ACID transactions.  We've carefully designed the system so that it could support transactions in the future.  All updates go into a commit log in the DFS for durability.  Each cell has a 64-bit revision number associated with it.  We use this revision number for snapshot isolation, to support Multi-version concurrency control (MVCC).  It's possible for the revision number to be supplied with inserts and queries.  We envision some day building a transaction monitor that sits in front of a Hypertable cluster to provide distributed transactions.

It's also fairly simple to provide row-level transactions.  All of the data for a given row resides in the same range.  This allows us to easily build a row-level transaction mechanism.  On our near term roadmap, we plan to add support for integer counters and an atomic increment operation, which is essentially a specialized transaction.  We may build that on top of a more generalized row-level read-modify-write mechanism as described in the Bigtable paper.

Is there a specific transaction use case that you would like to see supported?

- Doug

--
You received this message because you are subscribed to the Google Groups "Hypertable Development" group.
To post to this group, send email to hyperta...@googlegroups.com.
To unsubscribe from this group, send email to hypertable-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.

[Harshada]

Thanks Doug.

The previous discussion suggests that-> Hypertable provides row level
transactions. (i.e. the consistency is provided at the level of a row
--correct me if I am wrong)
Here, what does a row mean? The complete row corresponding to a single
key i.e. all the columns and all the revisions (like BigTable) or a
key and one particular version(timestamp).

On Feb 2, 8:17 pm, Doug Judd <nuggetwh...@gmail.com> wrote:
> Hi Harshada,
>
> Hypertable currently doesn't support ACID transactions.  We've carefully
> designed the system so that it could support transactions in the future.
> All updates go into a commit log in the DFS for durability.  Each cell has a
> 64-bit revision number associated with it.  We use this revision number for
> snapshot isolation, to support Multi-version concurrency control (MVCC).
> It's possible for the revision number to be supplied with inserts and
> queries.  We envision some day building a transaction monitor that sits in
> front of a Hypertable cluster to provide distributed transactions.
>
> It's also fairly simple to provide row-level transactions.  All of the data
> for a given row resides in the same range.  This allows us to easily build

> row-level transaction mechanism.  On our near term roadmap, we plan to add
> support for integer counters and an atomic increment operation, which is
> essentially a specialized transaction.  We may build that on top of a more
> generalized row-level read-modify-write mechanism as described in the
> Bigtable paper.
>
> Is there a specific transaction use case that you would like to see
> supported?
>
> - Doug
>

> On Mon, Feb 1, 2010 at 9:20 PM, Harshada <chavan.harsh...@gmail.com> wrote:
> > Hi,
>
> > I am new to this field. So, please pardon me if my questions are too
> > naive.
>

> >http://groups.google.com/group/hypertable-user/browse_thread/thread/a...

>
> > tells us that Hypertable supports simple row/range level transactions.
>
> > My questions are:
>
> > 1. Is it like the traditional transaction support- i.e. including
> > locking, logging, recovery etc? If yes, where can I find related files
> > in the source?
> > 2. Is it similar/on the parallel lines of BigTable's tablet level
> > transaction support?
>
> > Thanks,
>
> > Harshada
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Hypertable Development" group.
> > To post to this group, send email to hyperta...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > hypertable-de...@googlegroups.com<hypertable-dev%2Bunsu...@googlegroups.com>

[Doug Judd]

Hypertable is designed in such a way that it could support row level transactions.  We currently do not have any transaction API.  The row would be all cells with the same row key (like Bigtable).

- Doug

To unsubscribe from this group, send email to hypertable-de...@googlegroups.com.

[Harshada]

Oh cool :)

Thanks!

I have one more question. Does Hypertable support stored procedures
(procedures = C++ code)?

(I am really sorry for asking questions in bits and pieces.)

On Mar 4, 11:12 pm, Doug Judd <nuggetwh...@gmail.com> wrote:
> Hypertable is designed in such a way that it could support row level
> transactions.  We currently do not have any transaction API.  The row would
> be all cells with the same row key (like Bigtable).
>
> - Doug
>

> > <hypertable-dev%2Bunsu...@googlegroups.com<hypertable-dev%252Buns...@googlegroups.com>

[Doug Judd]

No problem!  Hypertable does not currently support stored procedures.

- Doug

To unsubscribe from this group, send email to hypertable-de...@googlegroups.com.

[dorian i]

 It's possible for the revision number to be supplied with inserts and queries.

Is there a roadmap(possible?) for specifying revision when inserting?

Mainly to lower overhead on:

1. counter columns (what could go wrong on increments with the same revision/timestamp?).  While deletes can use future timestamps.
2. normal columns where timestamp=revision

[Doug Judd]

The revision number is a field that is necessary for Hypertable to work properly.  We use it for MVCC purposes.  However, if you don't supply a timestamp (e.g. auto-assign), then the timestamp and the revision number are the same and they occupy the same space.  This goes for COUNTER columns as well as normal ones.

- Doug 

--

You received this message because you are subscribed to the Google Groups "Hypertable Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hypertable-de...@googlegroups.com.

To post to this group, send email to hyperta...@googlegroups.com.

Visit this group at http://groups.google.com/group/hypertable-dev.
For more options, visit https://groups.google.com/d/optout.

--

Doug Judd

CEO, Hypertable Inc.

[Dorian Hoxha]

Yes, but if you have many counters in a row:

1. If you specify a timestamp, they will have the same timestamp, but different revisions
2. If you dont specify the timestamp, they will have same timestamp+revision, but different compared to each other

While i was talking about having the same timestamp/revision across all the cells (so the timestamps/revisions from different cells will be compressed together on that cell-block).

--
You received this message because you are subscribed to a topic in the Google Groups "Hypertable Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hypertable-dev/KKOLLyCFNzs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hypertable-de...@googlegroups.com.