I appreciate your reply, Rik. Would it make more sense then to perhaps have a 'database' oriented VM (or kernel), a 'web server', 'embedded device' etc system? Granted such levels of specialization aren't always that clear cut but I know of many a situation in which each machine has a well-defined primary (obviously your web box can also be your POP3) roll. I know I try to keep the web boxes separate from the DB machines (since they are two wildly different methods of spitting out data to the user) and so on and so forth.
I believe that the trend is to optimize Linux for the very powerful machines (multiprocessor and with a lot of RAM). Do you agree with me?
No, not at all. The embedded Linux market seems to be much more active than development of Linux on high end servers. On the other hand, the high end server improvements tend to touch more code in the core kernel while a lot of the embedded systems people just keep separate patches and have no plans of merging their code with Linus.
I'm not so sure I agree with him -- if you want to make a dent in the market shares of Solaris and NT/2000/XP you have to keep up with their innovations (Async-I/O, better SMP, etc.). As a user of Linux as our OS of choice for our database and web servers I am feeling a lot of pressure to switch to Solaris because of their better handling of higher-load environments (OLTP databases, web servers, etc.). If Solaris wasn't so damn expensive we'd probably be using SunFire 280's. So I'm pleading to keep up with the big dogs so that I can be reassured that Linux has what it takes (it's handling things fine now but as he said in the article, everyone needs more RAM, CPU, etc.).
How is that coming along? From what I recall it was put in 2.4 but it had some goofy bugs. I'd like to use it on our database (Sybase ASE 12.5) and just wondering if they've made any improvements yet.
I own a Dell Inspiron 8000 with a GORGEOUS 15.1" UltraXGA screen. It's wonderful to look at and sometimes it's even easier on my eyes then my dual 19" CRT system on my workstation.
However, from what I understand about LCD screens is that they need to be mated with particular video cards (digital, of course) in order to even come close to high-quality laptop LCDs. Laptop manufacturers mate the best LCDs with the best, tuned, video cards in order to achieve the best display out there. With a much wider array of desktop LCDs and video cards you'd be hard pressed to be able to perfectly match a digital video card to a LCD display without massive amounts of time, money, and trial-and-error.
I also work at a computer department at a University (around 16K students). We also have been having this problem - of painfully slow download rates (e.g. web and email) because of, namely, Morpheus, Napster, etc. The old lore is that back in the day of when we had a couple T1s we noticed an unusually high amount of bandwidth coming from a few IP addresses... and by unusually high I mean taking up 90%+ of our bandwidth. So we had the bursar put a charge of $300,000 (which was accurate for how much we paid for bandwidth at the time) for "Bandwidth Usage" on their accounts and had that sent off to Mommy and Daddy. Immediately their bandwidth hogging ceased (upon further investigation it was shown they were running multiple FTP sites and some sort of an ISP web hosting business out of their dorm room) and we explained to their parents what abusive behavior of our networks was. They didn't appreciate it, but they did appreciate the fact that we removed the charge - provided of course their sons refrained from such activity in the future.:)
I run Win2K on my laptop (PIII850, 256MB RAM, etc.) and it runs fine. It runs everything I want it to just fine.
I also run Win2K on my 1.333GHz Athlon (which has 512MB PC2100 DDR). Runs great there as well.
However, I noticed that, either psycologically or actually, XP on the computer I use at work (PIII1GHz, 256MB RAM) seems to boot up far faster than Win2K. I can't quite figure it out - I understand it's a brand-new install so perhaps it hasn't had time to accumulate software bloat, but it's not like my systems have a ton of system services starting. As a matter of fact I make it a rule that nothing starts up aside from what Windows needs to run (e.g. no WinAmp agent, AIM, etc.). But XP will beat Win2K to the login screen every time and be 'up and running' faster than 2000. XP seems like a decent OS but there's no real reason (other than the startup/login speed) for me to upgrade from 2000. 2000 does everything I want and I don't have the time, money, or inclination to upgrade 2 boxes to XP (and yes, you can turn off all the fou-fou WinXP eye candy and make it look a whole lot like 2000. The one really neat thing is that it stylizes (aka 3D shading) all the web form elements (like submit buttons, checkboxes, etc.) which is really neat).
Do I trust the other group to do the same for me? Would I trust them to pay me more if they had the chance?
If the answer is no, then I will concede the extra buck and take $2. If the answer is yes, then I will take the extra dollar and expect that the other group, when given the situation, will do the same for me.
If you don't buy the trust then maybe it's not so much fairness but unfairness. "Why should I take less than some other group?" More wealth equals higher status. We all know this - it's kind of like trying to "keep up with the Joneses" sort of situation.
Let's say the issue was between something else, say computers. The choice is between two very decent brand XYZ (insert your own, high-quality) systems (say a 1.5GHz chip, 512MB RAM, etc.) that are perfectly acceptable for everyday use and will last 4 years. Or, you can get a 2GHz chip, 1GB RAM, 60GB HD and the other group would get a dual 3GHz, 4GB RAM, multiple hard drive beast. The rational person in me wants the 2GHz box... but the geek in me really wants the dual proc box.. and the geek also knows that all the recipients of the dual machine will brag endlessly upon how much theirs 'roxx0r'. So I settle for the 1.5GHz box and we're all the same.
It reminds me of the old joke:
Bob is sitting in his house one day when he hears his doorbell ring. He answers the door and there's a man with a suit holding a large wooden box with a big red button on the top. The man explains that the moment Bob presses the button he will receive $1,000,000 - and someone he never met will die. The man leaves the box with Bob and repeats the conditions. Bob goes back in to his easy chair and stares at the box but decides that killing someone is just too much for him to bear, and puts it in the closet. A couple of months later Bob remembers the box. So, he goes back to the closet and retrieves the box. He then hesitantly presses the button. Immediately his doorbell rings. Bob goes to the door and surprise; it is the same man in the suit who brought Bob the box. This time, however, instead of holding a box he has an oversized cashiers check for $1,000,000 made out to Bob. Bob takes the check, but before he can close the door the man asks Bob for the box with the button on it. Bob fetches the box and hands it to the man and asks him what he is going to do with the box. The man replies "I'm going to give it to someone you've never met."
One of my friends had a wireless mouse 'back in the day' maybe 3, 4 years ago... What struck me the most about it was:
a) the size (it was much larger)
and
b) the weight (much heavier)
I attribute that to the RF transmitter (or whatever it used, but it certainly wasn't a fun experience. I wouldn't mind a cordless mouse (one of my mice's cord likes to get stuck behind the monitor and I have to yank it out) if they could keep the same size and weight of my intellimouse optical.
User enters site
if form is on their end:
user enters CC info,
surepay verifies
surepay pokes you with:
MD5( $cc_num . $secret );
$userid;
expiry;
you store it in your DB
else form is on your SSL site:
user enters CC info
you verify
you store
MD5( $cc_num . $secret );
$userid;
expiry;
end if
then you routinely poke their servers when you figure out the expiry is up and the end user hasn't quit.
Or, of course, if surepay has the ability to re-bill someone, use their automagic service.:D
I was thinking about this the other day (since we're trying to do the same thing on our site) and I think it would take some sort of a special arrangement or a special package (if they didn't offer it before).
The details are something like this:
set up a database on your site to hold this type of information:
cc_hash,
payment_expiry,
userid,
etc.
Then, when the user vists your store (unless you are paying for the SSL license chances are you're redirecting to surepay, correct?) have it embed a userid (or whever you keep track of on your end) form field. After the user pays, have the surepay place either post a SSL form, send you an encrypted e-mail, etc. with the CC number (or some other form of identification) MD5'ed back to you. You can store that hash (hashed with maybe a secret 'salt' that only you and sureplay know) along with the userid in some table. Then, when the payment_expiry date rolls around, you can poke surepay with the userid and cc_hash so they know you still have their CC number (surepay would keep the unencrypted version and could generate your MD5 hash). Obviously if someone was evil they could break in and 'steal' your table but all that allows them to do is re-signup your current members (and that wouldn't be too difficult to un-do either).
I guess I don't notice the Office2000 leak or it doesn't effect me that much. Then again, I only run Word 2000 to spell-check my forum/slashdot posts so perhaps I'm just not running it enough to notice the leak?
But you're right that as more and more people like to download movies off of Morpheus, edit their home movies, and open 70MB images in Photoshop more RAM will certainly help.
I have 512MB DDR now and it's great.. But seriously Windows 2000/XP doesn't 'need' more than 256MB or so nor could I discern a difference between 256MB (on my laptop) and 512.
Linux runs great as a DB/web server on my PII400 with 384MB..
Even 4 years ago I was using 128MB with no probs. Why would the average home user need more than 512MB? Even with the eventual Windows bloat I highly doubt 512MB will be 'needed'.
Miami University in Oxford, OH also makes extensive use of 802.11b. It's in most of the admin buildings and quite a few academic buildings. It also lives in all the libraries and extends to the surrounding outside areas (as if anyone could read their laptop LCD outside anyway:))
Re: Me getting a new desktop in 2004:
I doubt it -- I have a PII400 I've used for the last 4 years... it served me very well until I got bitten by the Wolfenstein 3D bug over the summer and realized I 'needed' a new box so I built myself a 1.333GHz Athlon which I expect to keep until it blows up. Same with the PII400, it's a linux test box for FanHome which I keep all the dev code on .
I suspect, though, if things are that cheap in the year 2004 I'll go ahead and pick another computer up; I already have 3 -- another couple couldn't hurt (except the electric bill).
Wireless mouse and keyboard? Puh-lease. Those have been around for 5+ years and never, ever caught on (both infrared and RF). I doubt somehow we're going to want to sit on our couch and stare at our monitors. Why waste bluetooth bandwidth on your keyboard/mouse? I think the biggest drawback will be the need to replace batteries and/or plug the keyboard into the wall to recharge them. You'll always be working on a big paper or playing the perfect game of Counter Strike when your keyboard batteries die.
I dislike the idea of everyone using Bluetooth until their protocol isn't redicoulously easy to crack. Weren't there some stories posted a while ago about how easy it was to crack 128bit 802.11b -- with everyone and their mother using bluetooth it would be a cinch for someone to set up a wireless sniffer and read all your keyboard inputs (passwords, etc.).
Re: Laptop
I have a Dell Insprion 8000 that I purchased last May. It was faster than my desktop at the time so it truely was a replacement. It's a PIII850 with 256MB RAM. Runs great for what I use it for (when I'm on the road or otherwise away from my home computer it checks my mail and provides Age of Empires 2 gaming ) and I don't hope to replace it any time soon. It has a 15" LCD already and I couldn't imagine anything larger since as they said it would get HUGE. As soon as they develop those 'roll up' organic LCDs (which they've been talking about for 3 years or more now so I doubt all of a sudden they'll appear) they could have a laptop without any screen and then some sort of 'projector' type screen which you set up. I also have and use 802.11b at home and at work which is great although it is a separate PC card which sometimes I forget. If it was built-in like the Mac Ti Books (which are AWESOME btw) it would be a lot easier... Although one would think that would limit upgradeability since you'd have to rip the thing apart to replace the 802.11b with 802.11a. I don't know why they've limited the RAM to 256MB -- mine has that now with one slot free (for another 256MB DIMM I guess). If we're going to truely have desktop replacement laptops I'd see no reason why to get 512MB RAM (certainly whilst it is pennies on the dollar compared to even a year ago).
I'd like to comment on both the heat issues and the fragility issues. A couple months ago my friends and I went to the local MarketPro computer show and picked up a couple Asus A7M motherboards and Athlon 1.333 and 1.4GHz CPUs.
When we got them to our respective homes mine, for some reason, kept beeping (no RAM or invalid memory type). Grabbed my friend's known-good RAM and still had the error. Thought it was my CPU, so I took it over to my friends house. All I wanted to see was it POST since it couldn't do that on my mobo @ my place. I popped it in (sans heatsink:oops:) and turned it on. Immediately some text appeared (BIOS junk) so we turned it off.
Got a new motherboard in the mail 3 days later and I pop everything in. No worky!:( I took it back over to my friends, stuck it in there (with a heat sink this time) and tried it. No dice. All it took to fry my CPU was around 1 or 2 seconds w/o a heatsink. AMD was kind enough to ship me off another one a week later and it's been running great since. Moral of the story? Always use a heatsink. Second moral of the story: read the manual, since in big bold letters AMD says 'Under no circumstances should you ever - ever! run this CPU without a heatsink.' (paraphrased).
In regards to fragility somehow in the shuffling of CPUs my friend managed to chip the die on the front - rendering his CPU useless until AMD, once again, cheerfully sent him a new one.
Still on the wrong track!
on
MySQL 4.0 Released
·
· Score: 5, Insightful
If you're listening MySQL -- who really cares about SSL and unicode. Granted I've had them in my RDBMS that I use but still you're missing the big picture.
The people who post funny things like 'MySQL Mad libs' are on to something - Slashdot is full of 'arm chair' DBAs (and programmers and network engineers and etc. etc. etc.) who know just enough to think they know exactly what is wrong and how to fix it. It's kind of like the people who have used a computer for a while and start trying to troubleshoot their friend's computers - 'You may have run out of Megahertz' or 'You probably need more memory to download files faster'. Yes, subqueries, locking issues, etc. are very important. However, these are 'surface' level flaws in MySQL. There are some very, very large problems in the underlying architecture which need to be addressed. Since they're not as glamorous (or as understood) as subqueries and pretty much ignored by 90% of the users they never see the light of day - but they impact almost 100% of the users in one way or another.
Fix things like this:
Filesystem buffered writes. Transactional support is great - it allows me to roll-back aborted transactions. However, due to the inability to control whether or not my tables are write-buffered means that MySQL may *think* it has performed a write even though it is still in the write-cache. I can then turn off the system and voila -- corruption! Part of the fault lies in the OS who tells MySQL it was written even though it is in the cache, but I have a simple solution. Devise a way to selectively turn off buffered writes for certain tables / databases. This way if I know I have a critical table which has a lot of writes I can turn buffering off and be ASSURED that writes will be performed when asked. I suspect a lot of 1040 and other table corruptions are caused by something like this. Yes, performance will take a hit but I think it is a very acceptable trade-off for data corruption. Obviously all system tables should NOT be buffered.
Inability to use more than one index on a table in a query -- most enterprise RDBMS' can use more than one index on a table for a query. This can easily save a table scan or the use of a single, less-efficient index. Given an example query - 'SELECT bob FROM sometable WHERE somecol = 45 and somecol2 = 44' - if I have two indexes on sometable (somecol and somecol2) it can join the two indexes together and
Clustered indexes. These basically physically sort the table based on particular columns. This allows you to ORDER BY username ASC without using anything special since the rows are already sorted on username (if you have a users table and cluster the username col). This also greatly speeds up BETWEEN clauses. And yes, to people who know a little bit of SQL but don't know as much about clustered indexes -- you can create an index with a bobcol ASC but clustering the actual data is faster and more efficient if you are grabbing data which is not on the index. For example, SELECT * FROM table ORDER BY username ASC will not be as efficient as the same query clustered on the username. If you had a sorted index on username it will probably read the index sequentially and then visit the table. That extra operation = more disk seeks = more time / cpu to execute (and it really adds up as the table size increases). However, if you are doing something like 'select username, password from user order by username' it would be better to create a sorted index on username ASC, password. That way it will read the index only and not visit the table at all.
on-line backups. In today's internet world your site has to be 24/7. This means you cannot have significant performance problems (or even offline-ing your dB!) when you make a dump -- Sybase, etc. have done this from as far back as I can remember.
backups to something other than CSV files. MS SQL, Sybase, Oracle, they all dump to a compressed binary file. Saves a TON of space and is MUCH FASTER to dump and load. I can dump a 6GB Sybase DB in under 5 minutes. Loading it all (from scratch) and then bringing the DB online is about the same amount of time.
Ability to specify the number of files to dump to. What happens if you have a dump which is larger than 2GB? Most linux distros cannot handle a single file of 2GB or more. Give users a way to, within the dump statement, split the dump over two files. Sybase has the 'STRIPE ON' clause (originally to dump to two tape drives at once but works fine on filesystem files as well) to split the dump equally over an unlimited number of files.
cleaner way to view query plans of statements. EXPLAIN... is great and all, but the resulting table is a PAIN to read. What I want to know is simple:
Query is using XYZ, ABC tables. Table XYZ is using index 123 which is sorted so I do not need to create a temp table to sort ASC.
Since you have all the columns in your select statement in the index I do not have to visit the actual table - I can pull it all from the index. Because of this, I will read the index from start to finish.
ABC is using index 23dsf which is not sorted so I must create a temp table to sort that. Also, since it is a join, I do not need to perform an index scan but a positioned search (table scan is to a WHERE clause with no index AS index scan is to an index which is not selective enough or needs to read all columns.)
Simple, easy and pretty much even a NOVICE can see that their query is a good performer or a bad performer.
Along with more in-depth EXPLAIN, also provide me with a way to see what the optimizer is doing with the query. In MS SQL and Sybase you have 'trace flags' which you can turn on before your query to see EXACTLY what Sybase is doing - why does it think this index is better than this other one, why is it table scanning when you think it should index sort, etc. Give me an easy way to say 'verbose on; explain xxx;'.
Ability to delve deeply into performance of the system. If there is one job a DBA must know it's how to tell what the heck is going on when something is slow. Currently MySQL gives you meaningless info like 'slow queries'. Great, I see 200,000 of them. What queries are they? What good is it in a large application which may contain 3000 lines of SQL to tell me the raw number of queries which are slow? I want to know the EXACT SQL of the query(s) which are slow and I want to find the one taking up the most CPU time and blocking all the rest. I want to know how MySQL is managing it's data cache so I can see if I need more ram (e.g. it is swapping lots of data to/from the cache) or if I am I/O bound. Don't tell me to look at 'free' or 'top' - half the time it is wrong because you (MySQL) tell it misleading figures. I want *you* to tell me exactly what you are doing since you would know best! If you've ever seen a sp_sysmon output from Sybase ASE you'd know what I'm talking about.
Hire people who are accomplished relational algebra freaks. Pay them a lot of money - it is well worth it!!! If I see another changelog entry like this I'm going to scream:
Optimized queries of type: SELECT DISTINCT * from table_name ORDER by key_part1 LIMIT #
So does that mean these queries were NOT AT ALL optimized before? It doesn't read 'FURTHER optimized'.
"ORDER BY... DESC can now use keys."
Does that mean it was table scanning each time? Jebus! Get these wiz-bangs to overhaul your query optimizer. Hands down this is one of the most important things in the database -- knowing how to use the database statistics and knowing when to use a merge-join vs. a hash-join etc. are CRITIAL to database performance. Trust me when I say that this is a MAJOR priority - especially over SSH or Unicode since it impacts EACH AND EVERY statement which MySQL parses.
Small things which can really raise the respect of MySQL in the eyes of people who matter - the CTOs and CIOs of the world who might be considering something like Postgres or MySQL but opt for MS SQL, Sybase, or Oracle because of the more advanced (but less flashy) features.
Of course, integrated row (or in the least page) locking and full support of subqueries and the like are also VERY HIGH priorities.
I think addressing these issues will vastly improve MySQL -- they're not flames really, just gripes:D
You see solid-state disk drives used mainly in relational database management systems as a 'scratch pad' for highly-volatile data.
In order to explain I'll have to do a quick primer on RDBMS' and how they handle memory management.
As you're probably aware, there are a multitude of different operations you can perform on a RDBMS; UPDATE, DELETE, SELECT, etc.
For more efficient queries the RDBMS will cache physical data structures in memory. It may cache parts of the index or recently accessed data. If the cache is full it will kick out the oldest, least used parts to make some room for the new stuff.
To make a long story short, most servers have way more disk space than RAM. As such, it will use a designated 'temp' or scratch area for some of those sorts (and temporary tables) if there are more important things in RAM or it cannot all fit. In Sybase / MS SQL you create a special database for this called 'tempDB'. I'm sure DB2 / Oracle have similar data structures.
Here is where solid-state disks enter the picture. You can buy a small solid-state disk (9GB or less) for cheap. You then 'create' tempDB on the solid state device. That way you can completely eliminate the relatively slow disk drive for things like sorting, temp tables, etc. and devote all of your RAM to caching database information.
To me, this seems a lot better than using solid-state devices exclusively as a storage medium. Initially when you start up your RDBMS the cache is clean. After people run a couple queries the important (and most hit) indexes and data are cached any way so you do not have to worry about touching the disk unless you perform a write. However in most OLTP (online transaction processing; a la web app) it's mostly selects so you wouldn't receive the benefit of the solid-state device unless it wasn't in the cache.
Most SSDD have a battery-backup in them in case of power failure and are generally mated to a corresponding hard drive. When the SSDD is idle it will flush the writes to the HD to keep the HD up-to-date. On a power failure it will immediately dump changed data to the HD (also battery-powered).
For 'home' systems I can't imagine anyone using SSDD as their primary storage. It doesn't make sense - rarely does anyone perform anything that 'demanding' as to require solid-state drives. Plus, if you have a single memory error you would lose the entire thing (break one of your DIMMs and tell me what happens when you try and boot.):D
I will agree that for 99.9% of MySQL users MySQL runs just fine. They don't need, nor care about, sub-selects, row-locking, triggers, etc.
We used to run MySQL but found that it died *horribly* on heavy multiuser loads. (e.g. 500 concurrent users, all updating/insert/etc.)
I investigated the problem and found out that table locking really, really sucks. Last summer when we had this problem we didn't have the luxury to mess around with pre-alpha table structures and spend countless hours poking around with settings.
I carefully explored the other RDBMS's out there and eventually picked Sybase ASE 11.9.2 for Linux as the best choice. I can say it was hands-down the best choice we made. Now we're at 12.5 which supports SSL, XML, etc. and a host of other features MySQL hasn't even thought of.
Instead of 'dealing' with MySQL we're making money with something else.
So here it is:
If you are having problems with MySQL - DON'T PUT UP WITH IT. There are many other fish in the sea that will better fit your application. Simply because it is 'free' or 'popular' does not make it better for your application.
As someone else said, I always follow the 'pick the best tool for the job' test. If it is out of our price range, we either find a way to buy it or move on to the next item on our list.
I think far too often people perform the 'open source' or 'free' litmus test first -- leading to major headaches down the road.
If we were in this situation today I think we'd rather have picked Postgres, simply because it was a lot cheaper and offers many of the performance-enhancing features as the 'big three'!:)
Slashdot Mirror
I appreciate your reply, Rik. Would it make more sense then to perhaps have a 'database' oriented VM (or kernel), a 'web server', 'embedded device' etc system? Granted such levels of specialization aren't always that clear cut but I know of many a situation in which each machine has a well-defined primary (obviously your web box can also be your POP3) roll. I know I try to keep the web boxes separate from the DB machines (since they are two wildly different methods of spitting out data to the user) and so on and so forth.
I'm not so sure I agree with him -- if you want to make a dent in the market shares of Solaris and NT/2000/XP you have to keep up with their innovations (Async-I/O, better SMP, etc.). As a user of Linux as our OS of choice for our database and web servers I am feeling a lot of pressure to switch to Solaris because of their better handling of higher-load environments (OLTP databases, web servers, etc.). If Solaris wasn't so damn expensive we'd probably be using SunFire 280's. So I'm pleading to keep up with the big dogs so that I can be reassured that Linux has what it takes (it's handling things fine now but as he said in the article, everyone needs more RAM, CPU, etc.).
How is that coming along? From what I recall it was put in 2.4 but it had some goofy bugs. I'd like to use it on our database (Sybase ASE 12.5) and just wondering if they've made any improvements yet.
I own a Dell Inspiron 8000 with a GORGEOUS 15.1" UltraXGA screen. It's wonderful to look at and sometimes it's even easier on my eyes then my dual 19" CRT system on my workstation.
However, from what I understand about LCD screens is that they need to be mated with particular video cards (digital, of course) in order to even come close to high-quality laptop LCDs. Laptop manufacturers mate the best LCDs with the best, tuned, video cards in order to achieve the best display out there. With a much wider array of desktop LCDs and video cards you'd be hard pressed to be able to perfectly match a digital video card to a LCD display without massive amounts of time, money, and trial-and-error.
I also work at a computer department at a University (around 16K students). We also have been having this problem - of painfully slow download rates (e.g. web and email) because of, namely, Morpheus, Napster, etc. The old lore is that back in the day of when we had a couple T1s we noticed an unusually high amount of bandwidth coming from a few IP addresses... and by unusually high I mean taking up 90%+ of our bandwidth. So we had the bursar put a charge of $300,000 (which was accurate for how much we paid for bandwidth at the time) for "Bandwidth Usage" on their accounts and had that sent off to Mommy and Daddy. Immediately their bandwidth hogging ceased (upon further investigation it was shown they were running multiple FTP sites and some sort of an ISP web hosting business out of their dorm room) and we explained to their parents what abusive behavior of our networks was. They didn't appreciate it, but they did appreciate the fact that we removed the charge - provided of course their sons refrained from such activity in the future. :)
Ok -- I was amazed at the difference. If I had the money, I'd be tempted to buy two copies of XP to upgrade my two systems just for that feature!
I run Win2K on my laptop (PIII850, 256MB RAM, etc.) and it runs fine. It runs everything I want it to just fine.
I also run Win2K on my 1.333GHz Athlon (which has 512MB PC2100 DDR). Runs great there as well.
However, I noticed that, either psycologically or actually, XP on the computer I use at work (PIII1GHz, 256MB RAM) seems to boot up far faster than Win2K. I can't quite figure it out - I understand it's a brand-new install so perhaps it hasn't had time to accumulate software bloat, but it's not like my systems have a ton of system services starting. As a matter of fact I make it a rule that nothing starts up aside from what Windows needs to run (e.g. no WinAmp agent, AIM, etc.). But XP will beat Win2K to the login screen every time and be 'up and running' faster than 2000. XP seems like a decent OS but there's no real reason (other than the startup/login speed) for me to upgrade from 2000. 2000 does everything I want and I don't have the time, money, or inclination to upgrade 2 boxes to XP (and yes, you can turn off all the fou-fou WinXP eye candy and make it look a whole lot like 2000. The one really neat thing is that it stylizes (aka 3D shading) all the web form elements (like submit buttons, checkboxes, etc.) which is really neat).
Is it an issue of fairness or an issue of trust?
Do I trust the other group to do the same for me? Would I trust them to pay me more if they had the chance?
If the answer is no, then I will concede the extra buck and take $2. If the answer is yes, then I will take the extra dollar and expect that the other group, when given the situation, will do the same for me.
If you don't buy the trust then maybe it's not so much fairness but unfairness. "Why should I take less than some other group?" More wealth equals higher status. We all know this - it's kind of like trying to "keep up with the Joneses" sort of situation.
Let's say the issue was between something else, say computers. The choice is between two very decent brand XYZ (insert your own, high-quality) systems (say a 1.5GHz chip, 512MB RAM, etc.) that are perfectly acceptable for everyday use and will last 4 years. Or, you can get a 2GHz chip, 1GB RAM, 60GB HD and the other group would get a dual 3GHz, 4GB RAM, multiple hard drive beast. The rational person in me wants the 2GHz box... but the geek in me really wants the dual proc box.. and the geek also knows that all the recipients of the dual machine will brag endlessly upon how much theirs 'roxx0r'. So I settle for the 1.5GHz box and we're all the same.
It reminds me of the old joke:
Bob is sitting in his house one day when he hears his doorbell ring. He answers the door and there's a man with a suit holding a large wooden box with a big red button on the top. The man explains that the moment Bob presses the button he will receive $1,000,000 - and someone he never met will die. The man leaves the box with Bob and repeats the conditions. Bob goes back in to his easy chair and stares at the box but decides that killing someone is just too much for him to bear, and puts it in the closet. A couple of months later Bob remembers the box. So, he goes back to the closet and retrieves the box. He then hesitantly presses the button. Immediately his doorbell rings. Bob goes to the door and surprise; it is the same man in the suit who brought Bob the box. This time, however, instead of holding a box he has an oversized cashiers check for $1,000,000 made out to Bob. Bob takes the check, but before he can close the door the man asks Bob for the box with the button on it. Bob fetches the box and hands it to the man and asks him what he is going to do with the box. The man replies "I'm going to give it to someone you've never met."
It would be nice to see a couple pictures of the interior like most data centers, even if it is a secure area. At least maybe some flash animations. :(
One of my friends had a wireless mouse 'back in the day' maybe 3, 4 years ago... What struck me the most about it was:
a) the size (it was much larger)
and
b) the weight (much heavier)
I attribute that to the RF transmitter (or whatever it used, but it certainly wasn't a fun experience. I wouldn't mind a cordless mouse (one of my mice's cord likes to get stuck behind the monitor and I have to yank it out) if they could keep the same size and weight of my intellimouse optical.
To clarify I guess:
:D
User enters site
if form is on their end:
user enters CC info,
surepay verifies
surepay pokes you with:
MD5( $cc_num . $secret );
$userid;
expiry;
you store it in your DB
else form is on your SSL site:
user enters CC info
you verify
you store
MD5( $cc_num . $secret );
$userid;
expiry;
end if
then you routinely poke their servers when you figure out the expiry is up and the end user hasn't quit.
Or, of course, if surepay has the ability to re-bill someone, use their automagic service.
I was thinking about this the other day (since we're trying to do the same thing on our site) and I think it would take some sort of a special arrangement or a special package (if they didn't offer it before).
The details are something like this:
set up a database on your site to hold this type of information:
cc_hash,
payment_expiry,
userid,
etc.
Then, when the user vists your store (unless you are paying for the SSL license chances are you're redirecting to surepay, correct?) have it embed a userid (or whever you keep track of on your end) form field. After the user pays, have the surepay place either post a SSL form, send you an encrypted e-mail, etc. with the CC number (or some other form of identification) MD5'ed back to you. You can store that hash (hashed with maybe a secret 'salt' that only you and sureplay know) along with the userid in some table. Then, when the payment_expiry date rolls around, you can poke surepay with the userid and cc_hash so they know you still have their CC number (surepay would keep the unencrypted version and could generate your MD5 hash). Obviously if someone was evil they could break in and 'steal' your table but all that allows them to do is re-signup your current members (and that wouldn't be too difficult to un-do either).
I guess I don't notice the Office2000 leak or it doesn't effect me that much. Then again, I only run Word 2000 to spell-check my forum/slashdot posts so perhaps I'm just not running it enough to notice the leak? But you're right that as more and more people like to download movies off of Morpheus, edit their home movies, and open 70MB images in Photoshop more RAM will certainly help.
I have 512MB DDR now and it's great.. But seriously Windows 2000/XP doesn't 'need' more than 256MB or so nor could I discern a difference between 256MB (on my laptop) and 512. Linux runs great as a DB/web server on my PII400 with 384MB.. Even 4 years ago I was using 128MB with no probs. Why would the average home user need more than 512MB? Even with the eventual Windows bloat I highly doubt 512MB will be 'needed'.
Miami University in Oxford, OH also makes extensive use of 802.11b. It's in most of the admin buildings and quite a few academic buildings. It also lives in all the libraries and extends to the surrounding outside areas (as if anyone could read their laptop LCD outside anyway :))
Re: Me getting a new desktop in 2004:
I doubt it -- I have a PII400 I've used for the last 4 years... it served me very well until I got bitten by the Wolfenstein 3D bug over the summer and realized I 'needed' a new box so I built myself a 1.333GHz Athlon which I expect to keep until it blows up. Same with the PII400, it's a linux test box for FanHome which I keep all the dev code on .
I suspect, though, if things are that cheap in the year 2004 I'll go ahead and pick another computer up; I already have 3 -- another couple couldn't hurt (except the electric bill).
Wireless mouse and keyboard? Puh-lease. Those have been around for 5+ years and never, ever caught on (both infrared and RF). I doubt somehow we're going to want to sit on our couch and stare at our monitors. Why waste bluetooth bandwidth on your keyboard/mouse? I think the biggest drawback will be the need to replace batteries and/or plug the keyboard into the wall to recharge them. You'll always be working on a big paper or playing the perfect game of Counter Strike when your keyboard batteries die.
I dislike the idea of everyone using Bluetooth until their protocol isn't redicoulously easy to crack. Weren't there some stories posted a while ago about how easy it was to crack 128bit 802.11b -- with everyone and their mother using bluetooth it would be a cinch for someone to set up a wireless sniffer and read all your keyboard inputs (passwords, etc.).
Re: Laptop
I have a Dell Insprion 8000 that I purchased last May. It was faster than my desktop at the time so it truely was a replacement. It's a PIII850 with 256MB RAM. Runs great for what I use it for (when I'm on the road or otherwise away from my home computer it checks my mail and provides Age of Empires 2 gaming ) and I don't hope to replace it any time soon. It has a 15" LCD already and I couldn't imagine anything larger since as they said it would get HUGE. As soon as they develop those 'roll up' organic LCDs (which they've been talking about for 3 years or more now so I doubt all of a sudden they'll appear) they could have a laptop without any screen and then some sort of 'projector' type screen which you set up. I also have and use 802.11b at home and at work which is great although it is a separate PC card which sometimes I forget. If it was built-in like the Mac Ti Books (which are AWESOME btw) it would be a lot easier... Although one would think that would limit upgradeability since you'd have to rip the thing apart to replace the 802.11b with 802.11a. I don't know why they've limited the RAM to 256MB -- mine has that now with one slot free (for another 256MB DIMM I guess). If we're going to truely have desktop replacement laptops I'd see no reason why to get 512MB RAM (certainly whilst it is pennies on the dollar compared to even a year ago).
I'd like to comment on both the heat issues and the fragility issues. A couple months ago my friends and I went to the local MarketPro computer show and picked up a couple Asus A7M motherboards and Athlon 1.333 and 1.4GHz CPUs.
:oops:) and turned it on. Immediately some text appeared (BIOS junk) so we turned it off.
:( I took it back over to my friends, stuck it in there (with a heat sink this time) and tried it. No dice. All it took to fry my CPU was around 1 or 2 seconds w/o a heatsink. AMD was kind enough to ship me off another one a week later and it's been running great since. Moral of the story? Always use a heatsink. Second moral of the story: read the manual, since in big bold letters AMD says 'Under no circumstances should you ever - ever! run this CPU without a heatsink.' (paraphrased).
When we got them to our respective homes mine, for some reason, kept beeping (no RAM or invalid memory type). Grabbed my friend's known-good RAM and still had the error. Thought it was my CPU, so I took it over to my friends house. All I wanted to see was it POST since it couldn't do that on my mobo @ my place. I popped it in (sans heatsink
Got a new motherboard in the mail 3 days later and I pop everything in. No worky!
In regards to fragility somehow in the shuffling of CPUs my friend managed to chip the die on the front - rendering his CPU useless until AMD, once again, cheerfully sent him a new one.
If you're listening MySQL -- who really cares about SSL and unicode. Granted I've had them in my RDBMS that I use but still you're missing the big picture.
... is great and all, but the resulting table is a PAIN to read. What I want to know is simple:
... DESC can now use keys."
:D
The people who post funny things like 'MySQL Mad libs' are on to something - Slashdot is full of 'arm chair' DBAs (and programmers and network engineers and etc. etc. etc.) who know just enough to think they know exactly what is wrong and how to fix it. It's kind of like the people who have used a computer for a while and start trying to troubleshoot their friend's computers - 'You may have run out of Megahertz' or 'You probably need more memory to download files faster'. Yes, subqueries, locking issues, etc. are very important. However, these are 'surface' level flaws in MySQL. There are some very, very large problems in the underlying architecture which need to be addressed. Since they're not as glamorous (or as understood) as subqueries and pretty much ignored by 90% of the users they never see the light of day - but they impact almost 100% of the users in one way or another.
Fix things like this:
Filesystem buffered writes. Transactional support is great - it allows me to roll-back aborted transactions. However, due to the inability to control whether or not my tables are write-buffered means that MySQL may *think* it has performed a write even though it is still in the write-cache. I can then turn off the system and voila -- corruption! Part of the fault lies in the OS who tells MySQL it was written even though it is in the cache, but I have a simple solution. Devise a way to selectively turn off buffered writes for certain tables / databases. This way if I know I have a critical table which has a lot of writes I can turn buffering off and be ASSURED that writes will be performed when asked. I suspect a lot of 1040 and other table corruptions are caused by something like this. Yes, performance will take a hit but I think it is a very acceptable trade-off for data corruption. Obviously all system tables should NOT be buffered.
Inability to use more than one index on a table in a query -- most enterprise RDBMS' can use more than one index on a table for a query. This can easily save a table scan or the use of a single, less-efficient index. Given an example query - 'SELECT bob FROM sometable WHERE somecol = 45 and somecol2 = 44' - if I have two indexes on sometable (somecol and somecol2) it can join the two indexes together and
Clustered indexes. These basically physically sort the table based on particular columns. This allows you to ORDER BY username ASC without using anything special since the rows are already sorted on username (if you have a users table and cluster the username col). This also greatly speeds up BETWEEN clauses. And yes, to people who know a little bit of SQL but don't know as much about clustered indexes -- you can create an index with a bobcol ASC but clustering the actual data is faster and more efficient if you are grabbing data which is not on the index. For example, SELECT * FROM table ORDER BY username ASC will not be as efficient as the same query clustered on the username. If you had a sorted index on username it will probably read the index sequentially and then visit the table. That extra operation = more disk seeks = more time / cpu to execute (and it really adds up as the table size increases). However, if you are doing something like 'select username, password from user order by username' it would be better to create a sorted index on username ASC, password. That way it will read the index only and not visit the table at all.
on-line backups. In today's internet world your site has to be 24/7. This means you cannot have significant performance problems (or even offline-ing your dB!) when you make a dump -- Sybase, etc. have done this from as far back as I can remember.
backups to something other than CSV files. MS SQL, Sybase, Oracle, they all dump to a compressed binary file. Saves a TON of space and is MUCH FASTER to dump and load. I can dump a 6GB Sybase DB in under 5 minutes. Loading it all (from scratch) and then bringing the DB online is about the same amount of time.
Ability to specify the number of files to dump to. What happens if you have a dump which is larger than 2GB? Most linux distros cannot handle a single file of 2GB or more. Give users a way to, within the dump statement, split the dump over two files. Sybase has the 'STRIPE ON' clause (originally to dump to two tape drives at once but works fine on filesystem files as well) to split the dump equally over an unlimited number of files.
cleaner way to view query plans of statements. EXPLAIN
Query is using XYZ, ABC tables. Table XYZ is using index 123 which is sorted so I do not need to create a temp table to sort ASC.
Since you have all the columns in your select statement in the index I do not have to visit the actual table - I can pull it all from the index. Because of this, I will read the index from start to finish.
ABC is using index 23dsf which is not sorted so I must create a temp table to sort that. Also, since it is a join, I do not need to perform an index scan but a positioned search (table scan is to a WHERE clause with no index AS index scan is to an index which is not selective enough or needs to read all columns.)
Simple, easy and pretty much even a NOVICE can see that their query is a good performer or a bad performer.
Along with more in-depth EXPLAIN, also provide me with a way to see what the optimizer is doing with the query. In MS SQL and Sybase you have 'trace flags' which you can turn on before your query to see EXACTLY what Sybase is doing - why does it think this index is better than this other one, why is it table scanning when you think it should index sort, etc. Give me an easy way to say 'verbose on; explain xxx;'.
Ability to delve deeply into performance of the system. If there is one job a DBA must know it's how to tell what the heck is going on when something is slow. Currently MySQL gives you meaningless info like 'slow queries'. Great, I see 200,000 of them. What queries are they? What good is it in a large application which may contain 3000 lines of SQL to tell me the raw number of queries which are slow? I want to know the EXACT SQL of the query(s) which are slow and I want to find the one taking up the most CPU time and blocking all the rest. I want to know how MySQL is managing it's data cache so I can see if I need more ram (e.g. it is swapping lots of data to/from the cache) or if I am I/O bound. Don't tell me to look at 'free' or 'top' - half the time it is wrong because you (MySQL) tell it misleading figures. I want *you* to tell me exactly what you are doing since you would know best! If you've ever seen a sp_sysmon output from Sybase ASE you'd know what I'm talking about.
Hire people who are accomplished relational algebra freaks. Pay them a lot of money - it is well worth it!!! If I see another changelog entry like this I'm going to scream:
Optimized queries of type: SELECT DISTINCT * from table_name ORDER by key_part1 LIMIT #
So does that mean these queries were NOT AT ALL optimized before? It doesn't read 'FURTHER optimized'.
"ORDER BY
Does that mean it was table scanning each time? Jebus! Get these wiz-bangs to overhaul your query optimizer. Hands down this is one of the most important things in the database -- knowing how to use the database statistics and knowing when to use a merge-join vs. a hash-join etc. are CRITIAL to database performance. Trust me when I say that this is a MAJOR priority - especially over SSH or Unicode since it impacts EACH AND EVERY statement which MySQL parses.
Small things which can really raise the respect of MySQL in the eyes of people who matter - the CTOs and CIOs of the world who might be considering something like Postgres or MySQL but opt for MS SQL, Sybase, or Oracle because of the more advanced (but less flashy) features.
Of course, integrated row (or in the least page) locking and full support of subqueries and the like are also VERY HIGH priorities.
I think addressing these issues will vastly improve MySQL -- they're not flames really, just gripes
You see solid-state disk drives used mainly in relational database management systems as a 'scratch pad' for highly-volatile data.
:D
In order to explain I'll have to do a quick primer on RDBMS' and how they handle memory management.
As you're probably aware, there are a multitude of different operations you can perform on a RDBMS; UPDATE, DELETE, SELECT, etc.
For more efficient queries the RDBMS will cache physical data structures in memory. It may cache parts of the index or recently accessed data. If the cache is full it will kick out the oldest, least used parts to make some room for the new stuff.
To make a long story short, most servers have way more disk space than RAM. As such, it will use a designated 'temp' or scratch area for some of those sorts (and temporary tables) if there are more important things in RAM or it cannot all fit. In Sybase / MS SQL you create a special database for this called 'tempDB'. I'm sure DB2 / Oracle have similar data structures.
Here is where solid-state disks enter the picture. You can buy a small solid-state disk (9GB or less) for cheap. You then 'create' tempDB on the solid state device. That way you can completely eliminate the relatively slow disk drive for things like sorting, temp tables, etc. and devote all of your RAM to caching database information.
To me, this seems a lot better than using solid-state devices exclusively as a storage medium. Initially when you start up your RDBMS the cache is clean. After people run a couple queries the important (and most hit) indexes and data are cached any way so you do not have to worry about touching the disk unless you perform a write. However in most OLTP (online transaction processing; a la web app) it's mostly selects so you wouldn't receive the benefit of the solid-state device unless it wasn't in the cache.
Most SSDD have a battery-backup in them in case of power failure and are generally mated to a corresponding hard drive. When the SSDD is idle it will flush the writes to the HD to keep the HD up-to-date. On a power failure it will immediately dump changed data to the HD (also battery-powered).
For 'home' systems I can't imagine anyone using SSDD as their primary storage. It doesn't make sense - rarely does anyone perform anything that 'demanding' as to require solid-state drives. Plus, if you have a single memory error you would lose the entire thing (break one of your DIMMs and tell me what happens when you try and boot.)
I will agree that for 99.9% of MySQL users MySQL runs just fine. They don't need, nor care about, sub-selects, row-locking, triggers, etc.
:)
We used to run MySQL but found that it died *horribly* on heavy multiuser loads. (e.g. 500 concurrent users, all updating/insert/etc.)
I investigated the problem and found out that table locking really, really sucks. Last summer when we had this problem we didn't have the luxury to mess around with pre-alpha table structures and spend countless hours poking around with settings.
I carefully explored the other RDBMS's out there and eventually picked Sybase ASE 11.9.2 for Linux as the best choice. I can say it was hands-down the best choice we made. Now we're at 12.5 which supports SSL, XML, etc. and a host of other features MySQL hasn't even thought of.
Instead of 'dealing' with MySQL we're making money with something else.
So here it is:
If you are having problems with MySQL - DON'T PUT UP WITH IT. There are many other fish in the sea that will better fit your application. Simply because it is 'free' or 'popular' does not make it better for your application.
As someone else said, I always follow the 'pick the best tool for the job' test. If it is out of our price range, we either find a way to buy it or move on to the next item on our list.
I think far too often people perform the 'open source' or 'free' litmus test first -- leading to major headaches down the road.
If we were in this situation today I think we'd rather have picked Postgres, simply because it was a lot cheaper and offers many of the performance-enhancing features as the 'big three'!