Return-Path: X-Original-To: apmail-tajo-dev-archive@minotaur.apache.org Delivered-To: apmail-tajo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9119C10920 for ; Mon, 4 Nov 2013 12:11:25 +0000 (UTC) Received: (qmail 92079 invoked by uid 500); 4 Nov 2013 12:11:24 -0000 Delivered-To: apmail-tajo-dev-archive@tajo.apache.org Received: (qmail 92002 invoked by uid 500); 4 Nov 2013 12:11:22 -0000 Mailing-List: contact dev-help@tajo.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tajo.incubator.apache.org Delivered-To: mailing list dev@tajo.incubator.apache.org Received: (qmail 91966 invoked by uid 99); 4 Nov 2013 12:11:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Nov 2013 12:11:19 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 04 Nov 2013 12:11:17 +0000 Received: (qmail 89813 invoked by uid 99); 4 Nov 2013 12:10:22 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Nov 2013 12:10:22 +0000 Date: Mon, 4 Nov 2013 12:10:22 +0000 (UTC) From: "Jihoon Son (JIRA)" To: dev@tajo.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (TAJO-298) Catalog Federation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/TAJO-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812792#comment-13812792 ] Jihoon Son commented on TAJO-298: --------------------------------- If Tajo supports various catalog instances simultaneously, it will be useful. But I think that it will significantly increase the system's complexity. For example, when a worker tries to access to a catalog to build a query plan, it should get the information of which catalog stores the meta information of the relations relevant to the query plan. I think that the complexity problem outweighs the benefits. HDFS federation is designed and implemented to achieve the scalability and to handle the single point of failures. Since the master and workers access the catalog in Tajo, we may need to design the Catalog federation as the same reason of HDFS federation. > Catalog Federation > ------------------ > > Key: TAJO-298 > URL: https://issues.apache.org/jira/browse/TAJO-298 > Project: Tajo > Issue Type: Improvement > Components: catalog > Affects Versions: 0.8-incubating > Reporter: JaeHwa Jung > Assignee: JaeHwa Jung > Fix For: 0.8-incubating > > > Current Catalog supports just one Catalog server. But I think that users want to use serveral tables stored of multiple Catalogs at the same time. For example, After user query hive tables, user can inserver into tajo table. Above this, many use cases will happen. So, I wish that tajo supports muliple Catalog named Catalog Ferderation. I was inspired from HDFS Ferderation. -- This message was sent by Atlassian JIRA (v6.1#6144)