Re: [Sequoiadb-discuss] Sequoia

[Emmanuel C. <ma...@fr...>]

Gary,
> Thanks for your quick reply. However to summarize, writes are going to 
> be done in parallel to all databases. So even ignoring the overhead 
> issue, this doesn't sound like it will scale at all by adding more 
> machines? When the write traffic grows, eventually it will overload 
> the databases. Am I missing something here?
You are correct, as every database has to execute the writes, there is 
no speedup when adding machines (there might even be a slowdown due to 
the increased synchronization between the databases).
The next step to scale writes is to partition your database. Sequoia has 
something called RAIDb-2 that allows you to distribute tables on 
different nodes, this way you can send writes to different tables to 
different nodes. This code has not been tested for quite some time now 
so it might be better handled at the application level.
If you want to partition a single table (slice it in smaller chunks), 
you will need a database that supports that natively. Unfortunately this 
is usually not compatible with replication. Sequoia will work on top of 
a partitioned database but it might eliminate the benefits of the 
partitioning by sequentializing the writes (needs to be tested to be sure).

There is currently no magic solution to scale writes. It's either you 
buy faster hardware or you re-design your application to partition data 
so that writes can really be performed in parallel to different 
partitions (you can then use Sequoia to replicate each partition 
separately).

Hope this helps,
Emmanuel

>
> Emmanuel Cecchet wrote:
>> Hi Gary,
>>
>> I am CC-ing the new mailing list.
>>   
>>> Recently saw your post on Sequoia mailing list and have a quick newbie
>>> question. Does Sequoia handle write requests? How exactly does Sequoia
>>> scales with write requests? I understand that for read requests, it
>>> would scale somewhat (hopefully) linearly. That is, I expect that when
>>> I add 2x more databases to the group, it should be able to handle 2x
>>> more incoming requests. But what about write requests? Are the data
>>> updates replicated by Sequoia? If so, what kind of performance and
>>> delay can I expect? Any help or hint is much appreciated!
>>>     
>> If you are using RAIDb-1, writes are sent in parallel to all databases.
>> If you have a single controller, the overhead is about a millisecond in
>> latency per query.
>> If you have multiple controllers, you have to add the group
>> communication latency which varies depending on your configuration.
>> Typical numbers range from 1 to 8ms of added latency to a request.
>> So if you have a single threaded application that perform writes, you
>> will see a significant overhead especially if your writes are small
>> (adding 1 ms to a sub-millisecond query is more than doubling its
>> execution time). As writes also have to be executed in the same order by
>> all databases, Sequoia adds some constraints to make sure that writes to
>> the same table are done sequentially. If you were updating in parallel
>> the same table, this will now become sequential. Therefore you can see a
>> significant slowdown in such use case too (we are talking pure writes,
>> no reads here).
>> As you pointed it out, reads are distributed among the backends and you
>> can achieve fairly easily a linear speedup. So if you inject twice the
>> load, the response time will remain constant and your throughput
>> doubles. But if your number of requests remain constant, adding nodes to
>> a non-overloaded system is not likely to bring any noticeable
>> performance improvement.
>>
>> I hope this clarifies things a bit.
>> Thanks for your interest in Sequoia,
>> Emmanuel
>>
>> --
>> Emmanuel Cecchet
>> FTO @ Frog Thinker
>> Open Source Development & Consulting
>> --
>> Web: http://www.frogthinker.org
>> email: ma...@fr...
>> Skype: emmanuel_cecchet
>>
>>   


-- 
Emmanuel Cecchet
FTO @ Frog Thinker 
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: ma...@fr...
Skype: emmanuel_cecchet