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@xxxxxxxxx>
Sent: Monday, April 17, 2023 12:34 AM
To: Clay Jackson (cjackson) <Clay.Jackson@xxxxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>> 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@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
<oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>> On Behalf
Of Lok P
Sent: Sunday, April 16, 2023 11:01 AM
To: Mladen Gogala <gogala.mladen@xxxxxxxxx<mailto:gogala.mladen@xxxxxxxxx>>
Cc: yudhi s <learnerdatabase99@xxxxxxxxx<mailto:learnerdatabase99@xxxxxxxxx>>;
joncrisler@xxxxxxxxx<mailto:joncrisler@xxxxxxxxx>;
kylelf@xxxxxxxxx<mailto:kylelf@xxxxxxxxx>;
oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxx<mailto:gogala.mladen@xxxxxxxxx>> 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/>
