RE: Snowflake on Oracle

Thanks Adiya – VERY clear explanations! Looks like Hybrid tables and Unistore are great improvements.

And just to clarify my “dangerous” comments – my intent there was to say that it would be dangerous for ME to work w/either Snowflake or YugabyteDB before more RTFM and experimentation. It was in NO WAY meant to imply that EITHER of these two great products is “dangerous”.

Clay Jackson

From: Aditya Allamraju <aditya.allamraju_at_gmail.com> Sent: Monday, April 17, 2023 12:34 AM
To: Clay Jackson (cjackson) <Clay.Jackson_at_quest.com> Cc: oracle-l_at_freelists.org
Subject: Re: Snowflake on Oracle

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

I currently work for Snowflake. Joined the firm just a few months back. So still catching up on all things Snowflake. Engineers inside have a great respect for Oracle, DB2 and Teradata. But we think we have hit Teradata badly than other RDBMS as it is mainly addressing OLAP/DataWarehouse use-cases. As Kyle has already mentioned, the 3 founders are its biggest strengths. All of them still lead the most critical parts of the database kernel.

I am sure some of you already know this. But those who don't, here are few things to get your attention:

1. Separation of storage and compute i.e both can independently scale.
2. No indexes in Snowflake :)
3. Well known for governance and security which has become a very rigid requirement these days.
4. Batch operations are more encouraged than single-row operations.
5. Snowflake Unistore/Hybrid tables will address OLTP workloads and single-row operations. Serious efforts going in this direction to improve the product. Please watch out for any public previews. There are few customers who are already using them. Ref: https://resources.snowflake.com/external-content/snowflakes-new-unistore-workload-and-hybrid-tables-demo
6. Lastly, it is definitely not dangerous. So is Yugabyte as well :)

Just when I thought about what else can come up in database technologies, products like Snowflake surely did some innovation.

My 2 cents on Yugabyte: It does not fall under the same category as Snowflake. Other well known products in this category(NewSQL) are Google Spanner and SingleStore(previously MemSQL). They address very niche use-cases(this is also their drawback sometimes). Before choosing the products in the category, I strongly suggest knowing how a "commit" works in distributed systems and more specifically in that product you plan to use. Read all about 2PC(all it's variants) and 3pc. Check with their Sales engineer/PM's if you have queries. Know what ACID means for them. Between Yugabyte and Google Spanner, I would personally prefer Yugabyte as it is open source and I understood its architecture more clearly than Google Spanner and its TrueTime API.

Thanks to all of you for keeping this mailing list active. I first heard about this list when I was working at Pythian. It's a pleasure grabbing little nuggets of wisdom from your conversations.

Happy learning!
Aditya

On Sun, Apr 16, 2023 at 9:14 PM Clay Jackson <dmarc-noreply_at_freelists.org<mailto:dmarc-noreply_at_freelists.org>> wrote: I would advise EXTREME caution here – while I only know enough about Yugabyte and Snowflake to be dangerous, I DO know that Snowflake and yugabyteDB store data VERY differently

Clay Jackson

From: oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org>> On Behalf Of Lok P Sent: Sunday, April 16, 2023 11:01 AM
To: Mladen Gogala <gogala.mladen_at_gmail.com<mailto:gogala.mladen_at_gmail.com>> Cc: yudhi s <learnerdatabase99_at_gmail.com<mailto:learnerdatabase99_at_gmail.com>>; joncrisler_at_gmail.com<mailto:joncrisler_at_gmail.com>; kylelf_at_gmail.com<mailto:kylelf_at_gmail.com>; oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org> Subject: Re: Snowflake on Oracle

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

Thank you Mladen for throwing some light on it. I have not used/tested these distributed databases , how the behaviour is in regards to transaction management when compared to existing Monolith RDBMS databases. But yes I was reading through some blogs which were interesting and claimed these being used in some banking services or card authorization/merchant transactions as well. The stories of fiserv and mindgate look interesting too as these were supposed to be relying on RDBMS type database transactions. Not sure if they have handled some of the transaction management in their code itself which traditional databases do inherently without any additional coding at app level.

https://aws.amazon.com/blogs/apn/how-yugabyte-scaled-banking-as-a-service-for-the-temenos-high-water-benchmark/

https://www.itnews.asia/news/payments-firm-mindgate-switches-to-open-source-distributed-sql-database-592868

https://www.yugabyte.com/blog/distributed-database-fintech-innovation/

Regards
Lok

On Sun, Apr 16, 2023 at 4:43 AM Mladen Gogala <gogala.mladen_at_gmail.com<mailto:gogala.mladen_at_gmail.com>> wrote: On 4/15/23 14:39, Lok P wrote:
Google spanner is not sql compatible, or say it has its own proprietary language, so as Oracle guys may tilt towards yugabyte in this regard as Yugabyte is postgresql compatible which is almost Oracle like. Google Cloud Spanner leverages Google's proprietary network infrastructure, YugabyteDB is designed to work on commodity infrastructure used by most enterprise users.

The reason why people go with NoSQL databases is to avoid the transaction handling complexity. The requirement for the query to return only the rows which were committed before the query has started is a rather severe one, forcing the RDBMS system to build the read consistent copy of the blocks. That takes time. NoSQL databases don't have to do that,

As far as "distributed database" goes, one would do well to look for "CAP theorem". There are some limitations which apply to distributed databases. Those limitations are quite severe, as per CAP theorem.

RDBMS was modeled after the banking business. That is why most of the explanations of the transaction consistency mention bank checks. Having a degree in mathematics, I like the naive set theory after which Dr. Codd has modeled his relational model. I'll use the key, the whole key and nothing but the key, so help me Codd.

Yugabyte is a Postgres compatible distributed database. I haven't worked with it, but I did test it, to find whether it would be a good fit for the application that was about to be ported to PgSQL. It wasn't a good fit because it doesn't support 2PC. When the application includes an app server (WAS 9.x), MQ Series and a RDBMS, 2PC is a must because a transaction must commit in both RDBMS and MQ Series. And that was the end of testing YB.

--

Mladen Gogala

Database Consultant

Tel: (347) 321-1217

https://dbwhisperer.wordpress.com<https://dbwhisperer.wordpress.com/>

--

http://www.freelists.org/webpage/oracle-l Received on Mon Apr 17 2023 - 15:57:13 CEST