I don't think edits need to show up immediately to users who just query the DB - besides edits need to be voted
And if I remember correctly, the disk space required for MB isn't an issue
a read-only (query only) server could be much more optimized, couldn't it?
I wonder what last.fm developers would have to say on that topic...
Isn't muz one of them?
nullptr
yeah is
warp follows nullptr and segfaults
Aankhen`` has quit
i is in ur computer faulting segments
yeah and it caused aankhen to reboot
damn i have SQL headaches myself at
atm*
i was really looking into the column based databases, and am testing an implementation of D atm
Muzzz
copper: eh?
Aankhen`` joined the channel
nullptr
aaahhhhhh it's so relieving that Dr. Who doesn't have these f*cked and so loved cliffhangers from US TV shows
that's so braindead
also the xmas special is cute
copper
Muzzz: I was wondering how appropriate column-oriented DBs would be to MusicBrainz, and was hoping for some insight based on your experience with last.fm - http://www.databasecolumn.com/2007/09/one-size-...
Muzzz
Ah, DB work like that isn't my forte, I just run the queries and do various other stuff
I don't actually set up the database, and maintain, so I'm the wrong guy to ask :)
copper
ok
outsidecontext
what are the advantages of column based storing?
copper
fast reading
(but slow writing)
outsidecontext
if you mainly read the data of one (or a few columns) for long lists, right?
copper
given all the datamining going on at last.fm I'd assume column-oriented DBs would be even more beneficial to them
outsidecontext: right
it also compresses very well
Muzzz
copper: given the massive amount of writes we do, the large number of different databases, that'd be a silly assumption to make
A common misconception is that the charts are stored in a db, which they're not really
copper
Muzzz: I thought maybe using different types of DBs for different applications would help?
outsidecontext
copper: then my guess would be that this is not so beneficial for MB. there are a lot of edits and display of single or just a few rows
copper
ok
Muzzz
I also seriously wonder how well that idea scales
outsidecontext
copper: but that's only a general "feeling" :-) a look into the actual database queries would be better
Muzzz
May look to work great on a table with thousands of rows, but how's about millions heh
copper
Muzzz: why would it scale less well than row-oriented DBs?
outsidecontext: the idea was to duplicate MB's DB into a column-oriented DB on a separate server for queries, and an edit-only row-oriented DB
I'm not saying it *would* be better, only wondering if it would :)
outsidecontext
copper: ah. interesting idea. don't know
copper
the major argument being that edits don't show up immediately anyway, since they need to be voted
(it might be a different story for last.fm though)
for what it's worth, the existing DB for MB wouldn't need to be changed
if there's a failure with the read-only DB just revert back to the "master" DB
warp
copper: hm, most add edits show up immediatly. and pending edits, while not showing up as such, are marked with a different background-color:, etc..
copper
yeah I knew about that, just thought I could live without it
warp
please no :)
copper
lol, why not?
warp
when i see an album in need of lots of fixes, i tend to go in and fixit.
if the tracklisting is yellow all over, probably someone is on it already.
copper
surely frequent editors must be a minority - they could use the master DB
the idea is to direct the bulk of users, doing mainly queries, to a faster read-only DB
warp
ok, i'm just stating that I could not 'live without it'.
copper
lol, ok :)
warp
anyway, back to work :)
copper
yeah them lines ain't going to code themselves ;)
(or whatever it is that you do for a living)
warp
yes. code. php. and I have a deadline today.
brrr. php.
outsidecontext
warp: poor guy
Amberrock joined the channel
luks joined the channel
Prodoc joined the channel
Prodoc
good afternoon
srotta
copper: One thing to notice is that the writer is founder of Vertica.
copper: So it's no wonder it sounds good to him.
And it starts with, IMO, false assumptions, so I'm inclined to take it more as marketing than anything else.
(Anyone taken a look at Oracle/DB2/pickanydatabase innards lately?)
copper: main reason I don't buy into that article is, it only takes 3 of the 5 large db's into account, the 3 that support his point, not the ones that are counter to his "historical reason why it is this way"