hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Thusoo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-1293) Concurreny Model for Hive
Date Wed, 14 Apr 2010 21:46:52 GMT

    [ https://issues.apache.org/jira/browse/HIVE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857110#action_12857110
] 

Ashish Thusoo commented on HIVE-1293:
-------------------------------------

I would vote for versioning. Since we do not have to deal with the complexity of a buffer
cache I think this would be much simpler to implement than what is possible in traditional
databases. At the same time, for locks we will have to do a lease based mechanism anyway in
order to protect against locks leaking because of client crashes. And when you account for
that, it seems that locking would not be significantly simpler to implement than versioning.


> Concurreny Model for Hive
> -------------------------
>
>                 Key: HIVE-1293
>                 URL: https://issues.apache.org/jira/browse/HIVE-1293
>             Project: Hadoop Hive
>          Issue Type: New Feature
>          Components: Query Processor
>            Reporter: Namit Jain
>
> Concurrency model for Hive:
> Currently, hive does not provide a good concurrency model. The only guanrantee provided
in case of concurrent readers and writers is that
> reader will not see partial data from the old version (before the write) and partial
data from the new version (after the write).
> This has come across as a big problem, specially for background processes performing
maintenance operations.
> The following possible solutions come to mind.
> 1. Locks: Acquire read/write locks - they can be acquired at the beginning of the query
or the write locks can be delayed till move
> task (when the directory is actually moved). Care needs to be taken for deadlocks.
> 2. Versioning: The writer can create a new version if the current version is being read.
Note that, it is not equivalent to snapshots,
> the old version can only be accessed by the current readers, and will be deleted when
all of them have finished.
> Comments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message