Re: Big Table ?? vs Oracle and Yugabyte

Hi

Thanks, yes, but that is my real world experience in the last 6, 7 years.

The biggest problem is many decision makers never learn from mistakes (or admit them), but we never lack work because of them!

On Sat, Jun 10, 2023 at 3:50 PM Mark W. Farnham <mwf_at_rsiz.com> wrote:

> ergo, Codd’s seminal paper. (I actually like 1969 better than 1970
> personally, but most folks regard 1970 as the formal publication.)
>
>
>
> Notice that Codd didn’t define SQL. SQL was a limited partial way to
> implement some of the relational model. One of the biggest design
> challenges faced by Chamberlin and Boyce was the capacity of computer
> hardware available circa 1974 and the resulting presumption (along with a
> scrum like notion to get something at all working) that only a subset of
> relational calculous was feasible.
>
>
>
> Sadly, billions have been invested enhancing this language that is
> unlikely to ever be hammered into an orthogonally complete specification of
> relational algebra and tuple relational calculus.
>
>
>
> There is no fundamental limitation, however, that so called nosql wide
> flat files cannot be written in SQL. It becomes a question of cost and
> speed, with cost including licenses, and speed including whether or not
> data is recoverable.
>
>
>
> Sigh. Static definitions of wide records dating back to COBOL have always
> been expensive to change.
>
>
>
> The problem you have noted (feature creep) is indeed a fundamental
> problem, especially for the users of the originally quick and dirty
> implementation of an application that ran fast and cheaply and did what the
> original users wanted.
>
>
>
> Well noted, Ls Cheng!
>
>
>
> mwf
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Ls Cheng
> *Sent:* Saturday, June 10, 2023 5:46 AM
> *To:* pbrunoster_at_gmail.com
> *Cc:* gogala.mladen_at_gmail.com; oracle-l_at_freelists.org
> *Subject:* Re: Big Table ?? vs Oracle and Yugabyte
>
>
>
> 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