launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Heya Rob,

У уто, 16. 11 2010. у 17:37 +1300, Robert Collins пише:
> Its better at writes vs reads (because it has an append-only store
> (which does automatic compaction - rather like bzr)). If we fit our
> system on a single DB server *and expect to do so indefinitely* then
> staying in a relational single-server model is ideal. (We've outgrown
> a single-server for reads, but not for writes - and we have headroom
> there).

When you say "better at writes vs reads", I wonder if that includes
updates: with a fully "pre-joined" data set, I can imagine it being even
slower than reads if it doesn't simply "deprecate" the old row
("append-only" suggests it does).  How does it actually work?

That relates to a specific use-case I have in mind: translations sharing
that we do.  With our current model, updating a single translation in
one place updates it for a dozen or so "contexts" (i.e. in both Ubuntu
Lucid and Ubuntu Maverick).  It means we'd have to do a dozen updates to
replicate the functionality with a fully denormalized model, and if
updates are slower (they basically include a read, right?) then we'd hit
a lot of trouble.

I can elaborate if you are interested in exploring this use case, but
it's probably best done through a live chat.

OTOH, if update performance is very good, the read performance for the
other "direction" (where we collate all translations for a particular
English string) would be more interesting.  Basically, it's a simplistic
"translation memory" feature: go through entire DB of different contexts
and fetch translations for a particular language for that particular
English string.  That's a feature that's causing us mild issues with
Postgres atm, and if reads are comparatively slower, we'd be even worse
off.

Cheers,
Danilo