I was translating some document from German to English, that had my surname in it.
It got translated to ‘Beesley’, and I immediately thought of Angela Beesley, chair of Wikimedia Advisory Board. I started playing more, and did find, that:
- French ‘Domas Mituzas’ to English translates as ‘Anthere fall’
- ‘Mituzas’ in German is ‘Schindler’ (Matthias?:)
- Spanish ‘Domas Mituzas’ to English translates as ‘Anthere Anthere’ (every wikipedian has a bit of Florence inside :)
- English to Portuguese renders me as “Domas Lessig” (I have creative commons t-shirt :)
- English to Chinese is “florence 100,000″…
Thats what Web 3.0 is all about. Tampering with my personality. Who am I? :)
Just spotted amazing article, how Citizendium built better infrastructure than Wikipedia’s. There lots of fascinating details there, like…
They went with PostgreSQL for a number of reasons, including better scalability. PostgreSQL is an MVCC database. Unlike Wikipedia, Citizendium never has to lock the database for reads and writes. MySQL can do a lot of things quick and replicate them to slave servers, but PostgreSQL excels at complex functions and full features like JOINs and can do complicated categories and full text searches faster than Wikipedia.
If PG can function without locks, it must be definitely more scalable. InnoDB uses mutexes, spinlocks, etc – and that internal locking can be a bottleneck in many cases. Additionally, if a row is updated, a lock on the record is acquired. It is still a question how PG maintains ACID without any locks, got to research on that more.
I’m aware that MySQL isn’t best at full-text search out there – but Wikipedia uses Lucene for full-text search, so it is somewhat strange to hear that Citizendium platform is faster in that regard. And… I’m not sure where JOIN performance is really faster there – especially when we do lots of covering-index based joins. Probably the key word there is ‘complex’, though I’m not sure what that means :-)
The first reason not to use MySQL was:
First, to be different from Wikipedia.
Indeed, I always support critical thinking! Though this one:
Finally, we felt from reading various mailing lists over mediawiki development that mediawiki was hitting the ceiling of the features MySQL can provide as a backend.
IIRC that came from single post on single mailing list from someone who is not running Wikipedia backend. Mhm.
Of course, their monthly traffic is equal to our single minute traffic, so some views might differ…
This email thread made my day :-) Tim is awesome.
Congrats to Evan – his Wikitravel won a Webby (and has lots of my personal sympathies). Yepeee. For some people ‘wiki’ means wikitravel more than wikipedia. Wikipedia was winner of ‘best community’ and nominee of ‘best practice’ back in 2004. Yay MediaWiki! :-)
Dude, that is so good – the map of online communities. I’m not lost anymore.
Tim O’Reilly wanted to hear Amazon S3 success stories and numbers. In short, Amazon S3 allows organizations to outsource their storage and they say one can save lots of money. I wondered how that applies to Wikipedia environment and did some calculations. Continue reading “Cost analysis: S3 vs Wikimedia”
I already announced about coming to MySQL Conference, but I didn’t realize preparing for it will take that much time. Last year I had just regular session about Wikipedia’s scaling and did feel that it is somewhat difficult to squeeze that much information into less than one hour. This year I opted in for 3h session (with short break in the middle), and instead of few slides with buzzwords on them I worked on workbook-like material to talk and discuss about.
Presentations are always easy, I have to admit I’ve made quite a lot of my slides an hour before actual talks. Now I realized that writing a workbook ends up to be a book, and books are not written in single day… Full disclosure: I looked at last year’s presentation files and blog posts for preparation of the talk, but still, things have changed, both in technology and in numbers. We have far more visitors (ha, >30kreq/s instead of 12kreq/s!), more content, slightly more servers and less troubles :-)
Today I’ve delivered the paper for printing (dead tree handouts for session attendees!), but there are many ideas already what to append or to extend, so this will end up being perpetual process of improving. Let’s hope tutorial attendees will bring their laptops for updated digital handouts.
Of course, the good part is that the real work will be over after first day and I’ll be able to enjoy other sessions & social activities. If only I survive the staff party..