[Postgres-xl-general] [Postgres-xl-developers] Coordinator with Datanode

Arvind N arvindat.solaris at gmail.com
Mon Mar 16 01:10:27 PDT 2015


On Thu, Mar 12, 2015 at 5:20 AM, Mason S <masonlists at gmail.com> wrote:

>
>
> On Tue, Mar 10, 2015 at 12:59 AM, Ramanuj Hari <hari.ramanuj at gmail.com>
> wrote:
>
>> Hi Experts,
>>
>> I am facing an issue while taking decision. Not able to correctly arrive
>> conclusion.
>>
>>
>> What is the correct way to deploy Postgres-XL.
>>
>> [1] One VM to have Coordinator and Datanode.
>>
> [2] Based on connection requirement and database size requirement, we can
>> decide how many Coordinator and Datanode is needed, and deploy Coordinator
>> and Datanode on seperate VM.
>>
>>
>> What I am not able to figure out what's wrong with 1st option, because I
>> never saw any deployment of 1st type discussed in any of the mailing
>> thread.
>>
>>
> There are additional options. For example, with multiple vCPUs, you can
> have multiple Datanodes per VM.
>
> In general, yes, I would likely colocate a Coordinator and Datanode,
> especially with high concurrency. If you have low concurrency, you may not
> necessarily bother with a Coordinator on every VM. If it is a for a low
> concurrency BI workload with a heavy workload for individual queries, you
> could break the Coordinator out onto a separate smaller VM.
>

So is it acceptable to have Coordinator and Datanode to be run on the same
VM. What do you mean by High-Concurrency. ?? What would be the draw backs
by having Coordinator and Datanode to run on the same VM ?
What would the main reason that would drive a admin to add a new
coordinator to a DB Cluster ?. or what could be the case that we might need
100 coordinators ??
Are Coordinators RAM hungry ? Consider a Co-ordinator have 100 DB
connections with each connection provided 100 MB of Memory in the
configuration. With this kind of configuration will running co-ordinator on
a VM running data node cause Resource Starvation.



>
>
>> 1st option looks simple enough, but will it fit for infinite scaling
>> model, where to increase number of connection/ DB size, we can just spin
>> off a new VM (having coordinator and Datanode) and add the same to running
>> Postgres-XL cluster.
>>
>
> While you can add nodes to XL, it does not automatically redistribute
> data, you will have to do that as a separate step. So, instead you may wish
> to move off Datanodes to their own VMs as you grow, as a first step.
>
>
>>
>> What is the overhead of running very high number of Coordinator(say 100
>> or so), even though that many number of coordinator is not exactly
>> required.
>>
>>
> I do not know anyone who has tried 100 Coordinators, but the Coordinators
> really only communicate with one another for DDL, so most activity will
> just be fulfilling user requests.
>
>
> Regards,
>
> Mason
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Postgres-xl-developers mailing list
> Postgres-xl-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/postgres-xl-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/pipermail/postgres-xl-general-postgres-xl.org/attachments/20150316/d98d976d/attachment.htm>


More information about the postgres-xl-general mailing list