|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
| Daily Coping Tip Give kind comments to as many people as possible today I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
| The SPU Ever since I heard about the SQLOS and all the work that went into producing an operating system for SQL Server inside of the host OS, I've thought that perhaps there might be value in specializing the environment for a database platform. Given the importance of databases, especially relational ones, and the need to get every bit of performance out of them, I wondered if we wouldn't see a version of SQL Server that is installed directly on the hardware, without a host OS. In some sense, I guess that's what a PaaS database is in Azure, but I thought we might see that for the download-and-install version. Instead, maybe there's a better way to improve performance without requiring SQL Server (or Oracle, PostgreSQL, etc.) to implement some of the OS features they'd need. Perhaps we could change the hardware around and use a SQL Processing Unit (SPU). The SPU is another specialized chip. Like a GPU for graphics, or even some of the other chips that are made specifically for mobiles, storage, or networking, this one would be focused on database needs. Apparently, there are a few companies that are researching how they might build chips that focus specifically on the types of computations that data analysis requires. I don't know how practical this is, or whether we'd see any major database vendor attempt to port to a new chip. Perhaps they'd add instructions that could use one of these chips, similar to how a GPU can offload work. That might seriously improve performance, something that a lot of our customers would appreciate. Especially if this is without spending a lot of developer time rewriting old code. That's not to say that developers shouldn't learn to write better code. They ought to, mostly so that their initial attempt at producing reports or batches of data handles a wide variety of data values and workloads without stressing the hardware. More efficient code is always the best way to attack any problem. Even if you had a very efficient SPU, chances are that your workload will still grow to overwhelm the hardware at some point, especially if the number of users grow. Monitoring helps find problem queries, but it's up to developers to change their habits, grow their knowledge, and produce better code sooner. Then we can use hardware to deal with the large numbers of users that need to access the system. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
