back to article MariaDB inhales $25m. 'People tried to get away with simpler' but now there's a 'relational renaissance,' says open-source biz chief

MySQL cousin MariaDB has grabbed $25m in funding in what represents something of a mini fight-back for good ol' relational databases against the NoSQL family of systems, according to the CEO. Speaking to The Register, Michael Howard claimed a "renaissance" in relational databases was taking place. "It started a couple of …

  1. Charlie Clark Silver badge

    Historically, it had been used mostly as a transactional database.

    Not really, MySQL was for a long time not at all ACID compliant and even when it did add support for it, it wasn't very good: slow with global locking. MySQL was optmised for fast writes from the get go, so basically the same space as the NoSQL toys of today.

    1. Anonymous Coward
      Anonymous Coward

      Re: Historically, it had been used mostly as a transactional database.

      Not to be pedantic but this article is about MariaDB, not Mysql. MariaDB always had XtraDB or InnoDB as the default engine, not MyISAM.

      1. werdsmith Silver badge

        Re: Historically, it had been used mostly as a transactional database.

        In context I think the quote applies to the pre-fork ancestry of Maria.

    2. Tom 7 Silver badge

      Re: Historically, it had been used mostly as a transactional database.

      ISTR inodb was available as an option quite early on - ISTR using it mid 90s on Linux to piss off my systems manager because I could get stuff to run a lot faster than SQLServer4.5 on bigger faster machines.

      1. Charlie Clark Silver badge

        Re: Historically, it had been used mostly as a transactional database.

        Maybe, but it was slow (compared to essentially constraint-free MyASM), buggy and unreliable and, therefore, not officially supported.

        1. Tom 7 Silver badge

          Re: Historically, it had been used mostly as a transactional database.

          I used it on some 300,000 products with 20 odd parameters and 30,000 customers with long sales histories. It worked pretty well for that. ISTR it did multiple of ten transactions a second against a vb web frontend, about 3 times what SQL Server could manage on the same data/indexing etc. I dont recall any bugs but it was left running over a weekend, as was the SQLserver which had about four times the ram and a supposedly faster processor. Anything alkaline would have been useless for the job in hand.

          1. Charlie Clark Silver badge

            Re: Historically, it had been used mostly as a transactional database.

            I'm not disputing that it could work but MySQL didn't approve of it. IIRC you could get a support contract with the guy who came up with InnoDB (and later Oracle who bought it before they bought Sun).

            The first versions of SQL Server were shit but without precise dates it's difficult to say, but if you're talking about a VB website then I reckon you're not talking about the mid-1990s. But there mere existence of the tools for fixing corrupted databases hints at some of the problems.

            Schema changes with InnoDB were (and probably still are) a particular nightmare.

        2. Anonymous Coward
          Anonymous Coward

          Re: Historically, it had been used mostly as a transactional database.

          The more that you learn about MySQL, and, by extension, the cruft that they haven't yet managed to chuck out of MariaDB, the more you discover that it's a bit nastily hacky in rather a few ways.

          For example, I only very recently discovered that MariaDB's initial implementation of UTF8 is a bit insane, and they didn't exactly shout about eventually fixing/bodging it (a bit like all those rubbishy PHP tutorials and books that were still wittering about using the 'mysql' functions while the deprecation clock was already ticking):

          https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434

          In a way, it's rather sad that MySQL gained so much "brand awareness" at the expense of everything else. There are so many FLOSS projects that seemed to choose it just because everyone else did, when they really would have been better picking PostgreSQL, or a sensible database abstraction layer, instead.

  2. Korev Silver badge
  3. bombastic bob Silver badge
    Devil

    NoSQL vs SQL - seriously, it's based on the need

    I've done both the 'simple text file' method AND SQL databases for decades. It's really all based on the need.

    If you have a bunch of text data, you can often use simple command line tools and shell scripts. Sometimes that makes the most sense. I've done a lot of analysis on data like that.

    Sometimes the SQL utility can be used to 'spit out' the columns of data that another tool can crunch to provide charts, etc. and now you have a 'hybrid' solution that is controlled with a shell script or PHP backend.

    It's all based on what the needs are. Having to pick one or the other isn't very creative.

    (My preference is PostgreSQL though, for the SQL side)

    Main point, of course, is that one or the other solution isn't "superior", just different.

    (the most fun solution I did, multiple times in fact, was to create a series of time-based 3D charts from x,y,z text data using gnuplot, then string them together into a video using mencoder's "bunch of jpegs" feature, and play the video to watch the changes in the chart output over time. Built with shell scripts. at the end I added background music to the video to make it more fun. However, watching the video led me to discover a software bug in how the IMU data was being interpreted. Who knew?)

    1. Anonymous Coward
      Anonymous Coward

      Re: both the 'simple text file' method AND SQL databases

      I agree with you, Bob, and have upvoted accordingly.

      However I suspect the non-SQL stuff they are talking about is not text files etc., but the document databases like MongoDB. Your underlying point about picking according to need and not your database religion is sound either way.

      1. werdsmith Silver badge

        Re: both the 'simple text file' method AND SQL databases

        Databases like MongoDB take JSON data which in the end is just a text file.

        Being unstructured it’s less complicated to partition and shard out at the database level. In practice the scaling out with hardware, redundancy and the nodes required to keep track of where your data is gets fiddly very quickly. Especially if you are in cloud and you need to make sure you are not having redundant nodes too close together.

        1. Anonymous Coward
          Anonymous Coward

          Re: which in the end is just a text file

          I wasn't arguing one way or the other - I use MariaDB and Postgres, but also use MongoDB and Redis.

          My point was simply to clarify something that Bob *may* have misread.

        2. Charlie Clark Silver badge

          Re: both the 'simple text file' method AND SQL databases

          Document databases do give you typing but they suffer from the same problems they had in the 1960s when Cood proposed the relational model.

          In practice, the real focus for NoSQL is currently with time series stuff where realtime OLAP is valuable.

  4. Doctor Syntax Silver badge

    "I think the realisation that that was naive and juvenile started a number of years ago"

    The thing about naive and juvenile is that there's always a new batch coming along.

    1. Anonymous Coward
      Anonymous Coward

      Indeed. This particular case (NoSQL) would be funny if it hadn't been funny already 10 years ago and hence kind of stopped being funny by now.

  5. Lars Silver badge
    Thumb Up

    Best wishes

    Best wishes Monty and Maria.

    MySQL started as small as Linux and if I remember it right from the same university too.

    1. werdsmith Silver badge

      Re: Best wishes

      I think Widenius had dropped out of Helsinki many years before he started work with Axmark.

      1. Lars Silver badge
        Happy

        Re: Best wishes

        @werdsmith

        Of course Axmark is worth mentioning and so is Larsson regarding MySQL.

        Quoting the Wiki:

        "After dropping out of Helsinki University of Technology, Widenius started working for Tapio Laakso Oy in 1981. In 1985 he founded TCX DataKonsult AB (a Swedish data warehousing company) with Allan Larsson.[1] In 1995 he began writing the first version of the MySQL database with David Axmark, released in 1996. He is the co-author of the MySQL Reference Manual, published by O'Reilly in June 2002; and in 2003 he was awarded the Finnish Software Entrepreneur of the Year prize"

        When referring to peoples education it's quite normal to mention the University, if there was one.

        One could also add that InnoDB started in Finland.

  6. Tim99 Silver badge

    Overkill?

    Some of the medium/smaller MySQL/MariaDB backed websites out there would work well/better with SQLite. It is also a good prototyping framework for bigger sites, as it is easy to port to PostgreSQL.

    1. werdsmith Silver badge

      Re: Overkill?

      This is precisely how I use it, though Postgre is much better for GIS.

    2. swm Silver badge

      Re: Overkill?

      I love SQLite. When I had to maintain a website for thousands of square dances etc. I thought I would learn SQL for the fun of it. So I put all of the information in an SQLite database and generated web pages from the database.

      Best decision I ever made. If something needs to change or page headers need to be replaced I just modify the appropriate place in the database and regenerate the website. When one of our round dance cuers got married I changed one entry and, presto, everywhere she showed up on the website was changed.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020