August 13, 2018 at 9:01 am
Comments posted to this topic are about the item What is NoSQL?
August 13, 2018 at 9:08 am
Quick answer to the question would be "NoSQL" = "NoNoSQL" if you are doing SQL😉
😎
August 14, 2018 at 3:31 am
I have worked with SQL Server for about 12 years. I like it and I'm not very familiar with NoSQL.
There is one exception: I have been playing with SPARQL which is a query language somewhat similar to SQL. SPARQL works with 'triple stores' which store subject, predicate, object (SPO). If you imagine a conventional SQL table, then store each individual value in a triple consisting of (primaryKey, columnName, Value) this shows how relational data can be mapped to and from triples.
SPARQL shows its power when used with DBpedia. DBpedia is an extract of wikipedia which stores all wikipedia infobox data in a giant triple store. Using SPARQL you can (in theory) extract any of the data into a tabular form, or XML, or json.
Going back to SQL Server, it would be great if Microsoft included SPARQL support as an add-on, a bit like with 'R' (I know the latest version of SQL Server has graph support but that's not SPARQL). If SQL Server supported SPARQL, it would open up all the structured Wikipedia data to queries in SQL Server.
August 14, 2018 at 7:19 am
William Rayer - Tuesday, August 14, 2018 3:31 AMI have worked with SQL Server for about 12 years. I like it and I'm not very familiar with NoSQL.There is one exception: I have been playing with SPARQL which is a query language somewhat similar to SQL. SPARQL works with 'triple stores' which store subject, predicate, object (SPO). If you imagine a conventional SQL table, then store each individual value in a triple consisting of (primaryKey, columnName, Value) this shows how relational data can be mapped to and from triples.
SPARQL shows its power when used with DBpedia. DBpedia is an extract of wikipedia which stores all wikipedia infobox data in a giant triple store. Using SPARQL you can (in theory) extract any of the data into a tabular form, or XML, or json.
Going back to SQL Server, it would be great if Microsoft included SPARQL support as an add-on, a bit like with 'R' (I know the latest version of SQL Server has graph support but that's not SPARQL). If SQL Server supported SPARQL, it would open up all the structured Wikipedia data to queries in SQL Server.
SPO sounds exactly like EAV.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
August 14, 2018 at 7:30 am
Actually, [SQL Server] is a NoSQL database engine. It naively supports reading and writing data contained in row, columnular, xml, flat text, or blob format. It supports queries using: SQL, XQuery, JSON, and R.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 14, 2018 at 9:33 am
It is now. We have graph as well.
I might argue that the flat text and blob formats are still relational, just holding those types.
August 14, 2018 at 12:40 pm
Steve Jones - SSC Editor - Tuesday, August 14, 2018 9:33 AMIt is now. We have graph as well.I might argue that the flat text and blob formats are still relational, just holding those types.
A Cosmos DB developer might see those same blobs as documents, and an Excel developer might see the same flat files as spreadsheets. One could say that tables, graphs, sets, cursors, and relationships are the logical semantics and programming that we transpose on top of the data.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 14, 2018 at 1:53 pm
I think it's funny how all of these "NoSQL" environments now support some flavor of SQL. In reality, they meant to be non-relational.
I've seen many projects implemented in Hadoop with files structured as tables and HIVE SQL or SparkSQL installed on top to allow querying. Why go through all that effort to avoid a RDBMS only to effectively make it act like one?
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
August 15, 2018 at 1:19 am
I heard Simon Munroe's presentation when SQL Bits was held in Westminster. At the time I asked if NOSQL should really be NORDBMS and was told no. Now that so many NOSQL stores implement SQL I still think the more accurate definition would be NORDBMS.
SQL has been described as the "Narrow Waist" which I think is quite a good description.
For on-premise deployments I feel that the vast majority of enterprises gain little from NOSQL stores and scale out architectures other than employees with broader CVs. Once you start operating at serious scale then NOSQL and scale out architectures in the cloud start to make more sense. It is all about the compromises you choose to make because no choice is for free.
Getting stuff into NOSQL stores is easy. Getting stuff out en-masse isn't.
Let us suppose that adopting a NOSQL store allows developers to develop and iterate faster. My experience is that the gain from that faster pace is lost by the difficulties in integrating the data. Why would you capture the data if you don't have a purpose for it? Actually, post GDPR you mustn't capture data unless you have a legitimate purpose for it.
August 15, 2018 at 8:50 am
RDMS are typically SQL based, but a RDMS can also use some other query language besides SQL, and a non-RDMS (or NoSQL) database can also use SQL. It seems to me that NoSQL is really all about sacrificing the ACID properties of the relational paradigm (Atomicity, Consistency, Isolation, Durability) for the purpose of improved performance and scalability. Even SQL Server developers try to circumvent ACID by using features like NOLOCK and Delayed Durability, and a significant percentage of SQL Server related forum posts are really just somebody wanting to know if it's possible to bypass locking and transaction logging.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 15, 2018 at 9:24 am
Eric M Russell - Tuesday, August 14, 2018 12:40 PMA Cosmos DB developer might see those same blobs as documents, and an Excel developer might see the same flat files as spreadsheets. One could say that tables, graphs, sets, cursors, and relationships are the logical semantics and programming that we transpose on top of the data.
I was speaking of the actual storage. They're stored relationally. XML data type is stored this way, but it's also optimized for that type. The Graph stuff might be relational, but I think the implementation is different. In CosmosDB, a blog in a document store isnt' a relational store, it's fundamentally different.
August 15, 2018 at 9:25 am
Aaron N. Cutshall - Tuesday, August 14, 2018 1:53 PMI think it's funny how all of these "NoSQL" environments now support some flavor of SQL. In reality, they meant to be non-relational.I've seen many projects implemented in Hadoop with files structured as tables and HIVE SQL or SparkSQL installed on top to allow querying. Why go through all that effort to avoid a RDBMS only to effectively make it act like one?
Not Only SQL is what it means. The intention wasn't to never use SQL, though the popular stores tried to do away with it. What they've learned is that SQL actually works pretty good, and more importantly, it's a well known language.
August 15, 2018 at 10:32 am
Steve Jones - SSC Editor - Wednesday, August 15, 2018 9:24 AMEric M Russell - Tuesday, August 14, 2018 12:40 PMA Cosmos DB developer might see those same blobs as documents, and an Excel developer might see the same flat files as spreadsheets. One could say that tables, graphs, sets, cursors, and relationships are the logical semantics and programming that we transpose on top of the data.I was speaking of the actual storage. They're stored relationally. XML data type is stored this way, but it's also optimized for that type. The Graph stuff might be relational, but I think the implementation is different. In CosmosDB, a blog in a document store isnt' a relational store, it's fundamentally different.
I don't think that the relational model or the ANSI SQL standard requires that the data be stored on disk or in memory in a specific physical format. Relationships, constraints, and rows are at the logical level. Like, on disk, a clustered table is very different from a heap, and a ColumnStore table is very different from the original RowStore table format, and of course compressed data looks different on disk than in memory.
So, if a multi-dimensional cube, or a collection of flat files, or a key value store can be made to express all the rules of a relational database and the SQL language, then it meets the relational database equivalent to a "Turing Test". We can still call it a RDMS, even if loading a new "table" is as simple as copying a new file to the disk system. We can't say it isn't relational simply because the data isn't stored physically in a certain way.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 15, 2018 at 10:04 pm
Aaron N. Cutshall - Tuesday, August 14, 2018 1:53 PMI think it's funny how all of these "NoSQL" environments now support some flavor of SQL. In reality, they meant to be non-relational.I've seen many projects implemented in Hadoop with files structured as tables and HIVE SQL or SparkSQL installed on top to allow querying. Why go through all that effort to avoid a RDBMS only to effectively make it act like one?
This is like the second time you've quoted how people are using the tool rather than talking about what the tool can do. People do crazy things with these tools. Sometimes for the right reasons, sometimes for the wrong reasons. Just because people use these for the wrong reasons or use them poorly has nothing to do with the tool itself unless for some reason the tool is forcing them to do so. Like, I've seen plenty of people use SQL Server as tabular reporting with zero relationships. Be silly to hold that against SQL Server and mention it.
Personally, I've seen similar to what you have mentioned above, but in efforts to structure the data to go INTO a RDBMS. This is essentially how I use it myself. Land TB's of data into the store, structure it and then load it into the RDBMS for keys, validation, etc for actual serving and querying. Now, if people are bypassing the RDBMS and just sticking to Hive, well, that's another story all together and nothing against the tool.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply