Re: Big Table ?? vs Oracle and Yugabyte

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