Database Architecture, Central and/vs Localized Se

2019-09-16 20:04发布

问题:

The system in question is for a company with multiple locations. Unreliable internet speeds/availability at some locations have led to the path of a local server at each location off of which a location and a central server.

The role of the local server is for each location to be able to run no matter if it is connected to the outside world or not, or to eliminate high latency if the the connection speed is less than optimal.

The role of the central server is two-fold:

  1. Configuration, policy, user, etc, management. For example, new products, price changes, promotions, user changes, etc, are done on the central server and then distributed to the local servers so they have the most up to date info.
  2. Centralize all data created at each location to run reports, analytics and warehouse data.

The question of how much data to keep on the local server is debatable. For example some processes are dependent upon not just that one location, like customer loyalty, so a query must be run to the central server to check user activity and determine incentives. On the other hand, active customer base should be within the scope of the local servers data.

I lack experience in these types of distributed systems. My question is what database should we use that will facilitate this type of setup, hopefully incorporating the functionality to work automatically without much coding needed to achieve the data syncs to/from central server.

回答1:

Master-Slave Replication:

In this type of replication one server (the master) accepts writes and will replicate the changes to read replicas(slaves)

Characteristics

  • Asynchronous
  • Read Scalability
  • Master is a point of failure for all the nodes (SPOF)

Master-Master:

In this setup all the database servers accepts read and writes and synchronize together.

Characteristics

  • Synchronous(hopefully)
  • Read and Write Scalability
  • Performance is worse than Master-Slave
  • No SPOF

Master-Master is harder to setup and maintain. Possibility of id collisions.

Any Popular Database Server these days supports the features above.