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
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
This is expected, did MS write anything well-structured in their history?
I'm fairly sure their legal dept. is well-structured. I could be wrong though.
Write boring code, not shiny code!
No flamewar necessary. Oracle is the new evil overlord.
Having backing from Microsoft just makes it irrelevant.
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]
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.
from TFA : "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."
"DRM is like the Ford Pinto: it's a smooth ride, right up the point at which it explodes and ruins your day."-C.Doctorow
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?
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.
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 ....
Crazy? No. Ignorant. Yes. In essence "the idea of NoSQL was NOT USING SQL AT ALL" is simply not true. This has been mentioned for a while now, but apparently people can't seem to grasp it. NoSQL is a misnomer since the idea is not to move away from SQL but to provide data models alternative to Codd's relational model for a variety of reasons (high availability is just one of them.) I agree that the name needs to be changed, but I'd also say that Google is your friend.
It's a superset of SQL with extra operators? So NoSQL has become SQL? {face palm}
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?
And we are moving into functional and functional-object-hybrid models of programming when the majority of programmers in 2011 cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day. So what's your point?
If we had to wait for every moron code monkey to come up to speed, we would still be reading data off punch cards using a bastard mix of COBOL and mainframe assembly. Industrial and academic R&D and innovation forces have an obligation to move forward. Individual programmers have an obligation to educate themselves and to develop the work ethics to do things right wherever and whenever possible. Lack of the later is not reason to bog down the former.
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!
The Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are:
1. Executing one subprogram, and then another subprogram (sequence)
2. Executing one of two subprograms according to the value of a boolean variable (selection)
3. Executing a subprogram until a boolean variable is true (repetition)
How does one exactly break this theorm?
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.
...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
This is funny, nice link :)
Technically both are correct, you slobbering idiot. :P
I read TFA and all I got was this lousy cookie
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 Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are: 1. Executing one subprogram, and then another subprogram (sequence) 2. Executing one of two subprograms according to the value of a boolean variable (selection) 3. Executing a subprogram until a boolean variable is true (repetition) How does one exactly break this theorm?
It seems exaggeration and figures of speech to express the terrible state of affairs of the programming and software engineering practices cannot be performed lightly in what is supposed to be a "news for nerds" website. Let me break it down for you:
1. Hyperbole:
is the use of exaggeration as a rhetorical device or figure of speech. It may be used to evoke strong feelings or to create a strong impression, but is not meant to be taken literally. Hyperboles are exaggerations to create emphasis or effect
2. Rhetoric:
3. Figurative speech:
S: (n) trope, figure of speech, figure, image (language used in a figurative or nonliteral sense)
With that cleared up, the figure of speech -slash- hyperbolic piece rhetoric below:
cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day
is meant to serve as a grotesque, pejorative description of the equally grotesque situation of programmers - both the type who know nothing but OOP languages like Java or C#, but also "old guard" ones from the procedural bygone era - who despite working with a OOP language end up writing spaghetti with meatballs code.
There are other pejorative terms floating around for a good while now: hyper-spaghetti, GOT-OOP, hyper-lasagna and the like. Even when the code has no goto statements in it, the abuse and apparent lack of coherent use in the nominal control structures mentioned by Bohm and Jacopini makes the disastrous, impenetrable code within and across classes look like the type of GOTO-ridden code Dijkstra railed against it (with Bohm and Jacopini's work as theoretical validation).
These references have existed for a good while now (and given the sentence that preceded it), my hyperbole should have been clear from its context. I guess it was not. The analogy is very clear when you have seen a mass of recently developed production code based on nothing but GOTOs on a past recent enough to have seen widespread use of OOP languages (sadly, I have).
select {result: e}
where {something {something : something}}
Sorry, but simple it is not.
NoSQL databases, especially MongoDB, tend to be more web scale.
NoSQL databases, especially MongoDB, tend to be more cromulent.
There, FTFY.
What the hell is a rant?
the specification can be found here: http://www.unqlspec.org/display/UnQL/Home
wooosh!
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.
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?