https://rss3.bio/0x8fC645e6a176F07395B8f44196d1443772FE9d57
rojeckPrinciples of composition/aggregation reuse
The Composite/Aggregate Reuse Principle (CARP) is generally called the Composite Reuse Principle (CRP), which is defined as: try to use composite/aggregate instead of inheriting to achieve the purpose of reuse. The principle of composition/aggregation reuse is to use some existing objects in a new object to make it a part of the new object; the new object achieves the purpose of reusing existing functions by delegating to these objects held internally. Instead of getting existing functions th...
rojeckSignificance of the Single Responsibility Principle
The single responsibility principle tells us: a class cannot do too many things. In a software system, the more responsibilities a class (a module, or a method) assumes, the lower the possibility of it being reused. A very typical example is the universal class. In fact, we can tell the truth: any conventional MVC project, in extreme cases, can use one class (or even one method) to complete all functions. But doing so will cause serious coupling and even affect the whole body. A class underta...
rojeckHBase design row key design
HBase application scenarios are very extensive; there are a series of articles in front of the community. Everyone can take a look at the community; Zhang Shaohua this article mainly talks about the most important basic knowledge of HBASE, the involvement of rowkey, which is very awesome! Highly recommended!
rojeckPrinciples of composition/aggregation reuse
The Composite/Aggregate Reuse Principle (CARP) is generally called the Composite Reuse Principle (CRP), which is defined as: try to use composite/aggregate instead of inheriting to achieve the purpose of reuse. The principle of composition/aggregation reuse is to use some existing objects in a new object to make it a part of the new object; the new object achieves the purpose of reusing existing functions by delegating to these objects held internally. Instead of getting existing functions th...
rojeckSignificance of the Single Responsibility Principle
The single responsibility principle tells us: a class cannot do too many things. In a software system, the more responsibilities a class (a module, or a method) assumes, the lower the possibility of it being reused. A very typical example is the universal class. In fact, we can tell the truth: any conventional MVC project, in extreme cases, can use one class (or even one method) to complete all functions. But doing so will cause serious coupling and even affect the whole body. A class underta...
rojeckHBase design row key design
HBase application scenarios are very extensive; there are a series of articles in front of the community. Everyone can take a look at the community; Zhang Shaohua this article mainly talks about the most important basic knowledge of HBASE, the involvement of rowkey, which is very awesome! Highly recommended!
https://rss3.bio/0x8fC645e6a176F07395B8f44196d1443772FE9d57
Subscribe to rojeck
Subscribe to rojeck
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
The application of Salting in HBase is to assign a random character to each rowkey prefix, so that the data is scattered in multiple different regions to achieve a balanced load.
If the table region in HBase is distinguished according to the prefix of each letter, let's compare the changes before and after adding salt to the rowkey. First, we give a set of rowkeys before salt:
rk001
rk002
rk003
According to the partition, the above rowkey is in the same region. Below we add salt to the above rowkey:
a-rk001
b-rk002
c-rk003
After the processed rowkey, the data is distributed in 3 regions. In theory, the throughput at this time is 3 times that before the processing. Since the prefix is random, it takes more time to search lexicographically when reading these data (may initiate a request to each region server), so salt increases the throughput of write operations, but it increases the read operation Overhead.
The application of Salting in HBase is to assign a random character to each rowkey prefix, so that the data is scattered in multiple different regions to achieve a balanced load.
If the table region in HBase is distinguished according to the prefix of each letter, let's compare the changes before and after adding salt to the rowkey. First, we give a set of rowkeys before salt:
rk001
rk002
rk003
According to the partition, the above rowkey is in the same region. Below we add salt to the above rowkey:
a-rk001
b-rk002
c-rk003
After the processed rowkey, the data is distributed in 3 regions. In theory, the throughput at this time is 3 times that before the processing. Since the prefix is random, it takes more time to search lexicographically when reading these data (may initiate a request to each region server), so salt increases the throughput of write operations, but it increases the read operation Overhead.
No activity yet