Actually the code for the DB is very modularized. You just have to exchange one library and you can use a different databases. I have tinkered with this for PostgreSQL and Oracle but never for any other DB (while I have experience with Sybase and Informix, I have never used DB2).
I have had people from IBM approach me about doing a DB2 port, but no one has every offered any code and I have enough to do as is.
One of these days though I would love to setup slash on an IBM mainframe and actually benchmark it. I suspect it would run quite well (even with MySQL).
Oh very true. Sometimes you can't get around using subselects (there are a couple of places in Slashdot that are exactly in this situation).
There are other things I would rather see though. For instance in Oracle you can represent Graph structures in the databases (quite cool). I would love to have this for comment storage. Right now it is quite a pain in the ass to generate the comment pages in threaded/nested mode.
Actually, Slashdot's user tables are innodb (the transaction tables). So is the stories table. So far innodb has turned out to work really well. We have always had problems with the SELECT/INSERT penaltly and Innodb has solved that for us.
You know, most of the time someone using a subselect just lacks the imagination needed to do a join:)
On a serious note, you will find that most of the time a subselect ends up being your worst nightmare for performance reasons. Its normally better to find a way around them.
I am gone to Linux World Expo, when I get back the failover should be in place. I have been testing the new replication stuff and it seems to be working fine for me (this is for Slashdot).
Its a historical thing if you think about it. When slashdot was first started XML wasn't a real reality and MySQL would have flopped on the Hardware Rob had with that many comments in the DB.
To make this work the entire schema was redone (mainly keep blobs away from other attributes).
The arrowpoint is being "adjusted" at the moment, so yeah, the site is fucked till that is done.
Nice to see that it doesn't crash despite being completey swamped with connections:)
We are having to modify some of the database parameters to take the additional load. This mainly involved getting the use that the database runs as (mysql) and upping some of its ulimits. The other thing was we had to up the number of conections MySQL allows.
The frontpage without your id is something I put in place a few months ago. Basically in the past when we took the database down, the entire site went down. Now what happens is that everyone who is after a page that is generated by the database will get the front page rendered statically. Not great, but better then nothing.
Actually, College Radio stations which are non-profit do not have to pay the RIAA fees since they make no money off their broadcasts (this was at least true in 1990 when I worked for WRFL in Lexingtn Kentucky).
I had always long hoped that the same licensing would occur with public Internet Radio Stations.
We went over 300K of users about two weeks ago. The answer about the future is that we could easily (even today) handle the additional growth to 500K. At the moment its just an issue of adding memory to our databases.
The solution is to use all switched ports and lock down the ports to specific MAC addresses. That should solve most of your problems in this area. You could also just walk the switches looking for new addresses everyday.
I like MySQL, but I am hard pressed to call what they implemented replication. It has zero ability to handle fault tolerance and I don't think that people who are accustom to the big comerical databases are really going to consider it for critical applications until this is implemented well.
I really wish they would have just called this a RO load balancing option, since when you invoke the word replication it means a lot more.
You should look at experiments that the USGS did with injecting water into joints to determine if this could keep earthquakes from happening.
I would have a hard time believing that the weight of lakes by itself could cause earthquakes.
Slashdot Mirror
Actually the code for the DB is very modularized. You just have to exchange one library and you can use a different databases. I have tinkered with this for PostgreSQL and Oracle but never for any other DB (while I have experience with Sybase and Informix, I have never used DB2).
I have had people from IBM approach me about doing a DB2 port, but no one has every offered any code and I have enough to do as is.
One of these days though I would love to setup slash on an IBM mainframe and actually benchmark it. I suspect it would run quite well (even with MySQL).
Oh very true. Sometimes you can't get around using subselects (there are a couple of places in Slashdot that are exactly in this situation).
There are other things I would rather see though. For instance in Oracle you can represent Graph structures in the databases (quite cool). I would love to have this for comment storage. Right now it is quite a pain in the ass to generate the comment pages in threaded/nested mode.
Actually, Slashdot's user tables are innodb (the transaction tables). So is the stories table. So far innodb has turned out to work really well. We have always had problems with the SELECT/INSERT penaltly and Innodb has solved that for us.
You know, most of the time someone using a subselect just lacks the imagination needed to do a join :)
On a serious note, you will find that most of the time a subselect ends up being your worst nightmare for performance reasons. Its normally better to find a way around them.
I am gone to Linux World Expo, when I get back the failover should be in place. I have been testing the new replication stuff and it seems to be working fine for me (this is for Slashdot).
This is just me testing comments.
Its a historical thing if you think about it. When slashdot was first started XML wasn't a real reality and MySQL would have flopped on the Hardware Rob had with that many comments in the DB.
To make this work the entire schema was redone (mainly keep blobs away from other attributes).
Thank you, that was a lot of hell to make that work :)
The arrowpoint is being "adjusted" at the moment, so yeah, the site is fucked till that is done. Nice to see that it doesn't crash despite being completey swamped with connections :)
We are having to modify some of the database parameters to take the additional load. This mainly involved getting the use that the database runs as (mysql) and upping some of its ulimits. The other thing was we had to up the number of conections MySQL allows.
The frontpage without your id is something I put in place a few months ago. Basically in the past when we took the database down, the entire site went down. Now what happens is that everyone who is after a page that is generated by the database will get the front page rendered statically. Not great, but better then nothing.
Actually, College Radio stations which are non-profit do not have to pay the RIAA fees since they make no money off their broadcasts (this was at least true in 1990 when I worked for WRFL in Lexingtn Kentucky).
I had always long hoped that the same licensing would occur with public Internet Radio Stations.
I picked them because I use them on http://tangent.org/ and happen to think they are pretty cool for webpages. :)
FWIW I happen to be color blind
Actually, its the topic that the user selected for their submission and I could not find another one that fit any better.
We went over 300K of users about two weeks ago. The answer about the future is that we could easily (even today) handle the additional growth to 500K. At the moment its just an issue of adding memory to our databases.
The solution is to use all switched ports and lock down the ports to specific MAC addresses. That should solve most of your problems in this area. You could also just walk the switches looking for new addresses everyday.
I like MySQL, but I am hard pressed to call what they implemented replication. It has zero ability to handle fault tolerance and I don't think that people who are accustom to the big comerical databases are really going to consider it for critical applications until this is implemented well.
I really wish they would have just called this a RO load balancing option, since when you invoke the word replication it means a lot more.
You should look at experiments that the USGS did with injecting water into joints to determine if this could keep earthquakes from happening.
I would have a hard time believing that the weight of lakes by itself could cause earthquakes.