Peter Vary commented on HIVE-18685:


I like the possibility to scale out the MetaStore on multiple servers (I was 
thinking about db level separation, but catalog level separation seems more 

A few quick questions about the doc:
 * When the administrator defines the security model, how does it 
stored/retrieved? Maybe it should be a catalog level information
 * It might be difficult to have the same user base / security model working 
for every connecting application, especially with transient clusters - maybe it 
is not an immediate concern, but it might be good to keep in mind.
 * I am not a big fan of the current thrift API, and I would prefer adding new 
methods to it only if they drive us to a well designed V2 version of the API. 
That said, if we do not want to mix the 2 tasks (API redesign, addition of 
catalogs), then we can use something like proposed by [~akolb] in point 10. To 
be honest I would go this way only if we have a clear timeline for the API 
redesign as well, because I tend to think about this as a hackish solution, and 
I think it would be bad if we get stuck with it for a long term :) - especially 
that if I know correctly sql standard says we should use catalog.database.table 
notation in queries
 * Maybe longer term question, but in case of multiple servers who should 
decided which Metastore instance should be quieried to archive scalability. 
Should it be decided on MetaStoreClient level?



> Add catalogs to metastore
> -------------------------
>                 Key: HIVE-18685
>                 URL: https://issues.apache.org/jira/browse/HIVE-18685
>             Project: Hive
>          Issue Type: New Feature
>          Components: Metastore
>    Affects Versions: 3.0.0
>            Reporter: Alan Gates
>            Assignee: Alan Gates
>            Priority: Major
>         Attachments: HMS Catalog Design Doc.pdf
> SQL supports two levels of namespaces, called in the spec catalogs and 
> schemas (with schema being equivalent to Hive's database).  I propose to add 
> the upper level of catalog.  The attached design doc covers the use cases, 
> requirements, and brief discussion of how it will be implemented in a 
> backwards compatible way.

This message was sent by Atlassian JIRA

Reply via email to