Hi Tony, 

I don't know of any such plans at this time.  At least some of us are trying
to steer clear of full support for distributed query as it is a very hard
problem that gets you deeply enmeshed in the details of particular databases
and their SQL dialects, not to mention distributed query optimization.  I
therefore do not foresee this as a feature of Sequoia any time soon.

Cheers, Robert


On 2/26/08 10:46 AM, "Anthony J. Biacco" <[EMAIL PROTECTED]> wrote:

>  
> Also, is there any plans to inplement distributed joins for raid b-2?
> Perhaps through a query parser in the controller, which detects a
> join-type statement, then contacts a global catalog db/table on the db
> servers that contains a list of the nodes that contain the table
> requested?
> 
> -Tony
> ---------------------------
> Manager, IT Operations
> Format Dynamics, Inc.
> 303-573-1800x27
> [EMAIL PROTECTED]
> http://www.formatdynamics.com
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anthony
> J. Biacco
> Sent: Tuesday, February 26, 2008 9:54 AM
> To: Sequoia general mailing list
> Subject: RE: [Sequoia] still being developed? (questions)
> 
> 
> Thanx you for your answers Emmanuel.
> My hesitation to use b-0 is the same as you pointed out, the distributed
> joins. And being that it is the same for b-2 also, i'm not sure just
> using b-1 (without a SAN) would work for us, as we plan to scale to a
> larger database. probably 2TB+. Even being that disk space is cheap
> these days, i'm not sure if doing 2TB in each node with a small number
> of disk spindles is the right way to go. Especially, as i increase the
> number of nodes and transactions.
> I may end of going with the paralleldb option, san, and see how MySQL
> w/GFS performs with a single storage instance.
> 
> -Tony
> ---------------------------
> Manager, IT Operations
> Format Dynamics, Inc.
> 303-573-1800x27
> [EMAIL PROTECTED]
> http://www.formatdynamics.com
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Emmanuel Cecchet
> Sent: Tuesday, February 26, 2008 4:22 AM
> To: Sequoia general mailing list
> Subject: Re: [Sequoia] still being developed? (questions)
> 
> Hi Anthony,
>> 1. I understand that using sequoia kind of assumes a shared-nothing
> disk
>> architecture. But is it possible to use it with a SAN instead of
> RAIDed?
>>   
> If you use a SAN it means that your database supports shared-disk
> clustering (like Oracle RAC) and already deals with the proper locking
> and replication mechanism.
>> Can you even specify no RAID level?
> If your database readily supports replication (e.g. using a SAN), then
> you can use the ParallelDB load balancer that just forwards requests to
> your database cluster. In this case, Sequoia brings you load balancing,
> transparent failover and eventuelly request caching.
>> If so, does sequoia then have
>> nothing to do with this and all the reading/writing would just fall
> back
>> to MySQL's standards and locking along with whatever filesystem i'd be
>> using (probably GFS)? Would this even be possible or plausible?
>>   
> Just to make sure that this is clear, Sequoia just relies on the
> capabilities of the underlying databases. So if you try to use a SAN
> with a database that has no support for it, Sequoia will not help in any
> 
> way.
>> 2. In trying to understand the RAIDed architecture in regards to
>> sequoia, i'm not sure i understand something about the b-2 level. Does
>> sequoia determine which tables go on which servers? Or would I
> determine
>> that schema? What happens when an extra database server is introduced
>> into the mix? Does the schema re-partition the data automatically?
> Does
>> this need to be done manually?
>>   
> In RAIDb-2, Sequoia will fetch the schema that is available on each
> replica and proceed from there. If you want to force only specific
> tables on each node, this can be specified manually in the virtual
> database configuration file. The same thing applies when a new table
> needs to be created, you can specify policies to create that table on a
> specific set of nodes or choose dynamically nodes among a pool to select
> 
> the less loaded ones.
>> 3. For nested raid (b-0-1/b-1-0), is this a common config, and if so,
>> can someone comment on how well this works in the real world, in
> regards
>> to performance and ease of recovery?
>>   
> No this is not a common config and RAIDb-0 is rarely used because it
> does not support distributed joins. If table A is on node 1 and table B
> on node 2 and you try something like SELECT * FROM A,B you will get an
> error that no node has both tables and the query cannot be executed.
>> 4. In regards to the controller, where is this recommended to be
> placed?
>> on the app servers (tomcat), or the database servers?
>>   
> There is no single answer to that. It depends how many app servers or
> DBs you have. Sometimes you can collocate everything Tomcat/Sequoia/DB
> and sometimes you use even dedicated machines for Sequoia controllers.
> So all combinations are possible.
> 
> Thanks for your interest in Sequoia,
> Emmanuel

-- 
Robert Hodges, CTO, Continuent, Inc.
Email:  [EMAIL PROTECTED]
Mobile:  +1-510-501-3728  Skype:  hodgesrm


_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to