Archive for June 2007

Localization: ms_MY represents Bahasa Malaysia now

I’ve never been a big fan of localization, especially in the Malaysian context. After all, Malay (ms_MY) is a bit of a sham. The proponents choose to believe that Bahasa Melayu is spoken in Singapore, Brunei, and Indonesia, and is rather an important language. Till the proponents realize that Indonesia has a rather thriving population speaking Bahasa Indonesia (granted, for technical terms, ms_MY and Bahasa Indonesia are quite similar). Singapore speaks English, while acknowledging BM, Tamil and Mandarin as national/official languages.

For a language that is spoken by at most 30 million people, most of whom can converse (i.e. read, write, speak) in English well, I find the translation effort a waste of time. Granted, there are a handful of stubborn people that refuse to go global, and learn to converse in English in Malaysia, because they believe the national agenda to be all important – these are the exact folk that will be left in the doldrums in the much touted K-Economy. Its okay, I’m sure the government will find some way to bail them out while oil money is still hot.

My purpose of this blog isn’t to bash the Malay language or translation efforts. Its to announce that I finally see a glimmer of hope as to why the translation might make a tiny speck of sense. Its not Bahasa Melayu or Malay. Its Bahasa Malaysia. For something that’s been around since last April, I wonder why it hasn’t taken on further?

“The Malay language belongs to Malaysians of all races and not just the Malays. The term Bahasa Malaysia would instill a sense of belonging,” Zainuddin told The Star yesterday.

Of course, Malaysia should look upon Singapore when it comes to recognizing national languages… The article also blames Anwar Ibrahim, the ex-DPM who had an affinity for backsides, for the change when he was education minister, back in 1986. How timely. If this is for national unity, I’m all for it. I then see the value in ms_MY. Translate away to Bahasa Malaysia!

Technorati Tags: , , , , , , ,

Ticketmaster thrives on MySQL Replication

Even though the conference is long over, I still have unpublished notes sitting on my ~/Desktop, and it only makes sense that I clean it out. These are notes from Ed Presz’s session, titled For Ticketmaster, MySQL Replication is the Ticket! They are as always, pretty raw.

We were all given a handout, which was some corporate spiel, which contained a lot of information about hiring. Their mission is to “sell more tickets better than anyone in the event business, worldwide”.

I found it impressive to note that Ticketmaster managed last year’s Melbourne Commonwealth ticket sales. I guess, even more impressive is that for next year’s Beijing Olympics, Ticketmaster ran a ticket lottery, and 17,843 seat tickets were sold in 75 seconds!

MySQL 4.0.18 is currently used, and they plan to upgrade to MySQL 5.0.27 in 2007 – difference in the join syntax between 4 & 5 was a blocker. Reference was made to mysql#13551.

They use InnoDB, for its row-level locking, referential integrity, transaction support. The average size of the “event” database is ~20GB, with around ~230 tables. Rely heavily on MySQL replication. At any one time there are between 100,000 – 130,000 visible events!

MyISAM tables for full-text searching (InnoDB doesn’t do this yet) and LiveDaily. Using vBulletin, MyISAM performs better too.

One-way replication is very fast. No/minimal performance hit on MySQL master. Its real easy to add slaves. Dual masters, a farm of slaves (4) [cluster], then 4 more slaves of those slaves. Then they send all traffic to the lower level slaves.

Think through your architecture, since there is no multi-master replication. A slave can only have one master. Setup two instances of MySQL on MySQL_Server_1 listening on different ports (but this is not what they use). They use Bi-Directional replication (multi-master, circular, dual-master). Replicating from the UK to the US. They use UTF-8 and UTC time on the servers.

innodb_flush_log_at_trx_commit=0 – resulted in huge performance improvement with MySQL replication. However its not writing to disk at each commit, so you can lose 1 second of insert/update/delete values in the event of a crash. Mitigated the risk because there are so many slaves.

Technorati Tags: , , , ,


i