我遇到过多个指南，指出 AWS RDS 实例不应配置为可公开访问，因为这是一个主要的安全风险。示例：RDS 公开访问 - RDS 最佳实践

如果RDS实例配置了足够强且唯一的密码，几乎不可能被暴力破解，那么它仍然存在安全风险吗？即使实例可以公开访问，强大且唯一的密码难道不会使实例相当安全吗？

我试图更好地理解如果多个线程同时使用相同的JDBC连接尝试执行不同的sql查询将会发生什么.

• 结果是否在功能上正确？

• 性能影响是什么？

• 线程A是否必须等待线程B完全完成其查询？

• 或者线程A能够在线程B发送查询后立即发送其查询,之后数据库将并行执行两个查询？

我看到Apache DBCP使用同步协议来确保从池中删除从池中获取的连接,并使它们不可用,直到它们关闭.这似乎比它需要的更不方便.我正在考虑构建自己的"池",只需创建一个静态的打开连接列表,并以循环方式分发它们.我不介意偶尔的性能下降,并且在每次使用后不必关闭连接的便利性似乎非常吸引人.这样做有什么不好吗？

两部分问题：

1. Postgresql在行内或行外存储文本/ varchars的行为是什么？我是否认为默认设置将所有列始终存储在行中，直到达到2kB大小？

2. 我们可以控制上述行为吗？有什么方法可以更改特定列/表的阈值，或者强制特定列始终存储在行外？

我已经阅读了PostGresql Toast文档（http://www.postgresql.org/docs/8.3/static/storage-toast.html），但是我看不到任何更改阈值的选项（默认值似乎是2kB -for-row）或强制列始终存储行外（EXTERNAL仅允许它，但不强制执行）。

我已经找到了说明如何在SQL Server上执行此操作的文档（https://msdn.microsoft.com/zh-cn/library/ms173530.aspx），但没有看到与PostGresql类似的内容。

如果有人对我的动机感兴趣，那么我有一个表，该表包含短一致性列（ID，时间戳等），一个列为varchar（200）和一个列为text / varchar（max）的表，长度非常大。我目前将两个varchars存储在单独的表中，只是为了允许在短一致性列上进行有效的存储/查找/扫描。

但是，这很痛苦，因为我经常需要进行联接才能读取所有数据。我真的很想将上述所有字段存储在同一张表中，并告诉Postgresql始终强制将2个VARCHARs行外存储。

当我运行时mvn dependency:tree -Dverbose，我看到以下内容：

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ reddit_digest ---
...
[INFO] +- com.rajivprab:sava:jar:1.2.0:compile
[INFO] |  +- com.rajivprab:cava:jar:1.5.0:compile
[INFO] |  |  +- org.apache.commons:commons-lang3:jar:3.5:compile
...
[INFO] |  |  \- com.google.guava:guava:jar:20.0:compile

这是非常令人惊讶的，因为cava 工件指定了 guava version-22。

如果我继续添加 guava version-22 作为对我的项目的直接依赖项，然后mvn dependency:tree -Dverbose再次运行，我现在会看到以下内容，其中 cava 的 guava 版本神奇地固定为应有的值 (22)。

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ reddit_digest ---
...
[INFO] +- com.google.guava:guava:jar:22.0:compile
[INFO] +- com.rajivprab:sava:jar:1.2.0:compile
[INFO] |  +- com.rajivprab:cava:jar:1.5.0:compile
[INFO] |  |  +- org.apache.commons:commons-lang3:jar:3.5:compile
...
[INFO] |  |  \- (com.google.guava:guava:jar:22.0:compile - …

我天真地假设，如果我启用了缓存控制，并且客户端使用不同的标头参数值发出了 2 个不同的请求，则浏览器/服务器将独立地服务这两个请求，而无需任何缓存。

我痛苦地发现这实际上不是真的。即使请求标头的参数值发生变化，第一个响应仍然会被缓存并为第二个请求提供服务。

是否有关于哪些构成“高速缓存命中”以及哪些构成“高速缓存未命中”的高速缓存控制行为的明确列表？

我目前可以想到的一些不同因素：

1. 查询参数键
2. 查询参数值
3. 表单参数键
4. 表单参数值
5. 标头参数键
6. 标头参数值

根据我的经验，为了确定请求是否缓存命中，数字 6 肯定会被忽略。

根据我所做的一些研究，在确定某些内容是否缓存命中时似乎会评估因素 1 和 2。

其他人呢？

我只是注意到在类的静态初始化期间创建和启动多个线程会导致死锁，并且没有任何线程启动。如果我在类初始化后动态运行相同的代码，这个问题就会消失。这是预期的行为吗？

简短的示例程序：

package com.my.pkg;

import com.google.common.truth.Truth;
import org.junit.Test;

import java.util.Collection;
import java.util.concurrent.Callable;
import java.util.concurrent.Future;
import java.util.concurrent.FutureTask;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public class MyClass {
    private static final Collection<Integer> NUMS = getNums();

    @Test
    public void fork_doesNotWorkDuringClassInit() {
        // This works if you also delete NUMS from above: 
        // Truth.assertThat(getNums()).containsExactly(0, 1, 2, 3, 4);
        Truth.assertThat(NUMS).containsExactly(0, 1, 2, 3, 4);
    }

    private static Collection<Integer> getNums() {
        return IntStream.range(0, 5)
                        .mapToObj(i -> fork(() -> i))
                        .map(MyClass::get)
                        .collect(Collectors.toList());
    }

    public static <T> FutureTask<T> fork(Callable<T> callable) …

我正在努力更好地理解git-rebase背后的魔力.今天我对以下行为感到非常惊喜,我没想到.

TLDR:我重新设置了一个共享分支,导致所有提交sha1都发生了变化.尽管如此,派生分支能够准确地识别出其原始提交被"别名"为具有不同sha1的新提交.rebase并没有造成任何混乱.

细节

拿一个主分支: M1

将它分支到branch-X,添加一些额外的提交:M1-A1-B1-C1.记下git-log输出.

将branch-X分支到branch-Y,添加了一个额外的提交:M1-A1-B1-C1-D1.记下git-log输出.

将新提交添加到主分支的提示: M1-M2

将branch-X重新引导到更新后的master : M1-M2-A2-B2-C2. 请注意,A2-B2-C2都具有与A1-B1-C1相同的消息,内容和作者日期.但是,它们具有完全不同的sha1值以及提交日期.根据这篇文章,SHA1不同的原因是因为提交的父级已经改变.

将branch-Y重新引导到更新的分支-X上.结果:M1-M2-A2-B2-C2-D2.

值得注意的是,仅应用D1提交(并且变为D2).分支-Y中的A1-B1-C1提交被git-rebase完全忽略.您可以在输出日志中看到这一点.

这很棒,但git-rebase如何知道忽略A1-B1-C1？git-rebase如何知道A2-B2-C2与A1-B1-C1相同,因此可以安全地忽略？我一直认为git使用sha1标识符跟踪提交,但是尽管上面的提交有不同的sha1s,git仍然知道它们是链接在一起的.它是如何做到的？鉴于上述行为,何时修改共享分支真的很危险？

我目前正在设计一个应用程序,用户可以在其中创建/加入群组,然后在群组中发布内容.我试图弄清楚如何最好地将这些内容存储在RDBMS中.

选项1:为所有用户内容创建单个表.此表中的一列将是groupID,指定发布内容的组.使用groupID创建索引,以便快速搜索特定组中的内容.所有内容读/写都将触及此单个表.

选项2:每当用户创建新组时,我们动态创建一个新表.像group_content_ {groupName}这样的东西.所有内容读/写都将路由到特定于组的动态创建的表.

方案1的优点:

1. 使用单个简单查询在单个表上操作,可以更轻松地跨多个组搜索内容.
2. 构建简单的跨表查询更容易,因为内容表是静态的并且定义良好.
3. 实现模式更改和更改索引/触发器等更容易,因为只有一个表可以维护.

方案2的优点:

1. 所有读写操作都将分布在多个表中,从而避免了大量流量冲击单个表所导致的任何瓶颈(尽管如此,所有这些表仍然在一个数据库中)
2. 每个表的大小都会小得多,从而可以更快地查找,更快的模式更改,更快的索引等
3. 如果我们希望将来对数据库进行分片,那么如果所有数据已经​​在不同的表中"分片",则转换会更容易.

从性能/开发/维护的角度来看,上述两个选项之间的一般建议是什么？