149 lines
6.8 KiB
HTML
149 lines
6.8 KiB
HTML
<!DOCTYPE html><html lang="zh-CN"><head><meta charset="utf-8"><meta name="X-UA-Compatible" content="IE=edge"><title> MarkDown</title><meta name="description" content="A Blog Powered By Hexo"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="short icon" href="/favicon.png"><link rel="stylesheet" href="/css/apollo.css"><link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600" type="text/css"><style><!-- hexo-inject:begin --><!-- hexo-inject:end -->mjx-container[jax="SVG"] {
|
||
direction: ltr;
|
||
}
|
||
|
||
mjx-container[jax="SVG"] > svg {
|
||
overflow: visible;
|
||
}
|
||
|
||
mjx-container[jax="SVG"] > svg a {
|
||
fill: blue;
|
||
stroke: blue;
|
||
}
|
||
|
||
mjx-container[jax="SVG"][display="true"] {
|
||
display: block;
|
||
text-align: center;
|
||
margin: 1em 0;
|
||
}
|
||
|
||
mjx-container[jax="SVG"][justify="left"] {
|
||
text-align: left;
|
||
}
|
||
|
||
mjx-container[jax="SVG"][justify="right"] {
|
||
text-align: right;
|
||
}
|
||
|
||
g[data-mml-node="merror"] > g {
|
||
fill: red;
|
||
stroke: red;
|
||
}
|
||
|
||
g[data-mml-node="merror"] > rect[data-background] {
|
||
fill: yellow;
|
||
stroke: none;
|
||
}
|
||
|
||
g[data-mml-node="mtable"] > line[data-line] {
|
||
stroke-width: 70px;
|
||
fill: none;
|
||
}
|
||
|
||
g[data-mml-node="mtable"] > rect[data-frame] {
|
||
stroke-width: 70px;
|
||
fill: none;
|
||
}
|
||
|
||
g[data-mml-node="mtable"] > .mjx-dashed {
|
||
stroke-dasharray: 140;
|
||
}
|
||
|
||
g[data-mml-node="mtable"] > .mjx-dotted {
|
||
stroke-linecap: round;
|
||
stroke-dasharray: 0,140;
|
||
}
|
||
|
||
g[data-mml-node="mtable"] > svg {
|
||
overflow: visible;
|
||
}
|
||
|
||
[jax="SVG"] mjx-tool {
|
||
display: inline-block;
|
||
position: relative;
|
||
width: 0;
|
||
height: 0;
|
||
}
|
||
|
||
[jax="SVG"] mjx-tool > mjx-tip {
|
||
position: absolute;
|
||
top: 0;
|
||
left: 0;
|
||
}
|
||
|
||
mjx-tool > mjx-tip {
|
||
display: inline-block;
|
||
padding: .2em;
|
||
border: 1px solid #888;
|
||
font-size: 70%;
|
||
background-color: #F8F8F8;
|
||
color: black;
|
||
box-shadow: 2px 2px 5px #AAAAAA;
|
||
}
|
||
|
||
g[data-mml-node="maction"][data-toggle] {
|
||
cursor: pointer;
|
||
}
|
||
|
||
mjx-status {
|
||
display: block;
|
||
position: fixed;
|
||
left: 1em;
|
||
bottom: 1em;
|
||
min-width: 25%;
|
||
padding: .2em .4em;
|
||
border: 1px solid #888;
|
||
font-size: 90%;
|
||
background-color: #F8F8F8;
|
||
color: black;
|
||
}
|
||
|
||
foreignObject[data-mjx-xml] {
|
||
font-family: initial;
|
||
line-height: normal;
|
||
overflow: visible;
|
||
}
|
||
|
||
.MathJax path {
|
||
stroke-width: 3;
|
||
}
|
||
|
||
mjx-container {
|
||
overflow: auto hidden;
|
||
}
|
||
|
||
mjx-container + br {
|
||
display: none;
|
||
}
|
||
</style><!-- hexo-inject:begin --><!-- hexo-inject:end --></head><body><header><a href="/" class="logo-link"><img src="/logo.png"></a><ul class="nav nav-list"><li class="nav-list-item"><a href="/" target="_self" class="nav-list-link">ALL</a></li><li class="nav-list-item"><a href="/categories/leetcode/" target="_self" class="nav-list-link">LEETCODE</a></li><li class="nav-list-item"><a href="https://bearmiebear.blogspot.com" target="_blank" class="nav-list-link">BEAR</a></li><li class="nav-list-item"><a href="/atom.xml" target="_self" class="nav-list-link">RSS</a></li></ul></header><section class="container"><ul class="home post-list"><li class="post-list-item"><article class="post-block"><h2 class="post-title"><a href="/2019/11/14/AWS-KMS/" class="post-title-link">AWS KMS</a></h2><div class="post-meta"><div class="post-time">2019年11月14日</div></div><div class="post-content"><p>We used to keep private credentials on production servers without any protection or encryption. Well, luckily we don’t have any leak but this practice is not recommended for both security and easy of use reasons.</p>
|
||
<!-- hexo-inject:begin --><!-- hexo-inject:end --><p>Since AWS finally provides <a href="https://www.amazonaws.cn/kms/" target="_blank" rel="noopener">KMS(Key Management Service)</a> in our local region, we try to encrypt every private credentials by KMS and store them on S3.</p>
|
||
<p><em>TBD</em></p>
|
||
</div></article></li><li class="post-list-item"><article class="post-block"><h2 class="post-title"><a href="/2019/03/12/Postgresql-Partitioning/" class="post-title-link">Postgresql Partitioning</a></h2><div class="post-meta"><div class="post-time">2019年3月12日</div></div><div class="post-content"><p><code>Partitioning</code> refers to splitting what is logically one large table inot smaller physical pieces.</p>
|
||
<p>Currently, PostgreSQL supports partitioning via table <a href="https://www.postgresql.org/docs/9.6/ddl-inherit.html" target="_blank" rel="noopener">inheritance</a>. Each partition must be created as a child table of a single parent table. <strong>The parent table itself is normally empty</strong>; It exists just to represent the entire data set.</p>
|
||
<p>There are two forms of partitioning can be implemented in PostgreSQL:</p>
|
||
<ul>
|
||
<li><p>Range Partitioning</p>
|
||
<p> The table is partitioning into “range” defined by a key column or a set of columns, with no overlap between the ranges of values assigned to different partitions. eg. partition by date ranges or by identifiers.</p>
|
||
</li>
|
||
<li><p>List Partitioning</p>
|
||
<p> The table is partitioned by explicitly listing which key values appear in each partition.</p>
|
||
</li>
|
||
</ul>
|
||
<h3 id="Implementing_Partitioning"><a href="#Implementing_Partitioning" class="headerlink" title="Implementing Partitioning"></a>Implementing Partitioning</h3><ol>
|
||
<li><p>Create the “master” / “parent” table, from which all the partitions will inherit.</p>
|
||
<p> This table will not contain any data. Do not define any check on this table, unless you intend them to be applied equally to all partitions. There is no point in defining any indexes or unique constraints on it either.</p>
|
||
</li>
|
||
<li><p>Create “child” tables that each inherit form the master table. Normally, these tables will not add any columns to the set inherited from the master. </p>
|
||
</li>
|
||
<li><p>Add table constraints to the partition tables to define the allowed key values in each partitions. </p>
|
||
<p> Ensure that the constraints guarantee that there is no overlap between the key values premitted in different partitions. And there is no difference in syntax between range and list partitioning. </p>
|
||
</li>
|
||
<li><p>Create indexes on column(s) for each partitions.</p>
|
||
</li>
|
||
<li><p>Optionally, define a trigger or rule to redirect data inserted into the master table to the appropriate partition.</p>
|
||
</li>
|
||
<li><p>Ensure hte <a href="https://www.postgresql.org/docs/9.6/runtime-config-query.html#GUC-CONSTRAINT-EXCLUSION" target="_blank" rel="noopener">constraint_exclusion</a> configuration parameter is not disabled in <code>postgresql.conf</code>. If it is, queries will not be optimized as desired.</p>
|
||
</li>
|
||
</ol>
|
||
<h3 id="Trigger"><a href="#Trigger" class="headerlink" title="Trigger"></a>Trigger</h3><p>As we are creating new table and hopping data insered to right partition, a trigger function and a trigger are needed.</p>
|
||
</div></article></li></ul></section><footer><div class="paginator"></div></footer><script src="https://cdn.bootcss.com/mathjax/2.5.3/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script><!-- hexo-inject:begin --><!-- hexo-inject:end --></body></html> |