Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Mariadb, and other mysql spinoffs, have one key advantage over mysql....not owned by Oracle.

Aka...

MariaDB is not trying to keep mysql a technology backwater to protect proprietary Oracle db offerings. Its also not in bed with the NSA. Anyone that uses any Oracle products (including oracle implementation of Java), the same company that got its start selling software to the CIA, is dumb as a rock if they think they are getting security.

I've tried out MariaDB specifically, the Galera Cluster many times and found it to be very lacking. The default Debian repos just seem broken and have been for a long time according to the bug reports i've read. Apart from the broken packages the fact that the documentation is very lacking and dotted all over the place has put me off. After MariaDB I moved on to Percona's implementation which comes with working packages and good documentation.

What are the advantages to using this increasingly slow and bloated fork of the internet's favorite database platform?

Mind giving examples showing this to be true? This is the 1st I'm hearing about this although I don't follow it all the time. I'm just curious about how MariaDB could be so slow considering that the founders of MySQL are working on that version now.

NoSQL means the same thing it always means, "ACID is hard, so we don't do it."

ACID is expensive to scale. NoSQL offers little when you have 1 or 10 DB servers. But if most of what you store doesn't need to be ACID, and you need 10,000 DB servers, NoSQL has a real cost advantage.

As with everything cloudy, it's few software products but many, many end users.

Well, that and the vast majority of simple programs that don't need ACID to begin with. If you just need a non-ACID structured data store, why bother with SQL? Currently NoSQL is mostly for analytics, but I think that's just habit.

no idea, but I know Postgresql has had JSON columns [postgresql.org] for a while now, so you get the benefit of 'typeless' data storage (ie a blob of JSON data) and all the benefit of relational data if you want it (as its just another column).

MariaDB did it differently [mariadb.org], merging Cassandra as a storage back-end, and "dynamic columns' so you can have different columns of data per row in a table. (and you can get all the dynamic column data out as a JSON blob).

Hey that is interesting, I have a system here where I store small amounts of JSON data as text column, since I don't have to query that text column it is not a problem for me (although I have to deal with missing values by hand), but how would you go about querying data from those types of "document-store" columns?

MySQL has always been a way to serve unimportant data at high speed. Great if you're serving up fuzzy matches to people who are doing a Google search and have no preconceptions about what they will get back in response to a search, or organizing a web forum visited by millions where if you lose someones comment, you really don't care. If you're dealing with data where accuracy, reliability and predictability is important, though, it was

I guess we better not use C/C++ in that case. Getting integer overflows means it's not a serious language, we should call them "fuzzy integers" instead.

If you find a C++ compiler that will let you declare a variable of type 'foo' and store an object of type 'bar' in it without throwing any errors, despite 'bar' not inheriting from 'foo', then yes, I would say it's not a compiler you want to use to do serious work with.

You're like a dog with a bone. Last time I worked with MySQL was 5.0.1, and it was letting people insert ASCII strings into integer fields, and every time people expressed concerns, all you saw was rhetoric about how that should have been dealt with at the application layer. Which is fine if you're setting up a web forum, but not when you're organizing an enterprise that spans the world and has numerous applications accessing it, where one junior programmers mistake can hose your whole fucking enterprise. No client has mandated that I MUST use it since, therefore, I haven't used it since, and asked a serious question.

The history of MySQL was very well summed up in an earlier post: "ACID is hard, therefore we don't do it."

Not just me... most professionals know this and accept it and know that not every tool fits every scenario. Don't know what YOUR fucking problem is.

Try implementing hundreds of pages of ISO specifications for medical applications, then come back and talk to me about the "complexity" of Wikipedia. It has users, posts, edits, search and not a whole hell of a lot more than that. It's a web forum, not overly different from Slashdot. If they lose a post, no one really cares that much.

C/C++ don't claim to follow relational data rules like MySQL does. Not only is SQL supposed to error if it can't do *exactly* as the user describes, it's supposed to change nothing if any of the affected rows error. It's not supposed to be allowed to guess if the user tells it to do something ambiguous or nonsensical. It's supposed to be required to throw an error in that case. Indeed, many RDBMSs error on some tasks simply because the result would be non-deterministic.

I think his point is to say that MySQL is a full fledge SQL database is like saying IE 6 is a standards compliant web browser. Both do the job adequately for most people, but both aren't without serious faults.

MySQL owes its success to web frameworks where better SQL servers like Postgres are considered an overkill and it works quite well in that domain. If your requirements are more on the SQL-side than the web-side of the equation, you

MySQL's had a strict mode since 2004 to reject invalid data. They didn't make it default until late 2012 though in 5.6.8, and I couldn't find what the MariaDB default is (short of downloading the source and looking). Even then, they only it in the default config file, so manual or distro-specific configs that omit the setting will fall back to the old truncation mode.

MySQL's had a strict mode since 2004 to reject invalid data. They didn't make it default until late 2012 though in 5.6.8, and I couldn't find what the MariaDB default is (short of downloading the source and looking). Even then, they only it in the default config file, so manual or distro-specific configs that omit the setting will fall back to the old truncation mode.

Yeah, but it didn't always work. I know what the docs say. The last time I looked at them, they were wrong. I don't trust them not to still be wrong, because I've been in the trenches long enough know the man behind the project is a liar and an attention whore. I was hoping to hear from someone who could say "Yeah, I tested it recently, and the constraints work fine now/are still silently ignored."

The summary says the replication slaves are now crash free, but TFA says they are crash-safe. My database knowledge doesn't go very deep, but I think the latter means they won't lose data on crashes, not that they never crash.

Because NoSQL, does not stand for what it appears to stand for. It's a really crappy acronym. NoSQL really stands for "Not Only Structured Query Language" as compared to "Doesn't support Structured Query Language". So, something that is "NoSQL" will do SQL styled queries as well as other types of non-SQL queries