Distributed database computing fundamentally entails the management of a database across multiple physical locations, whether within a single entity or spanned across multiple ones. This notion is principally crucial in the context of increasing data volume and the need for high availability, scalability, and reliability. When approached from the perspective of Relational Database Management Systems (RDBMS), the subject generates varied opinions regarding feasibility, performance, and complexity.

RDBMS are based on a model established by E.F. Codd, which uses a table-based structure where data is related in terms of rows and columns. The traditional RDBMS was designed to operate within a single system or server, which constrains performance, failover capabilities, and geographic distribution. However, with advancements in software architectures and distributed computing technologies, traditional RDBMS have evolved to support distributed database environments to some extent.

Concept of Distributed Databases in RDBMS

Horizontal Partitioning (Sharding): One common approach in distributed RDBMS is sharding, where data is horizontally split across multiple nodes or geographies, such that each node acts independently with partial data. For instance, customer data can be partitioned based on geographic regions to local database instances. This reduces the load on individual servers and enhances response times by enabling queries to run in parallel across the nodes.

Synchronization and Replication: The replication and synchronization methods allow RDBMS to manage distributed data consistency and integrity. Replication can be synchronous, where transactions must commit simultaneously across all nodes, or asynchronous, where updates are propagated in a delayed manner to other nodes. These techniques, however, introduce complexity in maintaining data consistency and handling conflict resolution.

Two-phase Commit Protocol: To ensure integrity and consistency of transactions across multiple databases, distributed RDBMS often employ the two-phase commit protocol. This protocol first prepares all nodes to commit by locking the resources necessary for the transaction, ensures there are no conflicts that prevent any node from committing, and then commits the transaction at all nodes linearly.

Challenges and Limitations

While advancements have been made, distributed RDBMS still struggles with several issues:

• Scalability: Despite solutions like sharding, scaling out (adding more nodes) usually affects performance due to increased overhead of coordination and data consistency maintenance across nodes.
• Complexity: Managing a distributed RDBMS involves complex infrastructure and software setups, which can be a barrier from both technical and operational perspectives.
• CAP Theorem: According to Brewer's CAP theorem, a distributed system can offer only two of the following three: Consistency, Availability, and Partition tolerance. This presents inherent compromises in system design and performance in distributed RDBMS setups.

Comparing with NoSQL Databases

In contrast, NoSQL databases like MongoDB, Cassandra, and CouchDB were specifically designed to handle large-scale distributed data architectures more flexibly and effectively than traditional RDBMS. They typically offer better scalability and are more adept at handling large volumes of structured, semi-structured, and unstructured data across distributed networks.

Conclusion

While RDBMS have historically not been designed with distribution in mind, modern advancements and techniques have enabled them to be adapted to distributed environments with a reasonable degree of success. However, the complexity, operational overhead, and inherent limitations in scaling and performance mean that they might not always be the best solution for highly distributed database needs. Below is a table summarizing some key aspects:

In conclusion, while it is indeed possible to operate distributed databases within the RDBMS paradigm, organizations must carefully consider the inherent trade-offs and complexities involved, particularly when scalability and ease of management are paramount.