Hello everybody! Hello everyone! After so many mails, comments, fan club letters and carrier pigeons, I’m back, I’m here, I’m present and I keep my promise. This week, in #BestInMicro, I bring the long awaited and eagerly awaited second part of the Fences article.
Quoting myself, today we will be analyzing ‘in detail to know if it is really convenient or not to use the functionality, and logically to understand its impact’.
Now that we know what it is for and what functionalities it can have, it remains to understand the most negative points of this functionality, and I leave it to each person to analyze whether it is convenient or not to use it.
Let’s make a brief summary, in case you feel a bit lazy to read the previous article:
Fencing technology is a technique used to improve data fetching performance by distributing the workload across multiple servers. This technique allows the database to scale horizontally, which in turn improves capacity and availability. However, like any technology, there are pros and cons to its use and there are certain scenarios in which it is more appropriate to use it.
Let’s begin with the upside. By implementing Fencing, we achieve:
Improve performance: the distribution of the workload across multiple servers allows an improvement in the performance of the database, especially when there is a large amount of read/write traffic and we need different users, groups of users and/or projects that require priority, without having a direct impact on the rest (beyond removing ‘potential’ capacity).
Horizontal scalability: this sounds logical, and to be honest, it is not directly linked to fencing. But it counts in the end, because database capacity can be easily increased by adding more servers, which improves availability and capacity.
Reduced query response time: by distributing the workload, query response times can be reduced, especially in highly transactional environments.
As everything that goes up comes down…
As all light generates shadow…
Here I tell you the dark side to keep in mind if you decide to implement fencing.
Increased complexity: the implementation of fencing requires increased complexity in the configuration of the database and environment, which can increase implementation time and costs. Relatively detailed control is needed to ensure that whoever is to have ‘exclusive access’ serves them accordingly and does not create a bottleneck in the capacity of the other server(s).
Higher cost: implementing multiple servers for fencing can be costly, especially if the requirements of each group are not properly assessed, or if more capacity is required, perhaps due to poor design in the reporting phase.
Requires careful planning: workload distribution requires careful planning to ensure that performance and scalability requirements are met.
In summary, implementing fencing can be difficult to configure and manage, increases system complexity, can cause performance problems in some cases, limit end-users’ flexibility by restricting their access to certain data, and can even be difficult to audit and track who has access to what information.
I believe there are certain specific scenarios where Fencing can be advantageous rather than using a clustered environment, and there is also the possibility of using user mapping and prioritization in the database instances.
The implementation of a traditional cluster is more suitable in cases where high availability and fault tolerance are required (not least, Fences comes at a great cost by sacrificing a high availability server for a dedicated processing server), but not necessarily to improve performance.
So, it falls into each situation and what capabilities you must define whether to implement Fences.
Anyway, this is my little bit of sand to give you all the good and bad about how to implement Fences. Now, it’s up to you to evaluate it and decide, and let me know what you think! See you next time!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
