Skip to Main Content
  • Questions
  • Oracle's JSON implementation compared to Mongo

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, John.

Asked: October 29, 2024 - 2:22 pm UTC

Last updated: November 01, 2024 - 5:41 am UTC

Version: 23

Viewed 100+ times

You Asked

Greetings,

I recently heard that Oracle 23 will support JSON! I am excited about this since I have been taken away from supporting Oracle for the past three years to work on Mongo.

As I have been working with Mongo, I’ve realized a few big weaknesses over RDBMS design. I wonder if Oracle's JSON implementation avoids these weaknesses:

1.) Storage overhead from repeating field names in each document.
a. Let's say I have a collection that will contain 1000 fields. In this collection we will have 1 billion documents. Each document will be required to add a value for each of the 1000 fields. I calculated the number of total characters used for the 1000 field names to be 10,000 characters. Does Oracle save the field names for the 1000 fields in each document. That will result in 10,000 characters times a billion documents = 10 Trillion characters stored! In relational database tables, only 10,000 characters would be stored for the table since they only store the field names in the table definition.
b. Do you know if Oracle’s JSON implementation won’t store the repeating field names in each document of the same collection? There are cases where we don’t need the “flexible schema” option. We want all documents to have the same fields and set data types.

2.) Mongo has a two replicaset requirement for each Mongo primary server instance. Is Oracle going to require the same, which is to have two standby database servers for each primary server?

3.) Mongo highly recommends that we have enough memory to store the whole index and collection working set in memory. The weakness here is that Mongo licensing is based on memory and Mongo's decision to store the field names per document significantly bloats memory with useless information. Will Oracle continue to license based off of CPU for JSON implementations?

Thanks,

John

and Chris said...

The JSON data type was added in 21c :)

1. This data type uses the OSON format which does deduplicate attribute names:

Reduced storage: Medium to large sized JSON documents often contain nested object array structures and/or recursive structures. In those documents, the field names may be repeatedly stored many times in JSON text. For example, In above Figure, the field “name” is repeated in each element of the array. OSON will only store each distinct field name once using a dictionary encoding to shrink larger JSON documents.

https://blogs.oracle.com/database/post/autonomous-json-database-under-the-covers-oson-format

You can benefit from this format in 19c with:

create table t ( 
  jdata blob 
    check ( jdata is json format oson ) 
);


2. No. It's a good idea to have standby servers, but they are not required for Oracle Database.

3. As far as I know Oracle Database licensing will continue to be CPU-based.

Rating

  (1 rating)

Comments

Wow!

John Cantu, October 31, 2024 - 3:24 pm UTC

Wow, Chris. That article was just what I was looking for! Thank you.

It seems that Oracle engineers really understood the weaknesses of JSON and figured out ways to avoid it!

I agree that standby databases are important; however, if Mongo charges each license based the number of 256 RAM chunks ( <= 256 = 1 license; 257-512 = 2 licenses, etc.) , and they highly recommend adding two standby databases. That will result with a minimum of three additional Mongo licenses for every shard that is added when horizontal scaling is needed, not just one server like most people that aren't experienced with sharding would think.


Connor McDonald
November 01, 2024 - 5:41 am UTC

People are generally surprised when they *genuinely* compare the price of Oracle with other offerings. We often come up the most cost effective

More to Explore

CLOB/BLOB/etc

Complete documentation on Securefiles and Large Objects here