accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1957) specify durability during writes
Date Wed, 27 Aug 2014 17:35:59 GMT


Josh Elser commented on ACCUMULO-1957:

I can think of cases where having durability on the BatchWriter/Mutation level would be useful,
but I'm not convinced one way or the other if it's worth the added complexity.

Consider if I have a table which acts as a user database for a web application, where each
row stores information for a user. I would have columns that have the "full" durability: passwords,
user name, etc. If the user changes these, I want to be certain that the changes persist.
I would likely also have columns which I don't care if they get lost, primarily metrics: last_login,
last_activity, links_clicked, etc.

I think any case you come up with *could* be solved by separating the data into multiple tables.
The question I struggle with is whether this goes against the original bigtable premise where
all of the data for some "element" is stored together. I would need to write the equivalent
of a join to get all of the information for a user if I'm forced to store them in two tables.

> specify durability during writes
> --------------------------------
>                 Key: ACCUMULO-1957
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client, tserver
>            Reporter: Eric Newton
>            Priority: Minor
> There are several levels of durability:
> * acknowledged
> * walog'd
> * walog'd and synced to datanodes
> * walog'd and synced to datanode disks
> Rather than specify this at the table configuration, allow the user to specify it when
they create a batch writer.

This message was sent by Atlassian JIRA

View raw message