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
This is expected, did MS write anything well-structured in their history?
PlusFive Slashdot reader for Android. Can post comments.
Oh my gosh, they've managed to reinvent SQL, but with a shitter JSON-based syntax.
Unified NoSQL Query Language
You mean, like a No Structured Query Language Query Language?
UnQL - Unstructured Data Query Language
Oh... Wellp, I'm always going to read this as "uncle". Then again I always read SQL as "squeel", so I'm far from the authority on abbreviations, but strangely enough I always read NoSQL as "No Squirrel".
It has Microsoft's backing.
Queue flamewar in 5.. 4.. 3..
SQL - Sequel
UnQL - Un-Cool
~jeremypv
No flamewar necessary. Oracle is the new evil overlord.
Having backing from Microsoft just makes it irrelevant.
They're putting together a structured language for querying this unstructured DB crap.
Microsoft is backing an open-source initiative.
Wake me up when Im sober. No I did not read TFA
I'm sorry... what? TFA has no content and UnQL is from 2000.
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]
slashdot = stagnated
Hopefully the other DBs get on board with this, especially MongoDB and Cassandra, which at the moment seem to be the most advanced and stable. At least that in the future it would be much easier to test and/or migrate from one NoSQL DB to another. Easier options are a good thing !
For example, we've been looking into using a NoSQL solution for storing certain elements of our web application. Unfortunately, it's hard to test the advantages and disadvantages of each without rewriting the connection and logic code. Writing some sort of custom wrapper just for basic testing seems like a huge waste of time and a likely source of errors.
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.)
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. 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.
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. It doesn't work, and may in fact cause more problems than it actually prevents. Now they mistakenly think that their data has better integrity, when it reality it doesn't.
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?), they decide to contort it into a query language.
Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL. But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy, which strongly states that SQL is a horrible thing and should forever be avoided. (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.)
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, that uses a mangled JavaScript-inspired dialect of SQL, that loses data constantly, that doesn't perform any better than existing relational databases, that doesn't have the maturity of existing relational databases, and that doesn't have the rich set of development and administration tools of existing relational databases.
So after all of this time, effort and pain, what have they truly gained? They're worse off than when they started! Instead of spending a few days to a week to learn how to properly use a relational database, they've spent years upon years trying to do a very poor reimplementation of it. Why? Why do they do this?
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/
I don't know how good they are. They tried to sue me but the court couldn't access the complaint without agreeing to a 30 page EULA.
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?
The beauty of a nosql store is defined by this query method get(key) it need to be nothing more and nothing less than that. Adding a query language totally defeats this purpose. Not to mention once you commit to using a search mechanism you are tightly bound to it.
For instance I use mongodb but I do not allow anyone to use it's built in search mechanisms other than find by some key within the app itself.
Sticking to this rule allows us to move to something like pure memcached, membase etc as a store by a simple config change.
Now using search capability outside the app is handy but again tightly binds you to the platform.
Got Code?
Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings ....
am i missing something or is this just same old sql, what exactely is new here? no map/reduce?
UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right.
Learning to run before learning to walk, anyone?
http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale
The link to the spec appears to be http://www.unqlspec.org/ not http://wwww.unqlspec.org/ as shown in the article, which appears to just a site about couchbase.
And in other news, wheel reinvented, news at 11.
The world's burning. Moped Jesus spotted on I50. Details at 11.
So, this is better than existing unstructured languages like SPARQL, how?
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Somehow I feel that MS will be either buying up of these NoSQL companies or is developing their own in the near future. Why else would MS get involved...
What I don't get is why they're adopting something modeled on one of the key weaknesses of traditional relational database management systems. "Familiarity," perhaps, but this seems likely to be superficial, and the stated goal of "creat[ing] some form of commonality among non-SQL databases" strikes me as similar to the goal of finding "some form of commonality among non-elephant mammals."
That there exist applications for data storage where a relational database isn't the appropriate tool is trivial, and well-understood by the relational database community, as is the fact that integrity guarantees are not, in general, available "for free." This has nothing at all to do with one's choice of query language, incidentally.
The whole "NoSQL" thing strikes me as an attempt to use straw man arguments to drum up publicity, which, as I pointed out in response to another article, can be quite brilliant if done artfully. Unfortunately, the NoSQL community is hardly Groucho Marx, and the relational database "establishment," taken as a whole, is hardly comparable to a bunch of money-grubbing, back-stabbing studio executives.
The result, predictably, seems to be even more misinformed skepticism in a field already full of it, sort of like Twain's line about "lies, damn lies, and statistics" being mistakenly invoked as a general indictment of mathematical modeling (and, by extension, most of empirical science).
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...
the CODASYL people they've fresh meat.
Vision with execution is hallucination.
It's a superset of SQL with extra operators? So NoSQL has become SQL? {face palm}
How many years we have till NoUnQL movement?
Step 1: Structured query databases exist for four decades, show they are perfectly capable of scaling, load balancing, and anything else you want them to do.
Step 2: Microsoft writes a structured query database, it can hardly do any of these.
Step 3: "Rararara structured query sucks lets support some half-baked DB idea and as soon as there is a breakthrough buy it up."
Step 4: ???
Step 5: Profit!
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.)
Shitty programmers who cannot be bothered to learn how relational databases work or seem to be completely oblivious to the fact that they are paid to create systems that not only serve the front end consumer user but also people on the backend business side would advocate NoSQL. If the product/service you are writing has anything to do with money, business users need to have information stored in a relational model that can be easily queried or extracted into a data cube for business analytics. This is why you have data translation layers with data transformation objects (DTOs) in the first place to translate your object model into a relational model and back again.
If you work for a "for profit" company that deals with customer and sales data in any capacity then you need to have people competent people working who have at least a basic understanding of the relational model and transactions. If you work for one of those companies and are advocating NoSQL for data that the business needs for data mining or processing sales then you should either be reeducated or offered the door because you have forgotten who your actually work for.
Jesus was a compassionate social conservative who called individuals to sin no more.
so much for UnQL.
Microsoft likes this? Is that why UnQL is pronounced uncool?
http://www.unqlspec.org/display/UnQL/Home
Wow took a lot of looking around!
Of ISAM/VSAM DB engines, which also use Hash Tables vs. B-Trees (what Relational DB's use), so your point was what?
* My take on "NoSQL" DB's is they are a rip-off (or more politely, an "evolution") of ISAM/VSAM stuff IBM was doing ages ago in databases, because of their foundations designs noted above (& largely, the Windows filesystem + registry use a similar concept also iirc).
APK
P.S.=> In the end? Well - Everyone's "building & standing on the shoulders of GIANTS before they" (in other words, reaming ideas/stealing, but... making each iteration better than the last one, hopefully)...
SO, who gains?
Well, we, the end users (that's ALL OF US, everyone IS A CONSUMER), who are, after all, THE IMPORTANT ONES really!
(They're/We're the "customers" & consumers of said products, which is every one of us, & who hopefully PAY for the wares keeping an economy moving (this point? Well, it is 1 of the parts I don't like about "Open SORES" really because FREE can harm economic monetary movements between hands IF you *think* about it... but oems/manufacturers like it because, as in the case of routers, it keeps "per unit" co$t$ down, because the underlying OS or DB engine is "FREE" as in beer etc./et al))...
... apk
Nearly Unstructured Map Space Query Language (NUMSQL, pronounced "numb-skull")
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.
Is that even defined in the "standard" relational algebra?
"Relational databases" (I'll assume you mean RDBMSs here) are not about sets, they're about rows. The difference is that duplicates are permitted unless you explicitly forbid them -- this has various consequences. In relational algebra there is no concept of a "duplicate row".
I have been trying to figure out what exactly is the difference between relational and NoSQL data models.
And, I still don't fully (or at all really) understand them. CAN SOMEONE PLEASE EXPLAIN THE DIFFERENCE
OR at least give me a link to a well thought out explanation with some examples in it?
Honestly, this all sounds like new coke to me
But, I also know that I am not getting something
Queue flamewar in 5.. 4.. 3..
It's cue, you ignorant fuck.
...THIS...
RDMS Scale poorly because of poorly trained dev/admins. I've walked into 10s of shops and _laughed_ at their production RDMS. They would throw hardware at a problem that was from the outset simply poorly engineered. in fairness, most of these VLDB systems were built by glorified 'power' users who just kept hacking away at a problem. Bravo to them for making something work, but at some point when your whole business depends on this intern-built multi-TB database, you need to bring in an expert.
You don't need lots of $$$ to handle VLDB these days. You just need to understand the individual throughput and bottlenecks of the complete solution.
Also, once you understand and properly implement horizontal partitioning, the number of records in your table really doesn't matter.
-Malakai
A Dragon Lives in my Garage
http://xkcd.com/927/
Cassandra has CQL which appears to be farther along. Neo4j has its own query language, as well. This appears to just be CouchDB's variant, which shouldn't be news worthy if they haven't coordinated with their competitors.
This is funny, nice link :)
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,
This is a faggot imposter. I'm informing the FBI that you have stolen my identity.
- The Real Michael Kristopeit
LOL! you are visiting their website, you are using their computer, their processor, their bandwidth. If you want information from their website, you deal with their terms. If you don't like it, then you are free not to visit. You are also free to whine like a little girl if you like. And I am free to make fun of you.
Wasn't this invented before
As someone with 19 years of Object DB experience, I can safely say this idea is stupid. The ignorance of the IT industry never ceases to amaze me. It seems like people have a talent for repeating history and inventing things that already exist. NoSQL as a "movement" is already something of a "wecome to 30+ years ago."
We tried coming up with a standard query language years ago for various "NoSQL" type databases - graph databases, object databases, etc. Everyone decided it was a dumb idea in the end, and companies could not agree because there are more downsides than up sides. What you end up creating is just another library that may be useful for ordinary cases, but overall is useless. It's also a great way to kill many of the benefits of an object, graph, big table, whatever type NoSQL database. Why? Most good NoSQL databases worth anything have specific query techniques and libraries highly optimized for each. The minute you abstract that to a standard, you break not only performance, but you lose functionality because you are trying to comply with a standard.
Consider that the whole point of working with many of these databases is often performance and elimination of impedance mismatches such as object-relational mapping. A standard query language only serves to undo the facilities provided by each vendor. Object and graph databases often already have relatively standard query languages - the languages they are written in. Using collections APIs, map reduce, and other functions in languages such as C++, Smalltalk, Lisp, Ruby, Python, C#, and Scala is more than enough for most databases. Indeed consider that the existing language functionality can form the basis of a more complex query API tweaked for particular use cases. For instance, need massive multi-threading - just write your queries using lockless collections, special data structures, or split up the calls in clever ways. You are given full freedom, and vendors often ship implementations good enough for 99% of people anyway.
One of the other reasons for the status quo is it makes sense that different structures of objects can be optimized by querying with different techniques. Not just on a performance level, but on a framework, maintenance, architectural, and encapsulation level. Flat structures need very different styles of querying than graph structures or deeply nested objects. It is impossible to create a one size fits all query language and is exactly the reason people look for alternatives to SQL.
I'm sorry, but if it pains you so much to learn a query API for your data store, you are in the wrong business. Just about any product, service, or library has its own set of APIs. This is nothing new and not normally a bad thing. Learn them or don't use them, it's your choice. If you are too dumb to figure it out, too bad. Find a new career. If the documentation is bad, bear with it or find something else. Simple as that assuming you have intelligent managers and developers (but maybe a big assumption these days).
I am happy that some people are waking up and seeing that SQL is not always the best tool for the job. Sometimes SQL and Relational DBs are great, but I find most of my problems are better dealt with objects or graphs. The one and only issue I've ever had that the current generation of poor reinventions of the wheel is addressing is scalability. More specifically, distributing data across multiple machines has always been doable, but annoying and sometimes challenging. It's just funny that people "solve" some of these problem by then destroying all the other benefits of using such technologies. Worse yet, they enjoy the research and innovations of the past. Sometimes I wonder if anyone has done any real work since Parc.
No, I'd say you have no grasp of history. Relational designs are a superset of hierarchichal. Also, if you're having problems with performance then your design & implementation are at fault, not the fundamental data model.
I have lots of experience with the hierarchical databases common in medical systems. They have all the flaws that the relational model was built to address. In addition they are killer proprietary and wear their 1960's origins on their proverbial sleeves.
Conversely, I've had lots of experience with those same types of medical systems built on relational constructs. All of a sudden you are back in the modern world, with ODBC drivers, SQL support, access to a broad range of 3rd party toolsets, superior documentation, and so forth. No more arguing with the vendor only to lose every argument because "we (meaning the vendor) don't do it that way". They are not only correct in that assertion, but because they don't acknowledge any outside standards, you cannot effectively bring in any external frame of reference.
select {result: e}
where {something {something : something}}
Sorry, but simple it is not.
what the hell are you waffling on about?
the specification can be found here: http://www.unqlspec.org/display/UnQL/Home
No commercial database system fully implements the relational model, because parts are absurd for real world use. The tables of the relational model are a minuscule subset of the possible hierarchies, not the upside down world view you seem to hold, and the relational systems show their limitations in very poor query response against multiple levels of the data structures. The AI systems of which I speak have their recent origin in the late 90s, unlike the fossilized 60s systems (and moreover the ancient 1970s relational model) you mention. You are an advocate because that's all you know.
I hate updating data using SQL. The need to have both INSERT and UPDATE statements, with their very different syntaxes, is a considerable drag on my time. I've worked with non-SQL DBMSs in the past, and it can be so very much easier.
Don't get me wrong, there's a lot I like about SQL, but my ideal database would support SQL for queries, but also provide simpler mechanisms for read by key and create/update/delete operations.
I have 5-10 years of experience with this new UnQL NoSQL query language. Who will hire me?
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,
The relational model fits hierarchical data just fine. It's only the awkwardness of SQL that was holding you back or the particular implementation if queries were too slow. Is any of your experience based on a non-SQL relational language?