Re: Snowflake on Oracle

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> 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-1217https://dbwhisperer.wordpress.com
>
>

--
http://www.freelists.org/webpage/oracle-l