Voice of the DBA

Tag: rdbms

  • The General Database Platform

    It’s been a decade-plus of the Not-Only-SQL (NoSQL) movement where a large variety of specialized database platforms have been developed and sold. It seems that there are so many different platforms for data stores that you can find one for whatever specialized type of data you are working with. However, is that what people are doing to store data in their applications?

    I saw this piece on the return to the general-purpose database, postulating that a lot of the NoSQL database platforms have added additional capabilities that make them less specialized and more generalized. I’ve seen some of this, just as many relational platforms have added features that compete with one of the NoSQL classes of databases. The NoSQL datastores might be adding SQL-like features because some of these platforms are too specialized, and the vendors have decided they need to cover a slightly wider set of use cases.

    It also could be that some of the features of the relational database, which are certainly a general-purpose data store, are demanded by customers. I personally think that many problems are solved well by the RDBMSes out there,  and if you need something specific, then add on a NoSQL document, graph, time-series, or other type of database for some part of your application.

    A lot of organizations have moved to using multiple data stores in applications. I see it more and more from customers I deal with, often because there is a specialized need, like Redis for caching, that just outperforms the main database for a certain function. As long as it’s easy to integrate, why not use a second database platform in your application?

    I don’t know that you want to keep adding specialized systems, however. As the article notes: “the overhead today of having to learn and interact with multiple databases has become more burden than boon.” That can certainly be the case when there are a lot of platforms and your staff changes on a regular basis. We’ve seen this become a burden when there are too many versions of a database platform. Supporting these is hard and learning about all the features is a challenge for developers. Building expertise in many areas is sometimes very difficult for an organization.

    My guess is that the future will continue to be applications that use one data store, but the trend is away from this. Especially as more organizations start to use the cloud, I suspect a lot of companies will use a specialized data store for some part of their data. They’ll also be more likely to use a second platform for a data warehouse or analysis platform. With cloud vendors building easier data transfer capabilities, like Synapse Link, I do expect more customers to take advantage of these and use a second, specialized platform where it makes sense.

    I like the idea of specialized platforms and systems. I do think that there are some problems that are not well suited to being solved by relational structures. However, I also think that for a lot of critical transactional systems, it’s hard to get away from a relational store.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Moving Away From MySQL

    I like SQL Server as a database. I think it’s very complete, solves most of my problems, and is easy to use in work. It costs money, but less than some others. It’s also more complete to me than some of the open source databases out there. That being said, I think most of the top five or six relational platforms would work for me and I wouldn’t hesitate to use them.

    I ran across a post from Steinar Gunderson, who worked at Oracle on the MySQL team. It’s on his last day there, and it’s a bit of a why did he leave. I like that he notes he found a better opportunity, but he digs in deeper. Why did he look for a new opportunity?

    The answer seems to be that MySQL was a shockingly primitive piece of software, according to him. He felt there was lots of room for improvement and change, but people seem to like and accept what MySQL is and does. He is proud of what he has done, but felt that this was a product that was vastly inferior to other database platforms.

    That’s interesting, because I think MySQL works fine and is in use in many situations. While there might be plenty of things that can be improved, I’m a practical guy. If the technology meets my needs, and those I can foresee, I see no reason to change. That being said, I wouldn’t reach for MySQL to start a project. If it wasn’t SQL Server, I’d lean towards PostgreSQL.

    There are a couple of examples in the post, and it’s certainly a good post to write on your last day. If you published it when it wasn’t your last day, it might quickly move in that direction.

    If you use MySQL, I’m curious what you think. If you don’t, would you if SQL Server weren’t available? Would you learn MySQL for a new job? Or are you a die-hard, this is my platform kind of person?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The NoSQL Rise and Fall

    I’m not sure this blog that seems to talk about the problems of NoSQL databases in general makes a lot of sense. If you read the comments, you certainly see lots of complaints, but I also think the post isn’t well written. It lists the problems of RDBMSes as possibly deleting all tables while changing a key or being unable to add a column easily. While I don’t know about all RDBMSes, I don’t know any that could lose all data with anything less than DROP DATABASE.

    At the same time, the NoSQL complaints and problems seem to be generally presented, which isn’t good. The various NoSQL flavors of databases vary widely and the way you look at a columnar or graph database is much different than a document database. Really, the piece ought to be separated to look at a certain class of NoSQL database compared with RDBMSes.

    That being said, I do see less hype around NoSQL in general. The class of problems handled by various types of databases vary, and I am sure that lots of people using NoSQL databases are quite pleased with them. At the same time, I’m not sure a lot of the RDBMSes did get replaced or continue to get replaced. RDBMSes have a lot of value and we have a lot of experience, both as developers and administrators.

    There might be a shortage of NoSQL (pick a type) administrators for operating the databases. Even in some of the famous companies that use them, I find developers often explaining a RCA or the troubleshooting of a particular process. While that might be a choice that an organization makes, a lot of developers that I know don’t want to be supporting systems very often, especially at night and on weekends. A couple of bad incidents usually has developers wondering why there isn’t an expert on the Operations staff.

    I do think that many of benefits of different types of NoSQL databases are a bit over-hyped. Not that a graph database can’t handle your e-commerce system, but it likely takes a lot of code, and likely a lot of mistakes in getting it to work well. I also feel that some of the downsides of RDBMSes are minimized. They are a pain for application developers to work with, and the SQL language isn’t very sensible.

    That being said, we have a lot of experience with these databases, and that should not be discounted. Productivity is a big advantage in trying to build new software in a flexible manner. I am all for experimenting with different platforms to understand where they work well, but also learn to use your existing RDBMS platform well. Write better code and you might be surprised just how scalable your system proves itself to be.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Distributed SQL Databases

    One of the challenges that SQL Server, and many RDBMSes, face is scaling out. While SQL Server can grow to handle a large workload on one piece of hardware, eventually there reaches a point when a single machine cannot handle the workload.

    Microsoft is trying to handle this with some new tricks. We have the Hyperscale editions of Azure SQL Database and Big Data Clusters, on premise. I don’t know that either of these will end up providing us with scale out for our OLTP databases, but they are options.

    There are other options. Google has Spanner, which is a distributed SQL database and CockroachDB has attracted some attention. I caught an article that talks about some of the reasons you might look at CockroachDB, which is a cloud system, but one that gives you scale, and perhaps more importantly, lack of lock-in with a cloud vendor.

    I don’t know all the ins and outs of a distributed, scalable SQL database, but I do know that scaling one table, with lots of concurrent access, can be tricky. There are improvements in bandwidth and technology that might allow things to scale well, but I can’t help but think that conflict resolution will be a challenge if many people need to write to the same rows.

    I also know that often we aren’t writing to the same rows, but to the same table. Distributing that is easier, but when we start to look at lots of tables with referential integrity, I wonder how scalable this is. After all, the data needs to get committed and then written to multiple places for this to work well.

    The one advantage in the cloud is throwing hardware at problems like this, often in a more cost effective way than an organization can do in their own data center. Whether this works well remains to be seen, but certainly there are customers and investors that see this as a part of the future.

    Steve Jones