After connecting to the DDS replica set instance, users can see 3 system libraries: local, config, and admin. After connecting to the DDS cluster version instance, you can see the config and admin system libraries.
It is not recommended for users to directly create tables in the system library, and the reasons are explained below.
The local library does not participate in master-slave replication. The local libraries of each node in the replica set are independent of each other, and modifications to the local library of the master node will not be replicated to the slave node via oplog. Therefore, if users create tables and write data in the local library, there will be data security risks, and the read write separation feature of DDS cannot be utilized.
The write performance of the admin library is limited. For some special reasons, all tables under the admin library need to acquire DB write locks (non-intentional write locks) first when performing write operations. As a result, the write operations under the admin library are all performed serially and mutually exclusive with the read operations, so the performance is low and it is not suitable for storing business data.
It is not conducive to the assignment of user permissions. If you use a system library to store data, system tables may be exposed when assigning permissions to ordinary users, causing additional system risks.
There are serious risks in operations such as deleting tables and libraries. When you use dropCollection or dropDatabase to delete a library, the risk of misoperation increases.