Many companies have moved from centralized databases to distributed databases, the latter cloud-based services that have significant advantages over the former, older model. However, any new technology within IT raises caution flags as the security concerns are encountered and rectified. The fact is, distributed databases are not new. Companies that have experience and expertise in the field know proper, secure distributed database management, along with the tools you need for strong administration.
This article will look briefly at the distributed model versus the centralized model, the primary types of distributed databases, and security basics.
Centralized vs. Distributed Databases
VirtualMV provides a basic overview of the two general types of database: centralized (or centralized, depending on English version) and distributed:
Centralized databases reside in one place – in other words, all the hardware and other infrastructural elements that run and store the database are under one roof. It’s accessible through a web connection usually. Financial institutions will often use this type of database: Australia and New Zealand Banking Group (ANZ) is one example. It’s conventional and has its limitations, but it is an established standard.
Distributed databases are located in the cloud. In other words, a network of computers in multiple physical locations is used for database storage, processing, and management.
Clearly, the parameters of a database become more complex when the distributed model is used. However, many companies – including Google – have turned to data distribution to improve database redundancy, speed, scalability, and, in some senses, security (specifically, the latter improves by only permitting certain users to access specific sections of the distributed database).
Google, for example, uses a distributed database to gather, hold, and retrieve search information at set intervals (perhaps once a minute or hour rather than moment by moment, although most distributed databases deliver data daily) because searching usually occurs in similar patterns in different areas across the globe.
Whether a database is centralized or distributed, when it’s used, the database is the same in the sense that it’s one singular database. However, what an individual user might be accessing at one particular place is typically not the entire database. Instead, local access leads only to the part of the database applicable to the local area – what matters to that particular branch of the business, such as customers local to the area, which is why global businesses with numerous branches often choose this model. The branch’s section of the database updates the database of the main location – the entire database – usually daily, as described in the Google paragraph above.
Types of Distributed Database
Distributed databases are all designed a bit differently, and you can categorize them in different ways. To get a sense of a few major types of distributed databases, let’s look at the duplicated, partition, and partition + index approaches courtesy of ICT (information and communication technologies) educational site Teach ICT. These categories give us a sense of how distributed databases can be compartmentalized (or not):
- Duplicated – In a duplicated version of a distributed database, the whole database is stored in each of the various branches. That means you have a copy of the database that is fairly up-to-date (depending on how often updates occur) at all the local sites of the business. This solution works well if your database is not big and you are not concerned with scalability.
- Partitioned – You divide the database into pieces, sectioning off what is needed for particular departments or situations. One obvious example in which partitioning makes sense is with local branches because typically, they don’t need everything in the national or international database at hand. Another situation for which partitioning can be used in different applications designated for specific tasks – the customer order application, for example, does not need to contain the same information as the inventory application (and vice versa; see the second paragraph in “distributed databases” section above).
- Partitioned + index – A further evolution of the partitioned database keeps an index of database data stored in other locations. The indexes are updated typically every day (at a low-traffic hour) through a batch, in the same manner that the partitioned ones update the main database. In other words, the system is a compromise between the two other approaches.
Potential Security Concerns of the Distributed Database
As Oracle reminds us, you can set up the same type of security protections for your distributed database as exist on a centralized one – obviously engineered and/or configured in a way that fit the specifications of the distributed model:
- passwords for every user, with specific permissions for each user type
- additional software to cross-check user and type authentication
- cryptographic technology to secure data packets between servers and when communicating with users.
A distributed database can be extremely secure. It’s just a matter of appreciating where new vulnerabilities are created by changing the database model. Again, database partitioning allows you to segment your users into various categories of database access, which is a definite security benefit.
Distributed databases are increasingly popular for a host of reasons. The primary one is that they significantly decrease strain on the network, specifically when a partitioned variety is deployed. The fact that Google uses one to organize its search data is a sign of how reliable and, therefore, trusted this database management model has become.
Check back for more updates from Atlantic.Net, or learn more about our VPS hosting options.
