6 ms·

Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these

Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.

Waterluvian 9y ago
That's what I was wondering too. It feels like SQL and NoSQL will meet in the middle: JSON with SQL support, SQL with JSON support.
- overcast 9y ago
  Which is why I'm depressed RethinkDB failed to take off :(
- mcintyre1994 9y ago
  This is basically what Microsoft's Cosmos DB is, you store JSON documents, don't have to define a schema and you can query them with SQL.
  - malloryerik 9y ago
    And you can also bake in graph relations, right? How has your experience been with CosmosDB?
    - mcintyre1994 9y ago
      To be honest I've only used it for pretty trivial things, I didn't do any joins. From the docs [0] it looks like they only have self joins, so joining on children or something like that but not across documents/collections. Depending how much graph relation stuff you need you might be better off just using the graph API. I have no experience with that though. Or they support a MongoDB API if that covers your needs too. Like I said I've only done basic stuff, but I really liked it - it's performant and really easy to set up and use. I used the Python API and it was really easy, then I switched to the Node one to try using it in Azure functions (Python library imports aren't really supported there) and that's nice too - it uses promises and works great. It also doesn't feel like a giant lockin (IMO) - their APIs work anywhere and there's no magic in Azure AFAIK to make you put your compute there if you're using the Database. [0] https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql-query https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql...
- egeozcan 9y ago
  "Mongres is a PostgreSQL extension that runs a custom background worker speaks mongo wire protocol." https://github.com/umitanuki/mongres https://github.com/umitanuki/mongres
  - btown 9y ago
    There's also https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-schema/ https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-... which tails the Mongo oplog and makes a fully-relational read replica, adding columns and indices as needed. An amazing (and free) shortcut to using analytics tools if Mongo's your main datasource.
drmirror 9y ago
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.
- mason55 9y ago
  > otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
  - matwood 9y ago
    As an aside, I hate the term 'schemaless' because there is always a schema. https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/ https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
    - lukaseder 9y ago
      Yep. Schema-on-read (E.g. MongoDB) or schema-on-write (E.g. Oracle)
  - metheus 9y ago
    Quibble: “schemaless” isn’t accurate, MongoDB supports schema (JSON Schema, in fact). We often say “dynamic schema”. But your main point is good—- JSON isn’t the essence of it. And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.
- jeremiep 9y ago
scarface74 9y ago
I really don't need Sql compliance - I use C# and the Linq provider is pretty good.
sixdimensional 9y ago
Just remember, SQL is and always was "not only relational" - a play on the, should be long dead and buried acronym NoSQL (IMHO). Structured query language - I know for a fact from actually doing it (see Cache database, Hadoop schemaless SQL, even a product I worked on that was SQL to Mongo, heck the SQL standard itself) - guess what - it works with object/document stores too! Mongo could have implemented SQL on top of their storage engine a long time ago minus the joins. Instead they built their own query mechanisms. Mind you, mapreduce can't be reproduced explicitly in SQL, but SQL expressions can compile to Mapreduce (see Apache Hive), so even that was not an excuse. Edit: NoSQL served a purpose to remind people that there were other options other than relational databases (including those that predate the relational model and those that came after it), but man, what a terrible and misleading misnomer.
- munk-a 9y ago
  On this point, the datastores that have insisted on using a query language that isn't SQL have always seemed to just be attempts at setting up walled gardens. Plenty of people have extended SQL when their needs required it (MySQL, PostgreSQL, Oracle, TSQL/MSSQL) but intentionally rejecting the basic format of SQL queries just seems like an attempt to setup a barrier to ever move off your DBMS. Speaking as someone who ported an application from MySQL to MSSQL there is still a lot of work required to remove those custom extensions, but the core of what you're doing can remain the same.

Waterluvian 9y ago

That's what I was wondering too. It feels like SQL and NoSQL will meet in the middle: JSON with SQL support, SQL with JSON support.

overcast 9y ago
Which is why I'm depressed RethinkDB failed to take off :(
mcintyre1994 9y ago
This is basically what Microsoft's Cosmos DB is, you store JSON documents, don't have to define a schema and you can query them with SQL.
- malloryerik 9y ago
  And you can also bake in graph relations, right? How has your experience been with CosmosDB?
  - mcintyre1994 9y ago
    To be honest I've only used it for pretty trivial things, I didn't do any joins. From the docs [0] it looks like they only have self joins, so joining on children or something like that but not across documents/collections. Depending how much graph relation stuff you need you might be better off just using the graph API. I have no experience with that though. Or they support a MongoDB API if that covers your needs too. Like I said I've only done basic stuff, but I really liked it - it's performant and really easy to set up and use. I used the Python API and it was really easy, then I switched to the Node one to try using it in Azure functions (Python library imports aren't really supported there) and that's nice too - it uses promises and works great. It also doesn't feel like a giant lockin (IMO) - their APIs work anywhere and there's no magic in Azure AFAIK to make you put your compute there if you're using the Database. [0] https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql-query https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql...
egeozcan 9y ago
"Mongres is a PostgreSQL extension that runs a custom background worker speaks mongo wire protocol." https://github.com/umitanuki/mongres https://github.com/umitanuki/mongres
- btown 9y ago
  There's also https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-schema/ https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-... which tails the Mongo oplog and makes a fully-relational read replica, adding columns and indices as needed. An amazing (and free) shortcut to using analytics tools if Mongo's your main datasource.

drmirror 9y ago

I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.

mason55 9y ago
> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
- matwood 9y ago
  As an aside, I hate the term 'schemaless' because there is always a schema. https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/ https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
  - lukaseder 9y ago
    Yep. Schema-on-read (E.g. MongoDB) or schema-on-write (E.g. Oracle)
- metheus 9y ago
  Quibble: “schemaless” isn’t accurate, MongoDB supports schema (JSON Schema, in fact). We often say “dynamic schema”. But your main point is good—- JSON isn’t the essence of it. And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.
jeremiep 9y ago

scarface74 9y ago

I really don't need Sql compliance - I use C# and the Linq provider is pretty good.

sixdimensional 9y ago

Just remember, SQL is and always was "not only relational" - a play on the, should be long dead and buried acronym NoSQL (IMHO). Structured query language - I know for a fact from actually doing it (see Cache database, Hadoop schemaless SQL, even a product I worked on that was SQL to Mongo, heck the SQL standard itself) - guess what - it works with object/document stores too! Mongo could have implemented SQL on top of their storage engine a long time ago minus the joins. Instead they built their own query mechanisms. Mind you, mapreduce can't be reproduced explicitly in SQL, but SQL expressions can compile to Mapreduce (see Apache Hive), so even that was not an excuse. Edit: NoSQL served a purpose to remind people that there were other options other than relational databases (including those that predate the relational model and those that came after it), but man, what a terrible and misleading misnomer.

munk-a 9y ago
On this point, the datastores that have insisted on using a query language that isn't SQL have always seemed to just be attempts at setting up walled gardens. Plenty of people have extended SQL when their needs required it (MySQL, PostgreSQL, Oracle, TSQL/MSSQL) but intentionally rejecting the basic format of SQL queries just seems like an attempt to setup a barrier to ever move off your DBMS. Speaking as someone who ported an application from MySQL to MSSQL there is still a lot of work required to remove those custom extensions, but the core of what you're doing can remain the same.