RE: How to choose a database

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Sun, 23 Apr 2023 09:05:49 -0400
Message-ID: <283101d975e4$5413d740$fc3b85c0$_at_rsiz.com>



I may not correct what you mean by “monolith.” I will ask for further clarification of what you mean. When a word is used as a label, clear communications requires that we understand exactly what you mean.  

It seems that you mean to define it partly by what it is not (that’s okay). I believe monolith characteristics in your meaning are that horizontal scaling is not generically available and that sharding is not generically available.  

I’m curious whether (or not) you consider adding hosts to an Oracle RAC configuration as horizontal scaling (and therefore not monolithic).  

I’m curious whether (or not) you consider transaction routing by key content between the transaction source and rdbms services as generic sharding.  

If you’re trying to create a recipe card for how to choose a database (presumably rdbms system), I believe you will quickly run into questions of the anticipated volume (and therefore engineering cost justification) and the subject matter of the applications to be hosted.  

A trivial example of “manual” sharding is the time zone of the source transaction. With a modest amount of planning that scales horizontally from 1 global zone to 3 or 4 contiguous continental zones to 24 hourly zones.  

Another key factor is whether (or not) a system provides for reasonably good two phase commit so that multiple database servers provide a de facto horizontal expansion. Again, the actual database services to be provided must be considered as well as volume and continuation capabilities in the event of building, campus, and regional disasters.  

All these things are important in choosing which database systems to deploy, including whether (or not) analytics should be performed on the detailed original receipt of data that is subject to changes or on a downstream aggregation designed to answer questions about what has happened as opposed to handling the receipt and manipulation of the data.  

It may be the case that an expert system can be designed to provide system architecture recommendations based on a clear statement of goals.  

My experience is that getting a clear statement of the goals is the tricky part. Then it can be asked which database services would be a useful configuration to support those goals. In that context, whether or not something is a “monolith” by anyone’s definition is irrelevant.  

Good luck,  

mwf  

From: Pap [mailto:oracle.developer35_at_gmail.com] Sent: Sunday, April 23, 2023 2:48 AM
To: Mark W. Farnham
Cc: yudhi s; Oracle L
Subject: Re: How to choose a database  

You may correct me if wrong, but what I mean is monolith is something which is not horizontally scalable which means the same box has to be replaced with higher cpu, memory or IO power rather adding more number of same memory , cpu, IO power boxes horizontally to cope up with the increased load. And thus , these distributed databases can adopt to a higher load and can 'scale in' or 'scale out' easily without downtime.  

And to my understanding distributed databases are meant to cater that need. And I believe sharding is critical for these systems but again manual sharding not always an easy option always.  

On Sun, 23 Apr, 2023, 2:51 am Mark W. Farnham, <mwf_at_rsiz.com> wrote:

what do you mean by monolith?      

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Pap Sent: Saturday, April 22, 2023 4:28 PM
To: yudhi s
Cc: Oracle L
Subject: Re: How to choose a database  

 Actually I was trying to understand in general for database selection process(it may be oltp/olap). But say for e.g if we take specifically distributed RDBMS/sql databases (as opposed to monolith) , and compare cockroach vs yugabyte vs aurora postgres/mysql , what would be the goto database and why?  

On Sun, 23 Apr, 2023, 1:51 am yudhi s, <learnerdatabase99_at_gmail.com> wrote:

Any specific use case or database you are comparing?  

On Sun, Apr 23, 2023 at 1:23 AM Pap <oracle.developer35_at_gmail.com> wrote:

Hello Listers, There has been a discussion recently in this forum, which started with a question on "snowflake"(i.e an analytical database) and ended up discussing the compute+storage architecture compared with Google spanner, Yugabyte DB etc which are Relational/OLTP one. ( https://www.freelists.org/post/oracle-l/Snowflake-on-Oracle,8)  

I understand that people in this forum have rich database experience in one of the best rdbms in the world i.e. Oracle. And thus wanted to ask, have you been into situations in which somebody in your organization asks to evaluate or choose another of the cloud native databases(may be OLTP or OLAP) apart from Oracle. Say for example I have seen situations in which companies are moving existing applications or building new applications on to the AWS cloud so they don't want to be bound to Oracle rather trying to utilize some databases which is native to that cloud(say RDS , Aurora, redshift) or may third party databases which are available in multiple clouds(Yugabyte, Cockroach, Snowflake etc ). And we know Oracle is not available in Aurora and RDS has some max storage limitation for oracle and additionally Oracle exadata is not available in AWS too.  

So my question is,

1)Considering databases are something going to stay long and not frequently changeable, how do you evaluate/choose the best goto databases for OLTP(for 100's terabyte scale) and OLAP(for petabytes scale) applications for your organizations(say financial industry where ACID matters) at the current time when there are many databases in the market and also claiming to be the best in the field?

2)Many things come to mind, like we should see/test the isolation level, ACID and CAP etc. But is there a quick guide/workflow available which provides these accurately or we need to test these all by installing the database one by one manually?  

Regards

Pap          

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Apr 23 2023 - 15:05:49 CEST

Original text of this message