Re: Snowflake on Oracle

_at_Frank as you seem to be more familiar with Yugabyte, so wanted to know your views on the two points below from Mladen' regarding Yugabyte DB from this thread?

*"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*."

"*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*."

_at_Aditya, to your below point on Snowflake,

*"1)Separation of storage and compute i.e both can independently scale."* The compute can be scaled infinitely because each compute/warehouse is based on "shared nothing" architecture i.e. they are independent from each other and also does not operate on any common structure(say sequence/constraint/indexes etc) so no talking between two compute/warehouses is needed. However in regards to the storage, snowflake has common storage i.e. "shared everything" architecture , which is shared among all the nodes/warehouses (Like Oracle or any other common RDBMS), so how can that be scaled infinitely? Won't that suffer I/O saturation at certain point in time with high read/write activities on storage as because it's common/shared across all the compute nodes?

*"2. No indexes in Snowflake :)"*
Regarding the second point, though the name is different, isn't snowflake "search optimization service" indirectly creating indexes under the hood ?

Additionally, as in case of "Unistore/Hybrid tables" we will have the indexes/constraints as it is there in common OLTP databases and the data store will be in row format along with column format, so how can the compute be then be scaled independently? Don't the compute nodes(warehouses) have to talk to each other to ensure the integrity, uniqueness etc? It appears similar to the Oracle In-memory database option , in which Oracle stored data in columnar format along with the traditional row based format. Correct me if I'm wrong? I am wondering if with "Unistore", Snowflake is going to do the same i.e maintain data integrity. ACID compliant retaining all the RDBMS transaction properties , so then howcome it will operate more optimally as compared to common RDBMS databases?

Regards
Lok

On Tue, Apr 18, 2023 at 12:52 AM Franck Pachot <franck_at_pachot.net> wrote:

> I see a lot of guesses on YugabyteDB and Snowflake. Those are very
> different: Snowflake is a proprietary managed service for data warehouse.
> YugabyteDB is open-source distributed SQL for OLTP. I know nothing about
> Snowflake but can explain YugabyteDB if you want to. It re-uses PostgreSQL
> code for the SQL processing, to provide most of the PostgreSQL features but
> the storage and transaction are completely different implementation. This
> means no vacuum - it is there for compatibility only but is a no-op:
>
> yugabyte=# vacuum;
> WARNING: VACUUM will be ignored
> VACUUM
> yugabyte=#
>
>
> I also see some mention of NewSQL and Google Spanner and SingleStore.
> NewSQL is a general term that includes distributed storage like Aurora
> which are still single writer, and sharding over traditional databases.
> DistributedSQL is the term for the Spanner-like architecture: Google
> Spanner, TiDB, CockroachDB, YugabyteDB
> SingleStore (ex-MemSQL) does not support all SQL features over distributed
> tables (for example foreign keys) and then is not Distributed SQL.
>
> Franck
>
> On Mon, Apr 17, 2023 at 7:49 PM kyle Hailey <kylelf_at_gmail.com> wrote:
>
>>
>>
>>
>> >> All the Postgres stories about vacuuming apply to YB.
>>
>>
>> Franck Pachot
>> <https://twitter.com/FranckPachot>
>> _at_FranckPachot
>> <https://twitter.com/FranckPachot>
>> ·
>> Apr 9 <https://twitter.com/FranckPachot/status/1645162272019316741>
>> Replying to
>> _at_kylelf_ <https://twitter.com/kylelf_>
>> _at_PostgreSQL <https://twitter.com/PostgreSQL>
>> and
>> _at_Yugabyte <https://twitter.com/Yugabyte>
>> _at_Yugabyte <https://twitter.com/Yugabyte> has no vacuum and no undo. The
>> LSM-Tree compaction gets gids of expired MVCC versions at the storage
>> level. No locks. More like an online defrag of files
>>
>> [image: image.png]
>>
>> On Mon, Apr 17, 2023 at 8:54 AM Mladen Gogala <gogala.mladen_at_gmail.com>
>> wrote:
>>
>>> On 4/17/23 00:14, Clay Jackson (Clay.Jackson) 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
>>>
>>> Of course they do. YB is a Postgres compatible OLTP database which
>>> stores rows in the table. All the Postgres stories about vacuuming apply to
>>> YB. Snowflake, on the other hand, is a columnar DW database. They are very
>>> different animals.
>>>
>>> --
>>> Mladen Gogala
>>> Database Consultant
>>> Tel: (347) 321-1217https://dbwhisperer.wordpress.com
>>>
>>>

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





image/png attachment: image.png