RE: Big Table ?? vs Oracle and Yugabyte

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