Menu
▾
▴
Re: [Postgres-xc-developers] Patch ready for review: online data redistribution
|
From: Michael P. <mic...@gm...> - 2012-07-13 23:54:28
|
On Sat, Jul 14, 2012 at 1:01 AM, Nikhil Sontakke <ni...@st...>wrote: > > But, one thing that is essential is catalog updates. Are you suggesting > that > > the catalog updates too should be done using some SQL? > > Surely, we can do: > > BEGIN; > > CREATE NODE; /* Hmm, I think we should have a CREATE CLUSTER NODE version*/ > > ALL the redistribution SQL here; > > COMMIT; > > The new node info will be visible to the rest of the SQL commands that > follow this ways. > > Michael, I don't have a strong view against adding stuff in the core, > but since the first cut for redistribution seems to be a bunch of SQL > grouped together, I thought this might be worth investigating too. > Honestly I thought about such solutions before beginning my stuff, but arrived at the conclusion that we need a native way to manage redistribution. In this case, you fall under the following limitations: - How to manage node-level granularity for redistribution operations? In XC, by design, a SQL is launched globally on the cluster. At the exception of EXECUTE DIRECT but it only allows SELECT commands. - When and how to manage the catalog update? Even if it is possible to update catalog with DMLs, we need native APIs to be able to modify catalog entries. - CREATE NODE is used for the addition and deletion of nodes. Data redistribution does not concern changing the configuration of the cluster. You got a certain number of Datanodes, Coordinators, and you want to change the nodes where data of a table is located inside this given cluster. Your approach makes redistribution dependent on cluster configuration and it is honestly not welcome to add such degrees of dependencies that may be a burden in the future if we change once again the way cluster is configured. - For certain redistribution operations, we do NOT always need a transaction block! Just take the example of a replicated table changed to a distributed table. You just need to send a DELETE query to remote nodes to remove only the tuples that do not satisfy a hash condition. This is one of those things I am working on now. To my mind, each argument here makes necessary this feature in core. All combined even strengthen my arguments. > Regards, > Nikhils > > > Something I am afraid is not possible with an external utility is > control of > > redistribution at node level. For example, an external contrib module or > > utility will launch SQL queries to xc that have to be treated as global. > > However, redistribution needs to take care of cases like for example the > > reduction of nodes for replicated tables. In this case you just need to > > delete the data from removed nodes. Another easy example is the case of > an > > increase of nodes for replicated tables. You need to pick up data on > > coordinator and then send it only to the new nodes. Those simple examples > > need a core management to minimize the work of redistribution inside > > cluster. > > > > On 2012/07/13, at 15:09, Ashutosh Bapat <ash...@en... > > > > wrote: > > > > Even, I am wondering if that would be better. > > > > But, one thing that is essential is catalog updates. Are you suggesting > that > > the catalog updates too should be done using some SQL? > > > > Can you please expand more on your idea, may be providing some examples, > > pseudo-code etc.? > > > > On Fri, Jul 13, 2012 at 10:36 AM, Nikhil Sontakke <ni...@st...> > > wrote: > >> > >> Just a thought. > >> > >> If we have a utility which spews out all of these statements to > >> redistribute a table across node modifications, then we can just wrap > >> them inside a transaction block and just run that? > >> > >> Wont it save all of the core changes? > >> > >> Regards, > >> Nikhils > >> > >> On Fri, Jul 13, 2012 at 12:29 AM, Michael Paquier > >> <mic...@gm...> wrote: > >> > Hi all, > >> > > >> > Please find attached an updated patch adding redistribution > >> > optimizations > >> > for replicated tables. > >> > If the node subset of a replicated table is reduced, the necessary > nodes > >> > are > >> > simply truncated. > >> > If it is increased, a COPY TO is done to fetch the data, and COPY FROM > >> > is > >> > done only on the necessary nodes. > >> > New regression tests have been added to test that. > >> > > >> > Regards, > >> > > >> > > >> > On Thu, Jul 12, 2012 at 5:30 PM, Michael Paquier > >> > <mic...@gm...> > >> > wrote: > >> >> > >> >> OK, here is the mammoth patch: 3000 lines including docs, > >> >> implementation > >> >> and regressions. > >> >> The code has been realigned with current master. > >> >> This patch introduces the latest thing I am working on: the > >> >> redistribution > >> >> command tree planning and execution. > >> >> > >> >> As I explained before, a redistribution consists of a series of > >> >> commands > >> >> (TRUNCATE, REINDEX, DELETE, COPY FROM, COPY TO) that need to be > >> >> determined > >> >> depending on the new and old locator information of the relation. > Each > >> >> action can be done on a subset of nodes. > >> >> This patch introduces the basic infrastructure of the command tree > >> >> build > >> >> and execution. > >> >> For the time being, redistribution uses only what is called the > default > >> >> command tree consisting of: > >> >> 1) COPY TO > >> >> 2) TRUNCATE > >> >> 3) COPY FROM > >> >> 4) REINDEX > >> >> But this structure can be easily completed with more complicated > >> >> operations. > >> >> In this patch there is still a small thing missing which is the > >> >> possibility to launch a COPY FROM on a subset of nodes, particularly > >> >> useful > >> >> when redistribution consists of a replicated table whose set of nodes > >> >> is > >> >> increased. > >> >> Compared to the last versions, the impact of redistribution in > >> >> tablecmds.c > >> >> is limited. > >> >> > >> >> Regards, > >> >> > >> >> -- > >> >> Michael Paquier > >> >> http://michael.otacoo.com > >> > > >> > > >> > > >> > > >> > -- > >> > Michael Paquier > >> > http://michael.otacoo.com > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > Live Security Virtual Conference > >> > Exclusive live event will cover all the ways today's security and > >> > threat landscape has changed and how IT managers can respond. > >> > Discussions > >> > will include endpoint security, mobile security and the latest in > >> > malware > >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> > _______________________________________________ > >> > Postgres-xc-developers mailing list > >> > Pos...@li... > >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >> > > >> > >> > >> > >> -- > >> StormDB - http://www.stormdb.com > >> The Database Cloud > > > > > > > > > > -- > > Best Wishes, > > Ashutosh Bapat > > EntepriseDB Corporation > > The Enterprise Postgres Company > > > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- Michael Paquier http://michael.otacoo.com |
