Slashdot Mirror
Unified NoSQL Query Language Launched
splitenz writes "Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."
Standards
This Space Intentionally Left Blank
It has Microsoft's backing."
It won't work.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
There was way too much experimentation and innovation going on in the NoSQL world. This should help kill it.
Proud member of the Weirdo-American community.
Link to PDF version of paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.33.3465&rep=rep1&type=pdf
http://www.moonlight3d.eu/
which funnily enough is linked in the summery.
Maybe you should fix this to point to the actual link in TFA http://wwww.unqlspec.org/ ?
"So, everyone will use this unified query language?"
"Yes, it'll be great. No need to rewrite things when moving from one database to another."
"Sounds great. Portable apps! Hooray!"
"It amazes me that nobody has ever done anything like this before."
"Yes, in hindsight it's blindingly obvious. There should have been a single query language all along."
"A single query language--we could call it `S-QL` or something like that."
"Nah, I heard that there's already something called SQL. People would get them confused."
"Why? They're probably totally different things."
"Yeah, probably. It's better to make up new names than to risk confusion. So, what's it called?"
"Uncle."
"Isn't that what you say when you surrender?"
"Yes, but in this case there's no possibility of confusion."
Am I part of the core demographic for Swedish Fish?
Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.
Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.
Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).
Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.
Have you ever used a relational database?
Every NoSQL approach, be it document-oriented, key-value storage, or the various hybrid approaches, can be very easily implemented using relational techniques. In fact, they are all just subsets of the relational model. Key-value storage is merely a two-column table, for instance.
Basically every decent relational database system today allows you to easily partition your data in almost any way possible. It's trivial to store or replicate a single table's data cross hundreds, thousands, or even tens of thousands of storage and processing nodes.
Relational databases work very well for storing hierarchical data, as well. Recursive common table expressions make it extremely easy to work with such data.
There's just no reason to use a NoSQL database. Relational databases can do everything a NoSQL database can, and then a fuck of a lot more.
I just don't get NoSQLers at all. Can somebody explain them to me? So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
Generalizations + lies + attempt to ridicule without facts in hand
Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases.
Apparently obvious to the fact that in many non-trivial business cases, you don't need full ACIDity and an eventually consistency model is more appropriate.
Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.
Generalizations and unsubstantiated blanket statements about a group of software engineers for the mere sake of ridicule (this in contradiction to the first question that is dishonestly presented as a genuine question.)
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
Generalization, speculation.
It doesn't work, and may in fact cause more problems than it actually prevents.
Generalizations + hand waving (surprisingly, this didn't contain an instance to a "think of the children" fallacy)
Now they mistakenly think that their data has better integrity, when it reality it doesn't.
Generalization based on a claim that AFAIK has never been made (a poor man's attempt at a strawman.)
Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)
More generalizations as an attempt to ridicule or even insult (no actual, scientific and honest interest to understand the issue at hand.)
they decide to contort it into a query language.
You do have a point, ergo the need for a querying language, which pretty much the topic of TFA.
Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL.
That is a possibility, your point?
But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy
As it has been made apparent in the shitload of literature, interviews and presentations out there (fucking google it?), it has been acknowledge that NoSQL is a misnomer, as the intention was never to move out of SQL, but to provide alternative/competing data representations to the relational model (which provides a very good formal symbolic representation of a certain ubiquitous but not universal class of data.)
which strongly states that SQL is a horrible thing and should forever be avoided.
Says who? Cite references to this effect.
(But when confronted with this similarity, they'll backpedal and claim that the "No" in "NoSQL" means "not only", contradicting the "NoSQL means no SQL ever!" claims they'd made the week before.)
Red herring, strawman. I short, generalizing stupidity.
In the end, they've spent a lot of time and effort creating a "database" system that doesn't adhere to the ACID principles in any sensible way
Because full ACIDity is not desirable in certain classes of problems. Where have you been all this time?
that uses a mangled
Try to read CJ Date work on relational theory and relational databases. Every single thing you say is wrong, I'm sorry to say that. Relational databases are not about "fixed column data models". It's not an ACID Excel. It's not about tables. It's about sets and how sets relates to it's members and to other sets. This includes hierarchical models, which are easily expressed in a RDBMS.
Those who doesn't understand relational databases are bound to reinvent it, poorly.
splitenz writes:
"Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."
Then, FTA (right at the bottom of it):
This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago, Phillips said.
I know it's slashdot, but c'mon. Just looking at the linked postscript file shows you a major WTF discrepancy. First the paper is from 2000, and then that paper's query language is based on algebras that do not resemble Codd's relational algebra at all. And that runs counter to this, also FTFA:
Like SQL, UnQL was built on the foundation of relational algebra, Phillips said.
The news are great. The coverage blows. It would pay to read the stuff that is being submitted as a story... just sayin...
Developer and former DBA here. Yes, the relational model is more than capable of expressing hierarchical data. However, the SQL language, at least the subset common to most popular RDBMSs, doesn't grok hiearchical data very well. And that leads to a point Codd, Date and others make pretty much every day of their lives: Relational =! SQL. The relational model has elegance and power that can't be expressed in SQL, at least not easily. But many of those confronted with the shortcomings of SQL falsely assume these to be shortcomings of the relational model as well, which in most cases they are not.
Nonaggression works!
This is the issue, fast forwarding to 2010 we are dealing with scaling and environment issues that your precious relational database cannot solve.
Relational databases can scale just fine. It's merely fools like yourself, who are fucking clueless, who have trouble getting them to scale. The problem isn't relational database technology; it's the morons incorrectly designing and implementing the systems who are at fault.
Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.
Well, I would clearly use a real relational database, rather than MySQL. See, using MySQL was your first big mistake. PostgreSQL and Firebird make fine alternatives, and they fit very nicely with your "limited budget" constraint, considering that they're free. Commercial relational database systems work quite well, too, if you're willing to pay a little bit of money.
10 million rows in a single database is absolutely nothing. 10 million rows in a single table is nothing. If you're having trouble scaling with such a small amount of data, then you're doing something seriously, seriously wrong. Whatever it is that you've fucked up, that's yet another mistake on your part. For real professionals, scalability issues usually don't arise until you're dealing with databases containing numerous tables each containing trillions of rows of data.
Of those 300,000 SELECT queries you mention, most are likely unneeded. It sounds like you're just doing a shitty job of caching data. This is yet another mistake you have made.
Only a fool would run a database in a virtual machine that does not provide a proper IO subsystem. If I take the wheels off my car, it's not the car's fault when it doesn't move. Likewise, if you choose the stupidest and most feeble data storage approach possible, it's not the database's fault when IO becomes the bottleneck.
The database you describe can be very easily run, without scalability issues, on most low-end dedicated hosting plans costing a few hundred dollars per year. If your budget so so tight that you can't afford $300 a year, then whatever it is that you're doing is a joke, and the data that you're storing is useless.
(I apologize if your comment was just a joke, and I missed it. Whoosh on me! Sometimes it's just hard to tell when people are joking, and when people are seriously advocating NoSQL techniques. Both involve a similar style of ignorance. In the professional DBA case it is feigned, but in the NoSQL advocate case it is real, pure, honest-to-goodness ignorance.)
so much for UnQL.
Microsoft likes this? Is that why UnQL is pronounced uncool?
I have the opposite problem. If a website doesn't work with NoScript enabled, I deem it broken and never return. I don't have AdBlock, they can show me ads, but not like what you're describing.
I saw an article when I clicked.
Here's the idea. It's my computer, my processor, and if a website wants me to run something they need to ask permission first.
Mr Breivik, is that you?
You must have limited experience, relational model fits only set-based data well. There are plenty of hierarchical data structures for which the relational model is a terrible fit and give abysmal performance for both storage time and queries. I've seen this time and again in my three decades of working with relational databases. A client of mine has been working with medical AI systems for a few years, one early discover was relational model is absolutely an inferior representation for most knowledge base ontologies,
If you're persisting the objects from your oo app then you're already doing it wrong. ORM libraries, etc. are just further down the hole. If you can't be bothered to think about what information describes your objects then you don't have persistence, you have persistent cache which is all hibernate is supposed to be. If your app is boxed software or a game or something then that's probably good enough. But if your app is online and expected to scale and evolve over time then choosing to persist objects rather than information is shooting yourself in the foot.
I'm curious, what happens to all the objects in your object store when the application changes?
bite my glorious golden ass.
BigTable is 15 year old technology that has been completely surpassed by modern relational systems. Many Googlers complain about it and would rather not use it.
The object/relational impedance mismatch is often cited by people who think they should not have to model information to persist information (they mistake their object model for an information model). While it's almost always worth your while to design an information model behind your objects, in the case that it's not you don't have to. Either way a modern relational system has you covered.
bite my glorious golden ass.
And then you ha0ve a use case change. Or need to interface with an app written in another language. Or find that *shock* while a certain object is very effective for holding some information, it's a horrible way of storing for query. An object should be designed for the use case at hand, the database should be designed for efficient retrieval for that and future use cases. The two are damned near never the same. Persistence frameworks are a mistake.
I still have more fans than freaks. WTF is wrong with you people?