en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2006/1/23/7acfbd969d591c0cf8addfb419c8f1fe.html . to @ identified by 'password' with grant option]]> Mon, 23 Jan 2006 09:58:15 -0700 http://www.keithwatanabe.net/blogs/2006/1/23/7acfbd969d591c0cf8addfb419c8f1fe.html http://www.keithwatanabe.net/blogs/2007/4/7/744847df83bb0bd620e5671804235231.html Sat, 07 Apr 2007 10:57:04 -0600 http://www.keithwatanabe.net/blogs/2007/4/7/744847df83bb0bd620e5671804235231.html http://www.keithwatanabe.net/blogs/2008/1/18/80f29da35a46d812db5e154b7417537e.html
However, I think Sun buying out Mysql is a horrible move. It's a good finacncial move for Sun, considering that Mysql probably is the most popular RDBMS out there. However, in the past 10 years, I haven't been all that impressed by Sun's track record. I'm certain that anyone who's read this blog would note that I have a particular thing against Sun's so-called vision (which is just marketing-speak for throwing things against the wall and seeing if they stick). And I've been extremely vocal against Jonathon Schwartz as Sun's latest CEO. Right now, he's been credited as someone who has resurrected Sun after McNealy's departure and that this move was all due to him. That said, I think they're going to bungle Mysql and it's going to hurt the Open Source community in the long term.

First, doesn't Sun already have Ingress? Why not support that? Does Sun's move in buying Mysql imply that they'll let Mysql rot? Will they continue to commit to allowing Mysql to be Open Source and free for most cases? Or will they simply start enforcing new licensing policies that have the potential for decimating a good portion of the web?

I'm sure that many other Open Source developers and companies who rely on Mysql probably have similar contemplations with regards to this move. Or perhaps a better word is fear.

The interesting part about the move was that Oracle's move came the same day. Coincidence perhaps? Sun's goal with J2EE was to always attempt to move customers away from RDBMS and onto hardware (their hardware!) solutions by creating the notion of a middleware platform. Oracle's move with BEA shows me that Oracle wants to completely dominate the enterprise market and high and mid level tiers. With Mysql in Sun's court, it's clearly a threat to Oracle's position on the business application market. Sun could theoretically move to completely supporting a Java Open Source version of the application stack with Mysql + Tomcat + Hibernate. If they continue the current licensing with that stack, Oracle will find themselves in an even more limited situation, considering they are one of the most expensive software companies around.

From there, we have to look at the rest of the market for this. Obviously, we have LAMP which just isn't owned by anyone. That's the purest form of Open Source available and probably the most dominant. You have Microsoft's .NET + SQL Server bundle. Then you have Redhat + JBoss/J2EE + LAMP and support for Postres. IBM with Websphere + DB2 and major support for Suse and Redhat. Then Sun with Sun hardware, Mysql + massive Java support. And now Oracle with Oracle + WebLogic.

Some part of me thinks that Sun's purchase of Mysql is for their grid computing project. Maybe have a massively distributed, rental system like N-1 that contains an application stack that they support. So companies will never have to worry about support again in terms of reliable system administrators, DBAs, and production support. Instead, companies will just need to focus on development utilizing a well priced fee for their services. In other words, a highly trustworthy hosting service focused on providing Java solutions. They probably could integrate many enterprise features like their user management tool Liberty.

If Sun takes this route to computing, then it would actually not be a bad idea. I've proposed that Yahoo (and Google to some extent) should provide similar services, in evaluating their level of expertise on web scalability matters. In Sun's case, the cost for them would be low since they don't have to worry about purchasing hardware nor licenses as everything is internal. In some ways, I would consider this move to be something like enterprise hosting. In this vision, large firms could rent out space from Sun's data center where the entire application stack is provided. Sun would provide all the support and the firms would migrate their applications onto such a platform with Sun's help. In house staff could be eliminated or moved into Sun as an agreement.

Anyway, if this is the vision for Sun, I think it would be a good business move overall. It depends on whether or not they're wiling to focus on it and take such a huge gamble that companies would want a service like this. Also, it would be scary in some ways.]]> Fri, 18 Jan 2008 20:40:02 -0700 http://www.keithwatanabe.net/blogs/2008/1/18/80f29da35a46d812db5e154b7417537e.html http://www.keithwatanabe.net/blogs/2008/1/18/bbfc930bbc61b9295616c74a8329d3c1.html
To start off, having overall 8 years now in the IT business, I have to say that I'm at the peak of my abilities and still going stronger day by day. Before I used to be a little intimidated in doing something simple like setting up an application server because the documentation was an unreadable mess. These days, everything comes fairly quickly with reading a good tutorial online, some hands on practice then the actual implementation.

Besides, improving my programming skills, I also try to improve my other skills like system administration. For instance, this week I got a chance to really work with NFS, IPTables/Firewalls, and more of the security aspects of Mysql. And just yesterday I got my first chance at exploring mod_proxy because of a technical difficulty we're having with one of our servers. This is actually some fun stuff, especially considering that I've worked very little with these technologies.

Things never go as envisioned but that's the times where you really learn your stuff, especially after conquering a particularly impossible seeming problem. For instance, the last two days I was experimenting with getting a remote connection setup with Mysql. We're going to be doing a three layer architecture with a proxy server + application/web server + database backend (actually, it's even more complicated than that since we'll also be doing some NFS stuff, but more on that another day). So I needed to get the application server to be able to connect to Mysql remotely. First, I had to try it on a development/testing server. I've always said that networks are probably one of the most unreliable and confusing pieces of a computer around and it's hard to figure out what to do when you get a failure. In this case, I had to really dig into the way Mysql was setup from an administrative point of view. But I soon ran into problems when I did everything one tutorial mentioned and still couldn't do a simple test remote login with the mysql client.

Fortunately, I'm not the only one with similar problems. I found that the last issue was that iptables had been blocking almost all traffic. So I had to configure iptables under /etc/sysconfig/iptables and add a few rules to get port 3306 open and allow UDP and TCP traffic to come in. This nice tutorial shows how to handle this situation. After restarting iptables, I was able to login. I had to bang my head against the wall for a few hours, but those are the times when you literally beat the knowledge into your skull. After such times you really never forget such lessons.

I hope to be able to do more stuff like this at work. I really want to get my hands dirty with LDAP next. Although we only have a few machines, I like the idea of having centralized, unified login information. After I fix up my home system, I'm going to give LDAP a try. Also, I'm really looking forward to working with mod_proxy. I've worked with similar tools before in using the ajp/Coyote Connector for Apache to Tomcat. But this time, I'm going to be configuring a reverse proxy.

There's always more barriers to breakdown with technology and this is the stuff that I really like.
]]> Fri, 18 Jan 2008 21:04:04 -0700 http://www.keithwatanabe.net/blogs/2008/1/18/bbfc930bbc61b9295616c74a8329d3c1.html http://www.keithwatanabe.net/blogs/2008/3/29/ab18e01982fa54768fb407d42446d015.html
But through this experience, I learned quite a bit from both the Mysql side and PHP. First, PHP really needs a threading model. I cannot emphasize this enough. Most people probably are happy just to do some multi-tasking version of threads, but that's not "true" threads and you really are hacking a model together. I've seen fake threading packages here and there, but nothing that warrants trying it out. I'm starting to see why Java and other languages with threads natively built into them are considered superior in this regard.

Second, global variables are not necessarily an evil. What!?!?!??!?!?! Blasphemer! Actually, using global variables on a few scenarios saved my butt because passing them by value in a function's method calls inflated my memory usage to double the capacity. In those cases, I was loading up massive arrays of information where I needed to re-index some information before loading it into the database. Here's a situation where global variables are actually a GREAT thing because you want to save memory. The key here is that I know which variables are considered global so I can control from a program flow perspective whether or not these variables would have any side effects in the end.

On the other hand, I found objects to be evil. I was using the Zend Framework's models to load part of my data into memory. When you load a rowset using the Zend Framework, you actually are committing yourself to building up VERY fat objects into memory. On small data sets, this doesn't really matter. Most websites on the front end probably don't have to bother with such details. However, when you're loading several hundred rows, it REALLY matters. Fortunately, the rowset object allows you to convert the data into pure arrays. By doing this, I was able to cut memory usage in half. This was a critical step because I had to bump up the memory allocation to near 2gb and the script was going into swap.

From the Mysql side, I'm learned a thing or two about indexing. Most people probably just know about indexes from foreign keys, unique columns or surrogate keys (i.e. sequences). But indexes can be used in more ways to boost up your queries. Here, I was creating an equivalent log file table using with month and day columns. Quite often a person might want to check out the number of unique hits per month, or even for a day. On a data set of say 10 million rows, this can take roughly 20 seconds. Putting an index on day or month can cut the time in half.

One thing I was doing in designing the database was structuring it similar to how dimensional modeling works. Mostly, just one off join tables (I believe these are called the dimensions) from the fact table which was the log table itself. I had several large fact tables requiring me to do up to six table joins at a table. Not deep table joins, but just connecting them to lookup type tables. I tried creating a view to see if I could optimize the select speed. Turns out that the view took longer than a regular query. The reason here is that I would use some filter prior to joining up the tables. The view had no such filter and would grab the entire data set in a joint format before allowing you to run your filters.

Overall, the experience has been very cool because the typical highest number of rows I'd work with might be a few hundred thousand. Here, I'm working with several million, so learning to optimize my code and queries allow me to get a much better feeling for how optimal programming works.]]> Sat, 29 Mar 2008 01:30:15 -0600 http://www.keithwatanabe.net/blogs/2008/3/29/ab18e01982fa54768fb407d42446d015.html