From issues-return-146929-archive-asf-public=cust-asf.ponee.io@hive.apache.org Wed Jan 16 02:13:05 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 52F27180675 for ; Wed, 16 Jan 2019 02:13:05 +0100 (CET) Received: (qmail 4053 invoked by uid 500); 16 Jan 2019 01:13:04 -0000 Mailing-List: contact issues-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hive.apache.org Delivered-To: mailing list issues@hive.apache.org Received: (qmail 4035 invoked by uid 99); 16 Jan 2019 01:13:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2019 01:13:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B387A180D7E for ; Wed, 16 Jan 2019 01:13:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id y5HA87-K977q for ; Wed, 16 Jan 2019 01:13:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 480B45F588 for ; Wed, 16 Jan 2019 01:13:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 7FC80E006D for ; Wed, 16 Jan 2019 01:13:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3F4C325590 for ; Wed, 16 Jan 2019 01:13:00 +0000 (UTC) Date: Wed, 16 Jan 2019 01:13:00 +0000 (UTC) From: "Vihang Karajgaonkar (JIRA)" To: issues@hive.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HIVE-21115) Add support for object versions in metastore MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HIVE-21115?page=3Dcom.atlassian= .jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1674= 3500#comment-16743500 ]=20 Vihang Karajgaonkar edited comment on HIVE-21115 at 1/16/19 1:12 AM: --------------------------------------------------------------------- Thanks [~odraese]. You make a fair point. I took a look at the code you poi= nted above and here are lines which are interesting with respect to generat= ing the version numbers using transaction handler. https://github.com/apache/hive/blob/master/standalone-metastore/metastore-s= erver/src/main/java/org/apache/hadoop/hive/metastore/txn/TxnHandler.java#L5= 89 {code} String s =3D sqlGenerator.addForUpdateClause("select ntxn_next from NE= XT_TXN_ID"); LOG.debug("Going to execute query <" + s + ">"); rs =3D stmt.executeQuery(s); if (!rs.next()) { throw new MetaException("Transaction database not properly " + "configured, can't find next transaction id."); } long first =3D rs.getLong(1); s =3D "update NEXT_TXN_ID set ntxn_next =3D " + (first + numTxns); LOG.debug("Going to execute update <" + s + ">"); stmt.executeUpdate(s); {code} Although in theory we can use this same logic to generate object versions b= ut this is different which can have potentially severe performance degradat= ion. Note that the transaction_ids are unique across all the objects and in= stances of metastores. This means all the transactions are serialized to ge= nerate these ids in metastore. While this could be used to generate a globa= lly incrementing version number it may have some adverse performance implic= ations. Having a version at a per-object level instead reduces the scope of= the lock and only the transactions which are operating on the same object = will be serialized. I think as a mid-way we can implement the versioning fo= r non-acid enabled tables. If the table is ACID enabled, it should use the = transaction ids for its versioning. I am hesitant to use this logic above f= or all the objects which indirectly is going to serialize all the DML trans= actions in metastore. Perhaps someone more familiar with this code can comm= ent on my thoughts above. [~ekoifman] [~alangates]? was (Author: vihangk1): Thanks [~odraese]. You make a fair point. I took a look the you pointed abo= ve and here are lines which are interesting with respect to generating the = version numbers using transaction handler. https://github.com/apache/hive/blob/master/standalone-metastore/metastore-s= erver/src/main/java/org/apache/hadoop/hive/metastore/txn/TxnHandler.java#L5= 89 {code} String s =3D sqlGenerator.addForUpdateClause("select ntxn_next from NE= XT_TXN_ID"); LOG.debug("Going to execute query <" + s + ">"); rs =3D stmt.executeQuery(s); if (!rs.next()) { throw new MetaException("Transaction database not properly " + "configured, can't find next transaction id."); } long first =3D rs.getLong(1); s =3D "update NEXT_TXN_ID set ntxn_next =3D " + (first + numTxns); LOG.debug("Going to execute update <" + s + ">"); stmt.executeUpdate(s); {code} Although in theory we can use this same logic to generate object versions b= ut this is different which can have potentially severe performance degradat= ion. Note that the transaction_ids are unique across all the objects and in= stances of metastores. This means all the transactions are serialized to ge= nerate these ids in metastore. While this could be used to generate a globa= lly incrementing version number it may have some adverse performance implic= ations. Having a version at a per-object level instead reduces the scope of= the lock and only the transactions which are operating on the same object = will be serialized. I think as a mid-way we can implement the versioning fo= r non-acid enabled tables. If the table is ACID enabled, it should use the = transaction ids for its versioning. I am hesitant to use this logic above f= or all the objects which indirectly is going to serialize all the DML trans= actions in metastore. Perhaps someone more familiar with this code can comm= ent on my thoughts above. [~ekoifman] [~alangates]? > Add support for object versions in metastore > -------------------------------------------- > > Key: HIVE-21115 > URL: https://issues.apache.org/jira/browse/HIVE-21115 > Project: Hive > Issue Type: Improvement > Reporter: Vihang Karajgaonkar > Priority: Major > > Currently, metastore objects are identified uniquely by their names (eg. = catName, dbName and tblName for a table is unique). Once a table or partiti= on is created it could be altered in many ways. There is no good way curren= tly to identify the version of the object once it is altered. For example, = suppose there are two clients (Hive and Impala) using the same metastore. O= nce some alter operations are performed by a client, another client which w= ants to do a alter operation has no good way to know if the object which it= has is the same as the one stored in metastore. Metastore updates the {{tr= ansient_lastDdlTime}} every time there is a DDL operation on the object. Ho= wever, this value cannot be relied for all the clients since after HIVE-176= 8 metastore updates the value only when it is not set in the parameters. It= is possible that a client which alters the object state, does not remove t= he {{transient_lastDdlTime}} and metastore will not update it. Secondly, if= there is a clock skew between multiple HMS instances when HMS-HA is config= ured, time values cannot be relied on to find out the sequence of alter ope= rations on a given object. > This JIRA propose to use JDO versioning support by Datanucleus http://ww= w.datanucleus.org/products/accessplatform_4_2/jdo/versioning.html to genera= te a incrementing sequence number every time a object is altered. The value= of this object can be set as one of the values in the parameters. The adva= ntage of using Datanucleus the versioning can be done across HMS instances = as part of the database transaction and it should work for all the supporte= d databases. > In theory such a version can be used to detect if the client is presentin= g a object which is "stale" when issuing a alter request. Metastore can cho= ose to reject such a alter request since the client may be caching a old ve= rsion of the object and any alter operation on such stale object can potent= ially overwrite previous operations. However, this is can be done in a sepa= rate JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)