Posted in scalability
Tue, 24 Oct 2006 16:56:00 GMT
Recently eWeek ran an article on eHarmony's storage scaling solution choice which discussed how they chose to go with proprietary solutions from 3PAR and ONStor. I was hoping to learn something interesting about their deployment architecture but the most interesting things I learned was that eHarmony has 8+ million users, 9+ million photos and their proprietary solution vendor choice. Some interesting quotes from Mark Douglas, eHarmony's VP of Technology:
Posted in apple
Thu, 19 Oct 2006 04:03:00 GMT
I've been a happy iPod user for some time now, however I've only ever used my single iPod with a single iTunes install. I recently reinstalled my OS after wiping the hard drive for a clean start. To my surprise a fresh install of iTunes with the same iPod serial number would not import songs from my iPod into the iTunes library. iTunes had the gall to ask me if I wanted it to erase all the music on my iPod and replace it with the (empty) contents in its library. Essentially my iPod was orphaned. I've never thought about Apple DRM issues before but I'm no longer as excited about the iPod and iTunes as I was before.
Posted in scalability, mysql
Fri, 06 Oct 2006 03:07:00 GMT
I just ran across the MySQL Web 2.0 page which lists a number of their users including the following:
The most interesting thing from that page, however, is links to various presentations given by those sites on how they architected their sites to scale with MySQL, some of them scaling up to hundreds of MySQL servers.
Posted in perl, mysql, unicode, orm
Mon, 02 Oct 2006 15:35:00 GMT
One of the mysteries of Perl to me is that why, as of yet, is there no UTF-8 support in DBD::mysql although this issue has been discussed on the msql-mysql-modules list since at least 2003 (using the MARC archives). This is also given that MySQL does have UTF-8 support itself.
Posted in perl, mysql, xapian
Mon, 02 Oct 2006 08:08:00 GMT
I recently looked at using various encodings for hashed UIDs, e.g. UIDs generated by a crytographic hash algorithm such as SHA-1 or MD5. These are often useful when the UID does not need to have human meaning but should exhibit some uniformity, such as character set and length. I considered Base64 and hexadecimal first because they are commonly used by crypto libraries and then decided on Base64 and Base32 where appropriate. Base36 is actually the most compact case insensitive encoding (using Arabic numbers and Roman letters) but is not an option for me at the moment because there's no Perl module for it that will take arbitrary text and binary input at the moment. Math::Base36 exists but only handles numbers.