It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
Dynamic Typing in SQL
11–20 of 27 posts
Re: Dynamic Typing in SQL
#12It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
And a comparison to CockroachDB which also has excellent JSON support along with all the benefits of SQL. See: https://www.cockroachlabs.com/blog/json-coming-to-cockroach/
1. We don't need you to specify the types of any fields, indeed, we don't even need to know upfront which top-level fields ("columns") may exist in the document.
2. You don't need to use special operators / functions to deal with JSON-typed values.
Re: Dynamic Typing in SQL
#13It's not an OLTP system, so is the primary use-case for Rockset to be an OLAP system with low response times?
Re: Dynamic Typing in SQL
#14SQL types are actually default nullable, which puts them to the "not typed enough" category for my taste.
Then you really won't like it that we're moving in the opposite direction :) I personally like strong, static type systems. But a lot of real world data doesn't match static schemas, which is why businesses hire data engineers to (build systems to) clean it up.
I of course recognize that a database is not very useful if you can't get your data in there.
Re: Dynamic Typing in SQL
#15Just learned about Rockset today. Seems interesting but that pricing is way off considering that a columnar data warehouse like Snowflake has great JSON support and can handle way more data for far less. For 10M rows, even a single-node Postgres or MongoDB install will run just fine. It's not an OLTP system, so is the primary use-case for Rockset to be an OLAP system with low response times?
Rockset’s primary use-cases are: 1/ developers building low-latency operational applications, esp. combining real-time data sets with other structured data sets (eg: you are building a microservice to relieve pressure from your OLTP system) 2/ data scientists wanting to quickly test hypotheses on different structured and semi-structured datasets without having to stand-up any servers or do any ETL or data prep. (you can suspend collections/documents in Rockset when you don’t use them -- our pricing page currently only lists Active Documents’ pricing)
Rockset is mutable which allows it to keep itself in sync with any data source, unlike columnar data warehouses, which are not optimized for data manipulation.
Rockset’s strong dynamic typing allows it to treat JSON as a data representation format rather than a special data type or a storage format. So, once you load JSON data into Rockset, you can access all fields at all levels without any special JSON operators or functions.
Comparing Snowflake with Rockset is perhaps akin to comparing Teradata with Elasticsearch. Both useful systems but built for very different use cases.
The biggest thing Rockset has in common with Snowflake is in sharing the philosophy that data management systems have to be built ground up for the cloud to take full advantage of cloud economics. Our blog (https://rockset.com/blog/) has a few posts on these already and we will write more.
Re: Dynamic Typing in SQL
#16Just learned about Rockset today. Seems interesting but that pricing is way off considering that a columnar data warehouse like Snowflake has great JSON support and can handle way more data for far less. For 10M rows, even a single-node Postgres or MongoDB install will run just fine. It's not an OLTP system, so is the primary use-case for Rockset to be an OLAP system with low response times?
Re: Dynamic Typing in SQL
#17Just learned about Rockset today. Seems interesting but that pricing is way off considering that a columnar data warehouse like Snowflake has great JSON support and can handle way more data for far less. For 10M rows, even a single-node Postgres or MongoDB install will run just fine. It's not an OLTP system, so is the primary use-case for Rockset to be an OLAP system with low response times?
Hey, Igor from Rockset here. Rockset’s primary use-cases are: 1/ developers building low-latency operational applications, esp. combining real-time data sets with other structured data sets (eg: you are building a microservice to relieve pressure from your OLTP system) 2/ data scientists wanting to quickly test hypotheses on different structured and semi-structured datasets without having to stand-up any servers or d…
And my comment was more about the price, because at low volume of 10M records, any database system can already do fast queries. From the whitepaper, it looks like the indexing is intensive and that's where most of the cost is coming from, and explains the active/passive storage and tiered rocksdb-cloud setup.
Interesting use-case for prototyping but I don't see how it is cost-effective for higher-scale usages. Congrats on the launch though.
Re: Dynamic Typing in SQL
#18Re: Dynamic Typing in SQL
#19Earlier quoted context omitted.
Hey, Igor from Rockset here. Rockset’s primary use-cases are: 1/ developers building low-latency operational applications, esp. combining real-time data sets with other structured data sets (eg: you are building a microservice to relieve pressure from your OLTP system) 2/ data scientists wanting to quickly test hypotheses on different structured and semi-structured datasets without having to stand-up any servers or d…
The SQL with dot notation is nice, and something other databases have failed at doing with JSON. As for updates, it looks like _id is set automatically, and there's no UPDATE endpoint listed in the docs, so how is data mutated (by key)? And my comment was more about the price, because at low volume of 10M records, any database system can already do fast queries. From the whitepaper, it looks like the indexing is inte…
Our backend architecture is quite scalable and actually grows and shrinks with the demand continuously.
And yes, all documents are automatically indexed and replicated for fast query performance, which is more expensive than just storing them in "_id"->"doc" format. For our use cases and value prop, this one time indexing cost pays for itself several times over by saving time during query processing.
Re: Dynamic Typing in SQL
#20> Strong, because values have one specific type (or None) Because its type system does not provide implicit type conversion I guess. But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract). > Dynamic, because variables acquire type information at runtime, and the same variable can, at different points in time This is not a character…