When it comes to dealing with Oracle Database architecture, the components include, first, your shards. The shards —each an independent Oracle Database —depend on the partitioning. You decide on a partition key and how the actual data is divided across those shards.
Then you have a shard catalog. Shard catalog as it what the name says is a catalog of your sharding configuration is aware of all of the components in the shard and any kind of replicated object, that master object exists in the shard catalog to be maintained from there.
It also manages global queries, as we will see later, acting as a proxy. So queries can be distributed across multiple shards. The data from the shards is returned to the catalog, grouped, and then sent back to the client.
Now, this short catalog is essentially another version of an Oracle Database created independently of the shards that store the actual data, and its job is to maintain this catalog functionality. Finally, the shard director is like another form of a global service manager.
So it understands sharding by accessing the catalog and knowing where everything exists. The client connection pool will hit the shard director. In general, communication: if it’s being distributed to the shard catalog to be proxied, or if the key is available, the director can send the query directly to the shard where the data exists. So the shard can then respond directly to the client. All connection pool and global administration components are managed by the shard director.
Looking at it a little bit more in detail. The shard director, as we said, is like a global service manager. It acts as a regional listener, where all connection requests come to the shard director and are then distributed based on the connection type.
Now the director understands the topology and maintains a complete understanding of how the data maps to the shards. As we mentioned, based on the shard key, if requests are specified by that key, the connection request can be routed directly to the appropriate shard where the data resides for a direct response.
Next, the shard catalog, as we said, is another Oracle Database created specifically to store the topology of the sharded database. And have all of the centralized information metadata about your sharded database. It also, as we mentioned, acts as a proxy.
If a client request comes in without a short key, it will go to the catalog. It can be distributed to all of the shards. So the shards that you actually have the data can respond, but the data can then be combined and sent back to the client. As we said, it also creates the master copy of all duplicate tables created in the shard database.
Now, the shards. Each shard, as we said, is basically a database. The data is horizontally partitioned across these shards. So this physical database is called the shard. And depending on the topology of your sharding, there could be user sharding, for example, where multiple keys are in a single shard, or it could be a system sharding that, based on the hash value, distributes single or multiple data components across each shard.
Now, this is completely transparent to the application. So, as far as the application is concerned, this is a single database, and the response to everything they do is generally just a single database interaction.
However, for administrators, each shard is a separate database. Each shard can be managed independently and can have its own standby and other components, which are then configured for high availability and data operations management.
Recent Comments