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 <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Lok P
Sent: Sunday, April 16, 2023 11:01 AM
To: Mladen Gogala <gogala.mladen@xxxxxxxxx>
Cc: yudhi s <learnerdatabase99@xxxxxxxxx>; joncrisler@xxxxxxxxx;
kylelf@xxxxxxxxx; 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/>
