Database Technology Trends

I have the distinct honor to announce that Sybase invited me as a speaker at this year’s TechWave in Las Vegas. This year TechWave will be cohosted with SAP’s TechED. This joined event will attract 5000+ attendees and will draw a lot more attention to the Sybase event.

The topic I will be presenting is the highly charged theme of “Oracle to Sybase Migration”. This is a topic loaded with emotions and opinions. I think it is refreshing that Sybase is acknowledging this topic, as all the other vendors are doing for years. Let’s face it, prior to SAP most, if not all, Sybase migration projects where from Sybase to anywhere else. To me this is a huge showing of confidence from Sybase.

Here’s the official title and description of the session I will present at TechWave:

A Practitioner’s Guide to Successfully Migrate from Oracle to Sybase ASE (Parts 1 & 2)

CIO’s unanimously agree that reducing infrastructure costs is key to ensuring adequate budget investment to achieve top-line business growth.  While there are obviously many approaches to achieving this, one area gaining attention is migrating from the higher cost Oracle database platform to Sybase ASE,  Long known as the highly performant and resilient database powering much of Wall Street, its’ flexibility and low total cost of ownership, both in hardware and administrative costs, are making CIO’s take notice.  This 2-part session will explore this topic from two perspectives.  We will first dive into this topic from the perspective of the business’ "Program Manager" by identifying the major high-level tasks and milestones of a typical project plan as well as quantifying the level of effort and risk for each.  We will then explore this from an implementation perspective looking at some of the most critical and resource-intensive technical aspects of such projects to help you minimize the effort and risk of these types of career-enhancing projects.  If your company is considering its options for a competitive, yet cost-effective, database infrastructure, this is a session you can’t afford to miss.

Please join me at the most exciting TechWave in years. For more information go to:
http://www.sybase.com/techwave

See you there,
Peter

First of all I have to apologize to my loyal readers for the long absence from my blog. In simple terms, “I got busy”. But in these economic times, I guess this is a good thing. I don’t want to give a promise I can’t keep, but I will do my best to keep this blog up-to-date.

The past few years were dominated by all major database vendors introducing and improving their database cluster products. There is the bread of shared nothing clusters like Microsoft SQL Server 2008 and there are the share everything clusters like Oracle and Sybase. You can read all about this in my previous post “Grid Databases – The Future of Database Technology?“.

It is amazing how far these technologies have come and how much we got used to “always available” databases. You know what’s coming next. Now, that we have uninterrupted access to data, it would be great if we get the data faster. Well, the database vendors have an answer for that as well.

It was about 7 years ago when I first was introduced into the concept of in-memory databases. At the time it was less known database vendor called Times-Ten that offered an in-memory database with blazing performance metrics, hence times ten. It was the perfect answer to solid state disk drives that could drain an IT budget in a hurry.

Apparently this technology was so intriguing that Oracle decided to buy Times Ten and make it Oracle’s in-memory database. The only downside to this is, it is not an Oracle database in memory, it is Times Ten’s engine running in memory. This creates admin nightmares to have special skills to manage the Times Ten engine in addition to the Oracle server, as well as different software development techniques for both systems. Performance gains out weight manageability concerns, I guess?

Just recently Sybase announced its Sybase ASE server, in version 15.5, will have an in-memory engine equivalent that will provide the same functionality and manageability as the standard Sybase ASE server. This is a remarkable step, because it provides performance gains transparent to client applications and the database engine will not challenge DBAs to learn new skills. To me this is a win-win situation.

Microsoft is still in the planning and rumor phase of providing an in-memory database for its next version of SQL Server. The code name for the next SQL Server upgrade is Kilimanjaro. This is the name to use when searching for upgrade information. It is not clear when the new SQL Server release will be available and it is not clear if it will be named SQL Server 2010. It depends if it gets out this year or not.

IBM has its own in-memory database for DB2 and I believe it is a Java based and Java supporting engine. I have to admit that I’m not as fluent with DB2 as I wish to and please add your comments to this post if you’re a DB2 expert.

Having listed all the in-memory contenders, the question pops up “What about Sybase IQ?” or any other data warehouse database for that matter, Terradata and Netezza for example.

The answer lies in the architecture of in-memory databases. They are designed to improve transaction processing volume, the classic OLTP applications. Data warehouses would not have any benefits from in-memory databases. In-memory databases provide extreme high-speed transaction processing without the need to confirm disk write success. Traditional databases have one thing they have to do to ensure data integrity. They all need to wait for the disk i/o to confirm a write to disk. Database vendors came up with very complex and sophisticated caching techniques to overcome this performance challenge. But they cannot ignore this fundamental requirement.

In-memory database bypass this disk writing requirement and that’s what improves the speed. Designed for high volume transaction systems, like e-commerce shopping carts, in-memory databases are unbeatable when it comes to writing transaction data. And this is fundamentally different to data caching of traditional database engines. Data caching improves read performance, but does nothing to improve write performance.
There is a downside to these databases as well; they offer alternatives to performance problems in poorly written applications. Like powerful hardware, in-memory database have the potential to mask poor application development. We might see an explosion of in-memory database implementations due to this matter.

Bottom-line: this is cutting edge technology that will give database architects another tool in the toolbox to design the most effective database environment. Do yourself a favor and try to get your hands at a test environment to experience this technology first hand. Yes, 2010 could be the year of in-memory databases.

Thanks for listening,
Peter