Re: Big Table ?? vs Oracle and Yugabyte

From: Ls Cheng <exriscer_at_gmail.com>
Date: Sat, 10 Jun 2023 11:46:10 +0200
Message-ID: <CAJ2-Qb9LXZ_fbjeG0fspyLXPtCbJqhs6UTh9iMRN+pcjBdHqdQ_at_mail.gmail.com>



Hi

The problem is we start with an app requirement which seems suitable in nosql but after a time when some users want to add new features and suddenly some of them need ACID... I have a few customers who started developing some light new app in nosql and have grown to some considerable size in number of users and functionalities, after 2, 3 years nosql was no longer the choice. So the architects who developed the architecture say that the app was not meant to do what they are doing nowadays but no one can stop to add the new app features. Some of them are being migrated to Oracle.

On Thu, Jun 8, 2023 at 9:36 AM pier paolo Bruno <pbrunoster_at_gmail.com> wrote:

> It depends a lot on what you need to achive. Think for example to a
> portal or an application like facebook or a blog. If i publish a photo
> , an article or a blog and i see it now, you see it in 20 seconds and
> someone 1 minute later or 2 , it is not a problem. Same for deletion
> of something . Not every kind of application need acid. If you think
> at financial applications , logistic and many other fields acid is a
> must , but for a very broad kind of application it is not a strict
> requirement and without acid , the database can be much simpler and
> faster . So in my opinion nosql and sql are different things that
> solve different tasks . There are many things and task that you can do
> with a nosql database , the fact is that you have to look at what you
> need and then choose the technology. Perhaps using an rdbms for a
> portal or a blog or a publishing system was not the best choice , like
> using 10 cars instead of a truck can not be the right answer . I think
> there is a great space of application for both the technlogies
>
> Il giorno mer 7 giu 2023 alle ore 20:24 Mladen Gogala
> <gogala.mladen_at_gmail.com> ha scritto:
> >
> > On 6/7/23 10:52, Franky Weber Faust wrote:
> >
> > Hi Kyle,
> >
> > I don't know about Yugabyte, but BigTable has a lot of limitations
> compared to what we can do with Oracle or Postgres. Big Table is a
> wide-column database, so it isn't very compatible with Oracle SQL. I'm
> pretty sure you can insert a massive amount of data into it (as you can in
> Cassandra, which I'm more experienced with), but for every different query
> predicate you'll need a new table, or a materialized view, or a secondary
> index, which all have a cost on resources. BigTable it is not ACID
> compliant either.
> > I think you won't find any other database technology as mature as Oracle
> is, mainly in regard to online operations that you wish. You probably know
> that you need Oracle Enterprise Edition to leverage parallelism and online
> operations and an extra cost feature for partitioning. So it will be
> expensive, but if that's what your business needs and it pays out compared
> to the management overhead and downtime of other solutions, I'm 100% sure
> that is the way to go. I know SQL Server implemented a lot of online
> operations lately as well, maybe it is an option for you as well; it's been
> a while I don't work with it directly.
> >
> > Well, that is my impression with the most of the NoSQL databases I've
> encountered on my quest to boldly go where no DBA has gone before. I've
> encountered Mongo, Couch and Cassandra, which all claim that they're much
> faster than Oracle. They achieve the blinding speed by sacrificing ACID
> requirements. The most problematic thing is "read committed" isolation
> level which mandates that transaction can only see the stuff committed
> before the moment the transaction has started. In particular, that means
> that the old value of the rows has to be reconstructed if the table was
> modified after the transaction has started. In Oracle, the old data has to
> be read from the UNDO segments. Postgres keeps the data within the tables
> themselves and has so called visibility map, but both databases will
> reconstruct the old data. Mongo, Couch and Cassandra will not do that. The
> utility of that depends on the legal framework for which I am no expert.
> >
> > Relational databases, especially the "read committed" isolation mode,
> were modeled after the banking business. That is why the most frequent
> explanation of the transaction is the procedure of the payment with a
> check. ACID rules were written with the banking industry in mind. In the
> early 70's, when Codd and Date were tasked with coming up with something
> better than hierarchical databases like DL/1, only banks had enough money
> to purchase a really big mainframe, like 3090/600J with a whopping 64 MB of
> memory. There is an urban legend about the implementation of the work done
> by Codd and Date. The implementation was called System R (not to be
> confused with Method R) and was allegedly sold for approximately $100 to 3
> guys: Larry Ellison, Bob Miner and Ed Oates. I think we all know what did
> the three of them do with that software. Larry Ellison was a programmer at
> that time, pretty good one, too. He was allegedly the author of the
> venerable RPT/RPF reporting tool.
> >
> > For those of us young enough to have worked with MVS and CICS/DL1
> combination, we know that transactions were being implemented by an
> external piece of software called "TP monitor" (CICS, IMS, Tuxedo and later
> app servers like WebLogic and WebSphere). CICS has even had something
> called "temporary tape" from which the old values were read, in case of a
> rollback.
> >
> > I find Mongo and its ilk most useful as a document store, instead of the
> endless pain and misery with the CLOB columns. However, the lack of the
> enforcement of the ACID requirements will keep those databases at a fringe
> of the IT world. NoSQL databases typically do not support XA protocol which
> may create a problem in the application server environment and the
> application which connects to multiple databases, coordinating commits
> through the app server.
> >
> > --
> > Mladen Gogala
> > Database Consultant
> > Tel: (347) 321-1217
> > https://dbwhisperer.wordpress.com
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Jun 10 2023 - 11:46:10 CEST

Original text of this message