Rob Steward:

Click to play

I’ve been talking to a lot folks who have undergone a very large virtualization project. So, for example, they may be taking their entire infrastructure, and trying to virtualize as much of it as they can. And obviously, the reason for doing virtualization is to lower costs. When you say virtualization most people think of VMWare, a Windows hypervisor, or some kind of virtualization environment where they take multiple machines and put them on a single piece of hardware. Interestingly enough, as people have started to do this, they’ve started to virtualize their entire environment. I’m starting to see much more maturity in terms of how they approach what they’re going to virtualize, and how they’re going to make the decisions of what to move to those environments.

I’m seeing one big trend in that people are having issues getting their databases themselves onto virtualized environments and maintaining anywhere close to the throughput that they’re used in a non-virtualized environment. So, for example, one of the guys that works for me went to the VMWorld Conference that VMWare recently held and noticed in a lot of the sessions people brought up the question of: can I run Oracle database efficiently on a VMWare environment? And obviously, from the approach that WMWare themselves took at that conference, this is an issue that’s near and dear to their heart. And it’s also — the reason I bring that up is that, it’s also a concern that I’ve heard multiple times in talking to customers. Specifically with Oracle, but I’m sure the same concerns exist with every database. And that is, when we put the database on that virtual machine, we don’t get the same amount of throughput that we do in the non-virtualized environment.

For example, I visited one customer who was, again, virtualizing their whole environment, and they came to me and said, ‘Rob, can you help with this problem that we’re having in that when we put our databases on virtual machines, we can’t get the throughput that we need to support our business.’ This particular customer had set up a very nice testing infrastructure where they would take a machine that was not virtualized, they would move it over with its applications, with its operating system, with everything, put it on a VMWare machine, run it, run their tests and measure whether the throughput that they got through that application, or through that entire application’s stack was at least 90% as good as it was in the non-virtualized environment. And for any app, or any application’s stack that they could get to that 90% throughput, they would then virtualize it, put it in production in a virtual environment. Which I thought was a very interesting way to go about it, because they had done a lot of setup for a lab to measure these things, which of course the VMWare tools give you really good ability to measure these things, but they were testing every single application and every single application stack. Now, they never could get that 90% number out of any Oracle databases that they had virtualized. So, they approached me to ask, ‘Rob, you know, can the database middleware help us get that database server running at 90%?’ And the answer that I had for them was, to some degree, we can help that processing that goes on in the database server, because the database middleware influences the amount of processing on the database server, because of the way it sends, say the way it may execute a statement, the way it may minimize the amount of data that has to be returned, or minimize the number of networks round trips. And also there are options within database middleware, your JDBC drivers are going to be drivers that can affect whether certain processing happens on a server on the database itself or whether it happens on decline. So, for example, and probably one of the biggest things that the database middleware can influence on how much processing goes on on the database is, whether character set conversions happen within the drivers or within that database middleware, or whether they happen on the database server. Typically, they’re options which you can set to affect where that processing occurs, so where do you want it? Do you want to offload it to a database; do you want it in the middleware? So I sat with this customer, and looked at some things and we were able to make a difference, but we still were not able to get that database running at 90% throughput.

This is one of the areas that I’m doing some research within my team on how we can help virtualized environments. How Progress DataDirect can help to minimize the amount of processing that happens on the database server. Why does data access middleware matter at all? Why does it make a difference in a virtualization environment? In the book and on this blog we’ve talked a lot about why it really matters and what kind of differences it can make in terms of performance. If you think through what the value of virtualization really is, then you see we’ve got machines that are sitting around that are only being utilized part of the time, so what we want to do is instead of the 80% of the time that a machine is sitting there doing nothing, let’s put it to work. So the idea is I don’t have to have five machines, I can have one. So that saves you not only in terms of the machine cost but in terms of electricity, in terms of air conditioning, in terms of space in your data center. These things can add up to millions of dollars for companies of any size. That’s why everyone is looking to virtualization. If you think through any sort of normal business application, it spends typically between 60 and 80 percent of its time accessing the data, so if we can cut that amount of time and those amount of resources in half it makes a huge difference in the overall resource usage and throughput of your application.

Let’s say your application is 60% of its time doing data access and 60% of its resources. If we can cut that in half then we’ve just reduced the resource usage of that application by 30%. That 30%, as we start to add additional virtual machines and additional applications to those same virtual machines, that difference means we can start to put a lot more virtual machines on the same piece of hardware. The data access middleware is making that kind of difference on the resource usage within the application.

Like what you see? Share and Enjoy:

]]> http://dataaccesshandbook.com/community/data-access-and-virtualization/feed/ http://dataaccesshandbook.com/community/implications-of-storing-data-on-the-cloud/ http://dataaccesshandbook.com/community/implications-of-storing-data-on-the-cloud/#comments Wed, 09 Dec 2009 18:52:41 +0000 rsteward http://dataaccesshandbook.com/community/implications-of-storing-data-on-the-cloud/ n this podcast Rob Steward explains how clouds are currently used for storing data and how this is going to impact the IT landscape. This podcast lasts for 3:44 and can be listened to here: http://blogs.datadirect.com/media/ImplicationsOfStoringDataOnCloud.mp3

Rob Steward:

There’s a lot of data being moved out into the cloud, and there’s a lot of different paradigms that are coming up in order to access that data, so let me give you an example. Microsoft has recently moved SQL Server in the Cloud, Amazon’s got SimpleDB, there are a lot of other ones out there that I could talk about. And those are really databases within the clouds. If you think about it, SAS applications — so something like a NetSuite or a Salesforce CRM or an application that you’ve written in Force.com for that platform of Salesforce’s are cloud-based apps. The data that lives within Salesforce.com, it’s really your corporate data. It’s how do you access that data? How do you get to the data within Simple DB or within Salesforce.com or with any of the platforms or any of the SAS vendors out there? You know, you may use Workday or you may use any of the popular — NetSuite or any of the more popular SaaS applications out there.

It creates an interesting data integration problem, and the reason that I say this is if all of your customer data sits within Salesforce but all of your ERP data sits within SAP inside your enterprise, how do you combine that data? How do you integrate that data? And so there are very interesting things happening in the cloud to allow you to do integration. There’s companies like Pervasive and Cast Iron that are all producing solutions that can do integrations point-to-point within the clouds.

(Image credit: Cloud Computing by Kevin Krejci)

Well, one of the things that we’re looking at, at Progress DataDirect, is how do we integrate that data that’s out there in your Salesforce app or any of those SAS applications, or within those databases in the cloud. How do you integrate them with your data that’s inside your firewall? And how do you integrate them into the apps that you’re familiar with that run on your desktop? So if you like Crystal Reports to do reporting, how do you hook that up and get your data out of NetSuite and be reporting using Crystal Reports on that? So I think that there are a lot of interesting questions, and I’ll just say that we at Progress DataDirect are going to solve some of these problems of how you integrate through standards based APIs, but also the more general question about data in the cloud — I don’t see a big movement yet outside of SAS applications. A lot of people use a Salesforce or NetSuite. What I don’t see yet is, Amazon SimpleDB or SQL Server in the Cloud or any of those databases that just live in the cloud — I don’t see yet real business applications running on them. I see people playing with them. So I’m inclined to say the jury’s still out on whether those are viable as just back-end data stores. We’ll see as we move forward.

Tagged as: Cloud, NetSuite, SalesForce

Like what you see? Share and Enjoy:

]]> http://dataaccesshandbook.com/community/implications-of-storing-data-on-the-cloud/feed/ http://dataaccesshandbook.com/community/reflections-on-itarc/ http://dataaccesshandbook.com/community/reflections-on-itarc/#comments Thu, 19 Nov 2009 18:53:46 +0000 rsteward http://dataaccesshandbook.com/community/reflections-on-itarc/ Rob Steward recently attended the IT Architect Regional Conference: Thought Leader Edition, and spoke on “Achieving Optimal Database Application Performance and Scalability.” In this podcast Rob shares about his ITARC experience. The podcast lasts for 1:57 seconds and can be listened to here: http://blogs.datadirect.com/media/ITARCConference.mp3

Rob Steward:

So I thought it was a great conference, fairly small, less than 100 people there, but there were some really big names in the software architecture world: Grady Booch was there, Angela Yochem, Bill Inmon, and John Zachman. There were a lot of big headliner names, and I thought the attendees brought a very high level of knowledge. I was impressed with everybody that I talked to. With less than 100 people and six or eight sessions going on, none of the sessions were very large.

My session on achieving optimum performance was actually a packed room. There were no empty chairs, although it was a small room. I really like environments like that where you’ve got a small, much more cozy audience. At this conference – due to the high level of knowledge of the attendees and the cozy setting — I got to ask questions during my session, and to be honest, as a speaker I would much rather stand up there and be asked questions than just point at a screen and lecture. I thought, again, there were some really good questions that I got. I enjoyed talking with the attendees. I enjoyed listening to the panel discussions. I thought it was a very well run conference and very well worth the time. Really enjoyed it.

Like what you see? Share and Enjoy:

]]> http://dataaccesshandbook.com/community/reflections-on-itarc/feed/ http://dataaccesshandbook.com/community/leading-architects-to-speak-at-it-architect-regional-conference/ http://dataaccesshandbook.com/community/leading-architects-to-speak-at-it-architect-regional-conference/#comments Tue, 06 Oct 2009 09:00:40 +0000 rsteward http://dataaccesshandbook.com/community/leading-architects-to-speak-at-it-architect-regional-conference/ I’m excited to be speaking at the upcoming 2009 IASA IT Architect Regional Conference, Thought Leader Edition. The conference will bring together leading architects and will offer more than 30 seminars. The October 12 – 14 conference is New York’s largest to address the needs of IT architects, and attendees are able to select from five specialty tracks (Enterprise, Infrastructure, Software, Information and Fundamentals). For more information, see Zain Naboulsi’s New York - Architecture Titans Meeting post.

I encourage you to attend my “Achieving Optimal Database Application Performance and Scalability” presentation. I will be sharing tips and techniques to successfully predict, diagnose and solve issues in database applications. Exploring some themes and content featured in the “The Data Access Handbook,” I plan to address application design, development and deployment strategies with an emphasis on the role of database middleware on performance. What makes my presentation particularly unique is that it tackles performance issues outside the database – that is, problems in the software that connects applications to databases.

Key topics I will address include:

• Understanding the different components of database middleware that cause performance issues
• How to design for optimal performance
• How to write good application code
• How to troubleshoot your own performance issues and to set realistic performance expectations

I hope to see in October at ITARC!

You may listen to the podcast here: http://blogs.datadirect.com/media/RobSteward_WireProtocolDatabaseDrivers.mp3

Rob Steward:

So when we talk specifically about wire protocol architecture drivers, this is something where really what you’re talking about is a type 4 JDBC or a completely managed, 100% managed ADO.NET data provider, or in the case of ODBC, you have an ODBC driver which talks directly, opens up a TCP/IP socket or some network socket to the database and directly communicates using the network protocol and using the packets that the databases themselves understand. So that’s kind of the difference between a wire protocol and a non-wire protocol, so you may have pretty much any type 4 JDBC driver is going to be talking a wire protocol to the database, because it has to stay within the DM and it can’t call any native OS. A type 2 JDBC driver or a partially managed ADO.NET or what most people typically think of as ODBC, you’ve got that driver component on top of some other native component, and it’s that native component that talks across the wire to the database, and the driver itself does not talk directly. So there’s a lot of differences, a lot of different architectures out there with which to build the driver.

Now, of course, the obvious question is which one is best, and certainly, in my opinion, the best ones are the wire protocol drivers and the type 4 JDBC because in terms of performance, scalability, functionality, those are always going to be better in terms of performance and scalability in particular, and reliability, as well. When you get into pure Java solutions within the Java environment or 100% managed within .NET, theoretically you can’t have things like buffer overruns or memory leaks, so reliability is increased with those type 4 wire protocol type solutions, as well. So — and also in terms of performance and scalability, the fact that it is a wire protocol, let’s say wire protocol ODBC, where that driver talks directly to the database and not through some intermediate component, it’s going to perform better because it’s designed to do exactly what your ODBC application needs. It doesn’t have all this other stuff. It doesn’t have double sets of buffering, one in that client layer, one in the driver layer, and the reliability, again, is going to be increased. So, you know, in my opinion certainly type 4 JDBC, 100% managed in the .NET world, and wire protocol ODBC are somewhat equivalent when you think about architecture, and those, to me, would always be the best performing and best scaling solutions.

You may listen to the Data Access Considerations Regarding SOA podcast here: http://blogs.datadirect.com/media/RobSteward_SOADataAccessStrategies.mp3

Rob Steward:

So Mike, I think what’s particular to data access as in service oriented architecture reference to data access, there’s some very specific things that we’ve seen in the real world, so SOA’s been around really as an idea for about eight or ten years. What we’ve really seen is that in the last three to four years is real world implementation starting to roll out, and so what we share in the book is: What is it that we’ve seen people do that they could do better if they were to change a few things with their data access code within service oriented architectures?

So one of the things that I’ll talk about right now is one of the tenets of service oriented architecture is reuse of components, so really when companies do service oriented architectures they’re doing it to make themselves more agile in terms of the business, so that’s the main thing that you’re after with SOA. So another tenet of SOA that goes along with it is you want to capture best practices. So a big thing with SOA is you build your service, or build your services, you are capturing best practices. So for example, if I build a service that takes some item out of my inventory, then I want to build that service in a way that every application’s going to use it — that’s why we build the thing, so they can be reused — but when I do it, I do it in the best possible way. That way every application that uses that service is going to inherit that best coding that I did within that inventory service. So what that means, if you think about that from a data access point of view, is that the data access code that was in that service to remove that item from the inventory, if it’s written well then all the applications that use it will have good data access practices just by the fact that they’re using that service.

Now, what generally happens in companies that I’ve seen implement service oriented architecture is that they have some architects who understand services, understand service oriented architecture, understand how to implement it, they talk about governance, they talk about all the things that go around managing services, but what these guys are not is experts in data access. So what I’ve seen in many places is people will write a service — let’s take that example again, the inventory service — and they write within it some data access code, and that data access code may not be the best. It may not be the best way to do it: it may be slow or maybe it’s OK. What I see more often is that for the first application that needs that service, they write the service, it works fine for them, that application has 50 users, right, and it works fine for them, but again, the tenets of service oriented architecture is another application is going to come along and it’s going to use that service, so this service that one team wrote to begin with, that services 50 users within an application, all of a sudden here comes the second application. Now we’ve got 100 users, and now a third application, and we’ve got 200 users, and before you know it you’ve got 500 or 1,000 users on this service that was originally working fine when only 50 people were using it, but once it got to 500, it was working way too slow. Now, this is something that I’ve seen happen over and over and over. Services get rolled out, they work fine, but as you start to scale up your service oriented architecture and you get more people using them, the scalability just isn’t there.

So here’s my tip for that: I mentioned earlier that you typically have the services architects when you do SOA. What you also need is data access, the data architect involved as well, so you’ve got people who know what is the best way to access this data. Make sure they’re involved in your planning for your services. Even when you have an application that’s only got a few users and you’re writing a service for it, remember service oriented architecture is designed such so that more applications can come along after you and use that service, so make sure that you design those services and use all your knowledge of data access and use the things that we talk about in the book to make each service a much better performing service and much more scalable. Again, I’ve seen this over and over in the last few years where it rolled out, it was fine, but as soon as you started adding users to it you found out, “Oh, you know what, we really have to go back and rewrite that data access code because there’s a much better way to do it and make it more scalable.”

You may listen to the podcast here: http://blogs.datadirect.com/media/RobSteward_MemoryDataAccessBottlenecks.mp3

Rob Steward:

So there’s a specific class of issues that will happen that will cause you to use a lot more memory than you may need or you may want. In the book, we talk about a number of different tips that are sort of related, but we don’t — it’s a great question because we don’t have it organized necessarily all in one spot saying “Here’s a thing that can affect memory.” So the biggest thing I would say that can affect memory is the data that you retrieve, if it contains long data. So if the data that you’re retrieving or trying to insert or update contains pictures or papers, very long books, very long string fields or character fields, typically they’re going to be in a clob or a blob column or a long or a text or an image or any of those data types across the different databases that can store, say, a 2GB piece of data in one column in one row. So for example, this week I had a customer who was getting an out of memory error, and when we started to look at the code, what we found was they were trying to insert some pictures, and actually their pictures were getting up close to 2GB, but what would happen was within — and this particular case was ADO.NET — what was happening was they were loading that entire picture into memory, into an insert in the database, but there are a lot of ways within ADO.NET and within .NET to stream that picture in not all at once, and again, the exact error that they were getting was that they were getting an out of memory exception, so this is exactly, you know, the case that we’re talking about. Once they change their code to use the streaming interfaces that exist in .NET, everything looks fine. So again, there was that long data, you know — the same types of interfaces existed in JDBC. And in ODBC, you can also stream data in in chunks when you’re dealing with very large data.

Now, that’s when you’re doing like an insert or an update. Same thing applies when you’re fetching the data. Most drivers have options that control how much of that data’s buffered. So again, we talk extensively in the book about getting database middleware, drivers, providers, or whatever that is tunable, one of the tuning parameters that you typically have is when I fetch that picture data, or that long data, how much of it should I get at a time, how much of it should I buffer? So look there as well. That’s one of the big things that we see as well as those tuning parameters affect how the drivers do that. Also, some of them — or all the APIs have some way to retrieve that data in chunks, so don’t just allocate a 1GB buffer. If you think about it, if you have a picture column and you retrieve 100 rows, and even if, you know, you do half a GB, you know, that’s 50GB — you’re going to get an out of memory error. So you have to be careful about the way you stream long data. That’s the most common way that I see that people hit memory limitations.

The other way that we see is when you pull very large result sets — so for example, you might have some data warehouse query that returns a million rows. Now, when those million rows come back, you know, they may be a couple thousand bytes a piece, or they may — you may get into where you’re using a lot of memory to store those results coming back. Again, there are tuning parameters on most good database middleware, most drivers, that allow you to affect how much it will hash in memory, and some of them contain options that say, “Well, when I hit this certain memory limit let’s start caching the disk,” but probably the biggest thing you’re going to see in terms of memory is watch out for that long data.

Like what you see? Share and Enjoy:

]]> http://dataaccesshandbook.com/community/overcoming-memory-bottlenecks/feed/