Why are writes faster than reads?

[David Boxenhorn <da...@lookin2.com>]

I have seen several off-hand mentions that writes are inherently faster than
reads. Why is this so?

Re: Why are writes faster than reads?

[Peter Schüller <sc...@spotify.com>]

> I'm fairly certain the write path hits the commit log first, then the
> memtable.

I didn't mean to imply an ordering between the two (I probably should
not have said "memtable plus commit log"...), and yes I believe so.

-- 
/ Peter Schuller aka scode

Re: Why are writes faster than reads?

[Jonathan Shook <js...@gmail.com>]

Writes only have to write to the journal before returning. Reads have
to read potentially from several sources, including binary searches of
things that may or may not be cached anywhere.  The journal writes do
not involve much random disk IO, while the read activity does.

On Tue, May 25, 2010 at 11:53 AM, Tatu Saloranta <ts...@gmail.com> wrote:
> On Tue, May 25, 2010 at 4:04 AM, Mark Greene <gr...@gmail.com> wrote:
>> I'm fairly certain the write path hits the commit log first, then the
>> memtable.
>
> True, but that does not make them any less sequential -- journal logs
> are strictly sequential fast writes. Actual ordering occurs in memory,
> and results are eventually flushed from memtable to disk.
> There is no similar ordering for reads.
>
> -+ Tatu +-
>

Re: Why are writes faster than reads?

[Tatu Saloranta <ts...@gmail.com>]

On Tue, May 25, 2010 at 4:04 AM, Mark Greene <gr...@gmail.com> wrote:
> I'm fairly certain the write path hits the commit log first, then the
> memtable.

True, but that does not make them any less sequential -- journal logs
are strictly sequential fast writes. Actual ordering occurs in memory,
and results are eventually flushed from memtable to disk.
There is no similar ordering for reads.

-+ Tatu +-

Re: Why are writes faster than reads?

[Mark Greene <gr...@gmail.com>]

I'm fairly certain the write path hits the commit log first, then the
memtable.

2010/5/25 Peter Schüller <sc...@spotify.com>

> > I have seen several off-hand mentions that writes are inherently faster
> than
> > reads. Why is this so?
>
> I believe the primary factor people are referring to is that writes
> are faster than reads in terms of disk I/O because writes are
> inherently sequential. Writes initially only happen in-memory plus in
> a (sequentially written) commit log; when flushed out to an sstable
> that is likewise sequential writing.
>
> Reads on the other hand, to the extent that they go down to disk, will
> suffer the usual overhead associated with disk seeks.
>
> See http://wiki.apache.org/cassandra/ArchitectureInternals for details.
>
> --
> / Peter Schuller aka scode
>

Re: Why are writes faster than reads?

[Peter Schüller <sc...@spotify.com>]

> I have seen several off-hand mentions that writes are inherently faster than
> reads. Why is this so?

I believe the primary factor people are referring to is that writes
are faster than reads in terms of disk I/O because writes are
inherently sequential. Writes initially only happen in-memory plus in
a (sequentially written) commit log; when flushed out to an sstable
that is likewise sequential writing.

Reads on the other hand, to the extent that they go down to disk, will
suffer the usual overhead associated with disk seeks.

See http://wiki.apache.org/cassandra/ArchitectureInternals for details.

-- 
/ Peter Schuller aka scode

Re: Why are writes faster than reads?

[Mark Robson <ma...@gmail.com>]

On 25 May 2010 09:04, David Boxenhorn <da...@lookin2.com> wrote:

> I have seen several off-hand mentions that writes are inherently faster
> than reads. Why is this so?
>

In addition to the points that other posters made, writes only need to go as
far as your battery-backed raid controller, whereas reads go all the way to
the disc, possibly quite a lot of times (to search a tree structure for the
right block). The client has no option but to wait for these.

For durability, you just need the data to be in battery-backed ram in the
controller, which is a pretty fast path, provided it has sufficient
throughput to get the blocks on to disc faster than they're being written to
(which should not be a problem for Cassandra's sequentially-written commit
log and sstable files)

Mark