Facebook 经常使用数据驱动的分析方法来做决策。在过去的几年，用户和产品的增长已经需要我们的分析工程师一次查询就要操作数十 TB 大小的数据集。我们的一些批量分析执行在古老的 Hive 平台（ Apache Hive 由 Facebook 贡献于 2009 年）和 Corona 上——这是我们定制的 MapReduce 实现。Facebook 还不断增加其对 Presto 的用量，用于对几个包括 Hive 在内的内部数据存储的 ANSI-SQL 查询。我们也支持其他分析类型，比如 图数据库处理 （ graph processing ） 和机器学习（Apache Giraph）和流（例如：Puma、Swift 和 Stylus）。

同时 Facebook 的各种产品涵盖了广泛的分析领域，我们与开源社区不断保持沟通，以便共享我们的经验并从其他人那里学习。Apache Spark 于 2009 年在加州大学伯克利分校的 AMPLab 由 Matei Zaharia 发起，后来在2013 年贡献给 Apache。它是目前增长最快的数据处理平台之一，由于它能支持流、批量、命令式（RDD）、声明式（SQL）、图数据库和机器学习等用例，而且所有这些都内置在相同的 API 和底层计算引擎中。Spark 可以有效地利用更大量级的内存，优化整个 流水线 （ pipeline ） 中的代码，并跨任务重用 JVM 以获得更好的性能。最近我们感觉 Spark 已经成熟，我们可以在一些批量处理用例方面把它与 Hive 相比较。在这篇文章其余的部分，我们讲述了在扩展 Spark 来替代我们一个 Hive 工作任务时的所得到经验和学习到的教训。

用例：实体排名的特征准备

Facebook 会以多种方式做实时的 实体 （ entity ） 排名。对于一些在线服务平台，原始特征值是由 Hive 线下生成的，然后将数据加载到实时关联查询系统。我们在几年前建立的基于 Hive 的老式基础设施属于计算资源密集型，且很难维护，因为其流水线被划分成数百个较小的 Hive 任务。为了可以使用更加新的特征数据和提升可管理性，我们拿一个现有的流水线试着将其迁移至 Spark。

以前的 Hive 实现

基于 Hive 的流水线由三个逻辑 阶段 （ stage ） 组成，每个阶段对应由 entity\_id 划分的数百个较小的 Hive 作业，因为在每个阶段运行大型 Hive 作业 （ job ） 不太可靠，并受到每个作业的最大 任务 （ task ） 数量的限制。

这三个逻辑阶段可以总结如下：

1. 过滤出非产品的特征和噪点。
2. 在每个（entity\_id, target\_id）对上进行聚合。
3. 将表格分割成 N 个分片，并通过自定义二进制文件管理每个分片，以生成用于在线查询的自定义索引文件。

基于 Hive 的流水线建立该索引大概要三天完成。它也难于管理，因为该流水线包含上百个分片的作业，使监控也变得困难。同时也没有好的方法来估算流水线进度或计算剩余时间。考虑到 Hive 流水线的上述限制，我们决定建立一个更快、更易于管理的 Spark 流水线。

Spark 实现

全量的调试会很慢，有挑战，而且是资源密集型的。我们从转换基于 Hive 流水线的最资源密集型的第二阶段开始。我们以一个 50GB 的压缩输入例子开始，然后逐渐扩展到 300GB、1TB，然后到 20TB。在每次规模增长时，我们都解决了性能和稳定性问题，但是实验到 20TB 时，我们发现了最大的改善机会。

运行 20TB 的输入时，我们发现，由于大量的任务导致我们生成了太多输出文件（每个大小在 100MB 左右）。在 10 小时的作业运行时中，有三分之一是用在将文件从阶段目录移动到 HDFS 中的最终目录。起初，我们考虑两个方案：要么改善 HDFS 中的批量重命名来支持我们的用例，或者配置 Spark 生成更少的输出文件（这很难，由于在这一步有大量的任务 — 70000 个）。我们退一步来看这个问题，考虑第三种方案。由于我们在流水线的第二步中生成的 tmp\_table2 表是临时的，仅用于存储流水线的中间输出，所以对于 TB 级数据的单一读取作业任务，我们基本上是在压缩、序列化和复制三个副本。相反，我们更进一步：移除两个临时表并整合 Hive 过程的所有三个部分到一个单独的 Spark 作业，读取 60TB 的压缩数据然后对 90TB 的数据执行 重排 （ shuffle ） 和 排序 （ sort ） 。最终的 Spark 作业如下：

对于我们的作业如何规划 Spark？

当然，为如此大的流水线运行一个单独的 Spark 任务，第一次尝试没有成功，甚至是第十次尝试也没有。据我们所知，从 重排 （ shuffle ） 的数据大小来说，这是现实世界最大的 Spark 作业（Databrick 的 PB 级排序是以合成数据来说）。我们对核心 Spark 基础架构和我们的应用程序进行了许多改进和优化使这个作业得以运行。这种努力的优势在于，许多这些改进适用于 Spark 的其他大型作业任务，我们将所有的工作回馈给开源 Apache Spark 项目 - 有关详细信息请参阅 JIRA。下面，我们将重点讲述将实体排名流水线之一部署到生产环境所做的重大改进。

可靠性修复

处理频繁的节点重启

为了可靠地执行长时间运行作业，我们希望系统能够容错并可以从故障中恢复（主要是由于平时的维护或软件错误导致的机器重启所引发的）。虽然 Spark 设计为可以容忍机器重启，但我们发现它在足够强健到可以处理常见故障之前还有各种错误/问题需要解决。

• 使 PipedRDD 稳健的 获取 （ fetch ） 失败（SPARK-13793）：PipedRDD 以前的实现不够强大，无法处理由于节点重启而导致的获取失败，并且只要出现获取失败，该作业就会失败。我们在 PipedRDD 中进行了更改，优雅的处理获取失败，使该作业可以从这种类型的获取失败中恢复。
• 可配置的最大获取失败次数（SPARK-13369）：对于这种长时间运行的作业，由于机器重启而引起的获取失败概率显着增加。在 Spark 中每个阶段的最大允许的获取失败次数是硬编码的，因此，当达到最大数量时该作业将失败。我们做了一个改变，使它是可配置的，并且在这个用例中将其从 4 增长到 20，从而使作业更稳健。
• 减少集群重启混乱：长时间运行作业应该可以在集群重启后存留，所以我们不用等着处理完成。Spark 的可重启的 重排 （ shuffle ） 服务功能可以使我们在节点重启后保留 重排 （ shuffle ） 文件。最重要的是，我们在 Spark 驱动程序中实现了一项功能，可以暂停执行任务调度，所以不会由于集群重启而导致的过多的任务失败，从而导致作业失败。

其他的可靠性修复

• 响应迟钝的驱动程序（SPARK-13279）：在添加任务时，由于 O(N ^ 2) 复杂度的操作，Spark 驱动程序被卡住，导致该作业最终被卡住和死亡。 我们通过删除不必要的 O(N ^ 2) 操作来修复问题。
• 过多的驱动 推测 （ speculation ） ：我们发现，Spark 驱动程序在管理大量任务时花费了大量的时间推测。 在短期内，我们禁止这个作业的推测。在长期，我们正在努力改变 Spark 驱动程序，以减少推测时间。
• 由于大型缓冲区的整数溢出导致的 TimSort 问题（SPARK-13850）：我们发现 Spark 的不安全内存操作有一个漏洞，导致 TimSort 中的内存损坏。 感谢 Databricks 的人解决了这个问题，这使我们能够在大内存缓冲区中运行。
• 调整重排（shuffle）服务来处理大量连接：在重排阶段，我们看到许多执行程序在尝试连接重排服务时超时。 增加 Netty 服务器的线程（spark.shuffle.io.serverThreads）和积压（spark.shuffle.io.backLog）的数量解决了这个问题。
• 修复 Spark 执行程序 OOM（SPARK-13958）（deal maker）：首先在每个主机上打包超过四个 聚合 （ reduce ） 任务是很困难的。Spark 执行程序会内存溢出，因为排序程序（sorter）中存在导致无限增长的指针数组的漏洞。当不再有可用的内存用于指针数组增长时，我们通过强制将数据溢出到磁盘来修复问题。因此，现在我们可以每主机运行 24 个任务，而不会内存溢出。

性能改进

在实施上述可靠性改进后，我们能够可靠地运行 Spark 作业了。基于这一点，我们将精力转向与性能相关的项目，以充分发挥 Spark 的作用。我们使用 Spark 的指标和几个分析器来查找一些性能瓶颈。

我们用来查找性能瓶颈的工具

• Spark UI 指标：Spark UI 可以很好地了解在特定阶段所花费的时间。每个任务的执行时间被分为子阶段，以便更容易地找到作业中的瓶颈。
• Jstack：Spark UI 还在执行程序进程上提供了一个按需分配的 jstack 函数，可用于中查找热点代码。
• Spark 的 Linux Perf / 火焰图 （ Flame Graph ） 支持：尽管上述两个工具非常方便，但它们并不提供同时在数百台机器上运行的作业的 CPU 分析的聚合视图。在每个作业的基础上，我们添加了支持 Perf 分析（通过 libperfagent 的 Java 符号），并可以自定义采样的持续时间/频率。使用我们的内部指标收集框架，将分析样本聚合并显示为整个执行程序的火焰图。

性能优化

• 修复 排序程序 （ sorter ） 中的内存泄漏（SPARK-14363）（30％ 速度提升）：我们发现了一个问题，当任务释放所有内存页时指针数组却未被释放。 因此，大量的内存未被使用，并导致频繁的溢出和执行程序 OOM。 我们现在进行了改变，正确地释放内存，并使大的分类运行更有效。 我们注意到，这一变化后 CPU 改善了 30％。
• Snappy 优化（SPARK-14277）（10％ 速度提升）：有个 JNI 方法（Snappy.ArrayCopy）在每一行被读取/写入时都会被调用。 我们发现了这个问题，Snappy 的行为被改为使用非 JNI 的 System.ArrayCopy 代替。 这一改变节约了大约 10％ 的 CPU。
• 减少重排的写入延迟（SPARK-5581）（高达 50％ 的速度提升）：在 映射 （ map ） 方面，当将重排数据写入磁盘时，映射任务为每个分区打开并关闭相同的文件。 我们做了一个修复，以避免不必要的打开/关闭，对于大量写入重排分区的作业来说，我们观察到高达 50％ 的 CPU 提升。
• 解决由于获取失败导致的重复任务运行问题（SPARK-14649）：当获取失败发生时，Spark 驱动程序会重新提交已运行的任务，导致性能下降。 我们通过避免重新运行运行的任务来解决这个问题，我们看到当获取失败发生时该作业会更加稳定。
• 可配置 PipedRDD 的缓冲区大小（SPARK-14542）（10％ 速度提升）：在使用 PipedRDD 时，我们发现将数据从分类程序传输到管道进程的默认缓冲区的大小太小，我们的作业要花费超过 10％ 的时间复制数据。我们使缓冲区大小可配置，以避免这个瓶颈。
• 缓存索引文件以加速重排获取（SPARK-15074）：我们观察到重排服务经常成为瓶颈， 减少程序 （ reducer ） 花费 10％ 至 15％ 的时间等待获取 映射 （ map ） 数据。通过深入了解问题，我们发现，重排服务为每个重排获取打开/关闭重排索引文件。我们进行了更改以缓存索引信息，以便我们可以避免文件打开/关闭，并重新使用该索引信息以便后续获取。这个变化将总的重排时间减少了 50％。
• 降低重排字节写入指标的更新频率（SPARK-15569）（高达 20％ 的速度提升）：使用 Spark 的 Linux Perf 集成，我们发现大约 20％ 的 CPU 时间正在花费探测和更新写入的重排字节写入指标上。
• 可配置排序程序（sorter）的初始缓冲区大小（SPARK-15958）（高达 5％ 的速度提升）： 排序程序 （ sorter ） 的默认初始缓冲区大小太小（4 KB），我们发现它对于大型工作负载而言非常小 - 所以我们在缓冲区耗尽和内容复制上浪费了大量的时间。我们做了一个更改，使缓冲区大小可配置，并且缓冲区大小为 64 MB，我们可以避免大量的数据复制，使作业的速度提高约 5％。
• 配置任务数量：由于我们的输入大小为 60T，每个 HDFS 块大小为 256M，因此我们为该作业产生了超过 250,000 个任务。尽管我们能够以如此多的任务来运行 Spark 作业，但是我们发现，当任务数量过高时，性能会下降。我们引入了一个配置参数，使 映射 （ map ） 输入大小可配置，因此我们可以通过将输入分割大小设置为 2 GB 来将该数量减少 8 倍。

在所有这些可靠性和性能改进之后，我们很高兴地报告，我们为我们的实体排名系统之一构建和部署了一个更快、更易于管理的流水线，并且我们提供了在 Spark 中运行其他类似作业的能力。

Spark 流水线与 Hive 流水线性能对比

我们使用以下性能指标来比较 Spark 流水线与 Hive 流水线。请注意，这些数字并不是在查询或作业级别的直接比较 Spark 与 Hive ，而是比较使用灵活的计算引擎（例如 Spark）构建优化的流水线，而不是比较仅在查询/作业级别（如 Hive）操作的计算引擎。

CPU 时间：这是从系统角度看 CPU 使用。例如，你在一个 32 核机器上使用 50% 的 CPU 10 秒运行一个单进程任务，然后你的 CPU 时间应该是 32 * 0.5 * 10 = 160 CPU 秒。

CPU 预留时间：这是从资源管理框架的角度来看 CPU 预留。例如，如果我们保留 32 位机器 10 秒钟来运行作业，则CPU 预留时间为 32 * 10 = 320 CPU 秒。CPU 时间与 CPU 预留时间的比率反映了我们如何在集群上利用预留的CPU 资源。当准确时，与 CPU 时间相比，预留时间在运行相同工作负载时可以更好地比较执行引擎。例如，如果一个进程需要 1 个 CPU 的时间才能运行，但是必须保留 100 个 CPU 秒，则该指标的效率要低于需要 10 个 CPU 秒而仅保留 10 个 CPU 秒来执行相同的工作量的进程。我们还计算内存预留时间，但不包括在这里，因为其数字类似于 CPU 预留时间，因为在同一硬件上运行实验，而在 Spark 和 Hive 的情况下，我们不会将数据缓存在内存中。Spark 有能力在内存中缓存数据，但是由于我们的集群内存限制，我们决定类似与 Hive 一样工作在核心外部。

等待时间：端到端的工作流失时间。

结论和未来工作

Facebook 的性能和可扩展的分析在产品开发中给予了协助。Apache Spark 提供了将各种分析用例统一为单一 API 和高效计算引擎的独特功能。我们挑战了 Spark，来将一个分解成数百个 Hive 作业的流水线替换成一个 Spark 作业。通过一系列的性能和可靠性改进之后，我们可以将 Spark 扩大到处理我们在生产中的实体排名数据处理用例之一。 在这个特殊用例中，我们展示了 Spark 可以可靠地重排和排序 90 TB+ 的中间数据，并在一个单一作业中运行了 25 万个任务。 与旧的基于 Hive 的流水线相比，基于 Spark 的流水线产生了显着的性能改进（4.5-6 倍 CPU，3-4 倍资源预留和大约 5 倍的延迟），并且已经投入使用了几个月。

虽然本文详细介绍了我们 Spark 最具挑战性的用例，越来越多的客户团队已将 Spark 工作负载部署到生产中。 性能 、可维护性和灵活性是继续推动更多用例到 Spark 的优势。 Facebook 很高兴成为 Spark 开源社区的一部分，并将共同开发 Spark 充分发挥其潜力。

via: https://code.facebook.com/posts/1671373793181703/apache-spark-scale-a-60-tb-production-use-case/

作者：Sital Kedia, 王硕杰, Avery Ching 译者：wyangsun 校对：wxy

本文由 LCTT 组织编译，Linux中国 荣誉推出

任何写过比 hello world 复杂一些的程序的人都应该使用过调试器（如果你还没有，那就停下手头的工作先学习一下吧）。但是，尽管这些工具已经得到了广泛的使用，却并没有太多的资源告诉你它们的工作原理以及如何开发，尤其是和其它那些比如编译器等工具链技术相比而言。

此处有一些其它的资源可以参考：

• http://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1
• https://t-a-w.blogspot.co.uk/2007/03/how-to-code-debuggers.html
• https://www.codeproject.com/Articles/43682/Writing-a-basic-Windows-debugger
• http://system.joekain.com/debugger/

我们将会支持以下功能：

• 启动、暂停、继续执行

• 在不同地方设置断点

  • 内存地址
  • 源代码行
  • 函数入口
• 读写寄存器和内存

• 单步执行

  • 指令
  • 进入函数
  • 跳出函数
  • 跳过函数
• 打印当前代码地址
• 打印函数调用栈
• 打印简单变量的值

在最后一部分，我还会大概介绍如何给你的调试器添加下面的功能：

• 远程调试
• 共享库和动态库支持
• 表达式计算
• 多线程调试支持

在本项目中我会将重点放在 C 和 C++，但对于那些将源码编译为机器码并输出标准 DWARE 调试信息的语言也应该能起作用（如果你还不知道这些东西是什么，别担心，马上就会介绍到啦）。另外，我只关注如何将程序运行起来并在大部分情况下能正常工作，为了简便，会避开类似健壮错误处理方面的东西。

系列文章索引

随着后面文章的发布，这些链接会逐渐生效。

1. 准备环境
2. 断点
3. 寄存器和内存
4. Elves 和 dwarves
5. 源码和信号
6. 源码层逐步执行
7. 源码层断点
8. 调用栈
9. 读取变量
10. 之后步骤

LCTT 译注：ELF —— 可执行文件格式 （ Executable and Linkable Format ） ；DWARF（一种广泛使用的调试数据格式，参考 WIKI）。

准备环境

在我们正式开始之前，我们首先要设置环境。在这篇文章中我会依赖两个工具：Linenoise 用于处理命令行输入，libelfin 用于解析调试信息。你也可以使用更传统的 libdwarf 而不是 libelfin，但是界面没有那么友好，另外 libelfin 还提供了基本完整的 DWARF 表达式求值器，当你想读取变量的值时这能帮你节省很多时间。确认你使用的是 libelfin 我的 fbreg 分支，因为它提供 x86 上读取变量的额外支持。

一旦你在系统上安装或者使用你喜欢的编译系统编译好了这些依赖工具，就可以开始啦。我在 CMake 文件中把它们设置为和我其余的代码一起编译。

启动可执行程序

在真正调试任何程序之前，我们需要启动被调试的程序。我们会使用经典的 fork/exec 模式。

int main(int argc, char* argv[]) {
    if (argc < 2) {
        std::cerr << "Program name not specified";
        return -1;
    }

    auto prog = argv[1];

    auto pid = fork();
    if (pid == 0) {
        //we're in the child process
        //execute debugee

    }
    else if (pid >= 1)  {
        //we're in the parent process
        //execute debugger
    }

我们调用 fork 把我们的程序分成两个进程。如果我们是在子进程，fork 返回 0，如果我们是在父进程，它会返回子进程的进程 ID。

如果我们是在子进程，我们要用希望调试的程序替换正在执行的程序。

   ptrace(PTRACE_TRACEME, 0, nullptr, nullptr);
   execl(prog.c_str(), prog.c_str(), nullptr);

这里我们第一次遇到了 ptrace，它会在我们编写调试器的时候经常遇到。ptrace 通过读取寄存器、内存、逐步调试等让我们观察和控制另一个进程的执行。其 API 非常简单；你需要给这个简单函数提供一个枚举值指定你想要进行的操作，然后是一些取决于你所提供的值可能会被使用也可能会被忽略的参数。函数原型看起来类似：

long ptrace(enum __ptrace_request request, pid_t pid,
            void *addr, void *data);

request 是我们想对被跟踪进程进行的操作；pid 是被跟踪进程的进程 ID；addr 是一个内存地址，用于在一些调用中指定被跟踪程序的地址；data 是 request 相应的资源。返回值通常是一些错误信息，因此在你实际的代码中你也许应该检查返回值；为了简洁我这里就省略了。你可以查看 man 手册获取更多（关于 ptrace）的信息。

上面代码中我们发送的请求 PTRACE_TRACEME 表示这个进程应该允许父进程跟踪它。所有其它参数都会被忽略，因为 API 设计并不是很重要，哈哈。

下一步，我们会调用 execl，这是很多诸多的 exec 函数格式之一。我们执行指定的程序，通过命令行参数传递它的名称，然后用一个 nullptr 终止列表。如果你愿意，你还可以传递其它执行你的程序所需的参数。

在完成这些后，我们就会和子进程一起结束；在我们结束它之前它会一直执行。

添加调试循环

现在我们已经启动了子进程，我们想要能够和它进行交互。为此，我们会创建一个 debugger 类，循环监听用户输入，然后在我们父进程的 main 函数中启动它。

else if (pid >= 1)  {
    //parent
    debugger dbg{prog, pid};
    dbg.run();
}

class debugger {
public:
    debugger (std::string prog_name, pid_t pid)
        : m_prog_name{std::move(prog_name)}, m_pid{pid} {}

    void run();

private:
    std::string m_prog_name;
    pid_t m_pid;
};

在 run 函数中，我们需要等待，直到子进程完成启动，然后一直从 linenoise 获取输入直到收到 EOF（CTRL+D）。

void debugger::run() {
    int wait_status;
    auto options = 0;
    waitpid(m_pid, &wait_status, options);

    char* line = nullptr;
    while((line = linenoise("minidbg> ")) != nullptr) {
        handle_command(line);
        linenoiseHistoryAdd(line);
        linenoiseFree(line);
    }
}

当被跟踪的进程启动时，会发送一个 SIGTRAP 信号给它，这是一个跟踪或者断点中断。我们可以使用 waitpid 函数等待这个信号发送。

当我们知道进程可以被调试之后，我们监听用户输入。linenoise 函数它自己会用一个窗口显示和处理用户输入。这意味着我们不需要做太多的工作就会有一个支持历史记录和导航命令的命令行。当我们获取到输入时，我们把命令发给我们写的小程序 handle_command，然后我们把这个命令添加到 linenoise 历史并释放资源。

处理输入

我们的命令类似 gdb 以及 lldb 的格式。要继续执行程序，用户需要输入 continue 或 cont 甚至只需 c。如果他们想在一个地址中设置断点，他们会输入 break 0xDEADBEEF，其中 0xDEADBEEF 就是所需地址的 16 进制格式。让我们来增加对这些命令的支持吧。

void debugger::handle_command(const std::string& line) {
    auto args = split(line,' ');
    auto command = args[0];

    if (is_prefix(command, "continue")) {
        continue_execution();
    }
    else {
        std::cerr << "Unknown command\n";
    }
}

split 和 is_prefix 是一对有用的小程序：

std::vector<std::string> split(const std::string &s, char delimiter) {
    std::vector<std::string> out{};
    std::stringstream ss {s};
    std::string item;

    while (std::getline(ss,item,delimiter)) {
        out.push_back(item);
    }

    return out;
}

bool is_prefix(const std::string& s, const std::string& of) {
    if (s.size() > of.size()) return false;
    return std::equal(s.begin(), s.end(), of.begin());
}

我们会把 continue_execution 函数添加到 debuger 类。

void debugger::continue_execution() {
    ptrace(PTRACE_CONT, m_pid, nullptr, nullptr);

    int wait_status;
    auto options = 0;
    waitpid(m_pid, &wait_status, options);
}

现在我们的 continue_execution 函数会用 ptrace 告诉进程继续执行，然后用 waitpid 等待直到收到信号。

总结

现在你应该编译一些 C 或者 C++ 程序，然后用你的调试器运行它们，看它是否能在函数入口暂停、从调试器中继续执行。在下一篇文章中，我们会学习如何让我们的调试器设置断点。如果你遇到了任何问题，在下面的评论框中告诉我吧！

你可以在这里找到该项目的代码。

via: http://blog.tartanllama.xyz/c++/2017/03/21/writing-a-linux-debugger-setup/

作者：Simon Brand 译者：ictlyh 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

介绍

当 LXD 2.0 随着 Ubuntu 16.04 一起发布时，LXD 联网就简单了。要么你可以使用 lxd init 来配置，为你的容器自己提供一个 “lxdbr0” 网桥，要么使用一个已存在的物理接口。

虽然这确实有效，但是有点混乱，因为大部分的桥接配置发生在 Ubuntu 打包的 LXD 之外。那些脚本只能支持一个桥接，并且没有通过 API 暴露，这使得远程配置有点痛苦。

直到 LXD 2.3，LXD 终于发展了自己的网络管理 API ，并有相应的命令行工具。这篇文章试图来简述这些新的功能。

基础联网

在初始情况下，LXD 2.3 没有定义任何网络。lxd init 会为你设置一个，并且默认情况下将所有新的容器连接到它，但是让我们亲手尝试看下究竟发生了些什么。

要创建一个新的带有随机 IPv4 和 IP6 子网，并启用 NAT 的网络，只需要运行：

stgraber@castiana:~$ lxc network create testbr0
Network testbr0 created

你可以如下查看它的配置：

stgraber@castiana:~$ lxc network show testbr0
name: testbr0
config:
 ipv4.address: 10.150.19.1/24
 ipv4.nat: "true"
 ipv6.address: fd42:474b:622d:259d::1/64
 ipv6.nat: "true"
managed: true
type: bridge
usedby: []

如果你不想要那些自动配置的子网，你可以这么做：

stgraber@castiana:~$ lxc network create testbr0 ipv6.address=none ipv4.address=10.0.3.1/24 ipv4.nat=true
Network testbr0 created

那就会这样：

stgraber@castiana:~$ lxc network show testbr0
name: testbr0
config:
 ipv4.address: 10.0.3.1/24
 ipv4.nat: "true"
 ipv6.address: none
managed: true
type: bridge
usedby: []

如果你的容器没有使用它，那么创建的网络对你也没什么用。要将你新创建的网络连接到所有容器，你可以这么做：

stgraber@castiana:~$ lxc network attach-profile testbr0 default eth0

要将一个网络连接到一个已存在的容器中，你可以这么做：

stgraber@castiana:~$ lxc network attach my-container default eth0

现在，假设你已经在机器中安装了 openvswitch，并且要将这个网桥转换成 OVS 网桥，只需更改为正确的驱动：

stgraber@castiana:~$ lxc network set testbr0 bridge.driver openvswitch

如果你想要一次性做一系列修改。lxc network edit 可以让你在编辑器中交互编辑网络配置。

静态租约及端口安全

使用 LXD 管理 DHCP 服务器的一个好处是可以使得管理 DHCP 租约很简单。你所需要的是一个容器特定的网卡设备以及正确的属性设置。

root@yak:~# lxc init ubuntu:16.04 c1
Creating c1
root@yak:~# lxc network attach testbr0 c1 eth0
root@yak:~# lxc config device set c1 eth0 ipv4.address 10.0.3.123
root@yak:~# lxc start c1
root@yak:~# lxc list c1
+------+---------+-------------------+------+------------+-----------+
| NAME |  STATE  |        IPV4       | IPV6 |    TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+------------+-----------+
|  c1  | RUNNING | 10.0.3.123 (eth0) |      | PERSISTENT | 0         |
+------+---------+-------------------+------+------------+-----------+

IPv6 也是相同的方法，但是换成 ipv6.address 属性。

相似地，如果你想要阻止你的容器更改它的 MAC 地址或者为其他 MAC 地址转发流量（比如嵌套），你可以用下面的命令启用端口安全：

root@yak:~# lxc config device set c1 eth0 security.mac_filtering true

DNS

LXD 在网桥上运行 DNS 服务器。除了设置网桥的 DNS 域（ dns.domain 网络属性）之外，还支持 3 种不同的操作模式（dns.mode）：

• managed ：每个容器都会有一条 DNS 记录，匹配它的名字以及已知的 IP 地址。容器无法通过 DHCP 改变这条记录。
• dynamic ：允许容器通过 DHCP 在 DNS 中自行注册。因此，在 DHCP 协商期间容器发送的任何主机名最终都出现在 DNS 中。
• none ： 针对那些没有任何本地 DNS 记录的递归 DNS 服务器。

默认的模式是 managed，并且典型的是最安全以及最方便的，因为它为容器提供了 DNS 记录，但是不允许它们通过 DHCP 发送虚假主机名嗅探其他的记录。

使用隧道

除了这些，LXD 还支持使用 GRE 或者 VXLAN 隧道连接到其他主机。

LXD 网络可以连接任何数量的隧道，从而轻松地创建跨多个主机的网络。这对于开发、测试和演示非常有用，生产环境通常更喜欢使用 VLAN 进行分割。

所以说，你想在主机 “edfu” 上有一个运行 IPv4 和 IPv6 的基础 “testbr0” 网络，并希望在主机 “djanet” 上使用它来生成容器。最简单的方法是使用组播 VXLAN 隧道。这种类型的隧道仅在两个主机位于同一物理段上时才起作用。

root@edfu:~# lxc network create testbr0 tunnel.lan.protocol=vxlan
Network testbr0 created
root@edfu:~# lxc network attach-profile testbr0 default eth0

它在主机 “edfu” 上定义了一个 “testbr0” 桥接，并为其他主机能加入它设置了一个组播 VXLAN。在这个设置中，“edfu” 为这个网络扮演了一个路由器角色，提供 DHCP、DNS 等等，其他主机只是通过隧道转发流量。

root@djanet:~# lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lan.protocol=vxlan
Network testbr0 created
root@djanet:~# lxc network attach-profile testbr0 default eth0

现在你可以在任何一台主机上启动容器，并看到它们从同一个地址池中获取 IP，通过隧道直接互相通讯。

如先前所述，这个使用了组播，它通常在跨越路由器时无法很好工作。在这些情况下，你可以用单播模式使用 VXLAN 或者 GRE 隧道。

要使用 GRE 加入另一台主机，首先配置服务主机：

root@edfu:~# lxc network set testbr0 tunnel.nuturo.protocol gre
root@edfu:~# lxc network set testbr0 tunnel.nuturo.local 172.17.16.2
root@edfu:~# lxc network set testbr0 tunnel.nuturo.remote 172.17.16.9

接着是“客户端”主机：

root@nuturo:~# lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.edfu.protocol=gre tunnel.edfu.local=172.17.16.9 tunnel.edfu.remote=172.17.16.2
Network testbr0 created
root@nuturo:~# lxc network attach-profile testbr0 default eth0

如果你像使用 VXLAN，只要这么做：

root@edfu:~# lxc network set testbr0 tunnel.edfu.id 10
root@edfu:~# lxc network set testbr0 tunnel.edfu.protocol vxlan

还有：

root@nuturo:~# lxc network set testbr0 tunnel.edfu.id 10
root@nuturo:~# lxc network set testbr0 tunnel.edfu.protocol vxlan

这里需要隧道 id 以防与已经配置的多播 VXLAN 隧道冲突。

这就是如何使用最近的 LXD 简化跨主机联网了！

总结

LXD 使得从简单的单主机网络到数千个容器的非常复杂的跨主机网络的定义变得更加容易。它也使为一些容器定义一个新网络或者给容器添加第二个设备，并连接到隔离的私有网络变得很简单。

虽然这篇文章介绍了支持的大部分功能，但仍有一些可以微调 LXD 网络体验的窍门。可以在这里找到完整的列表：https://github.com/lxc/lxd/blob/master/doc/configuration.md 。

额外信息

• LXD 主站：https://linuxcontainers.org/lxd
• Github 地址： https://github.com/lxc/lxd
• 邮件列表支持：https://lists.linuxcontainers.org
• IRC 频道：#lxcontainers on irc.freenode.net
• 在线尝试 LXD：https://linuxcontainers.org/lxd/try-it

via: https://www.stgraber.org/2016/10/27/network-management-with-lxd-2-3/

作者：Stéphane Graber 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Shell 脚本编程 是你在 Linux 下学习或练习编程的最简单的方式。尤其对 系统管理员要处理着自动化任务，且要开发新的简单的实用程序或工具等（这里只是仅举几例）更是必备技能。

本文中，我们将分享 10 个写出高效可靠的 bash 脚本的实用技巧，它们包括：

1、 脚本中多写注释

这是不仅可应用于 shell 脚本程序中，也可用在其他所有类型的编程中的一种推荐做法。在脚本中作注释能帮你或别人翻阅你的脚本时了解脚本的不同部分所做的工作。

对于刚入门的人来说，注释用 # 号来定义。

# TecMint 是浏览各类 Linux 文章的最佳站点

2、 当运行失败时使脚本退出

有时即使某些命令运行失败，bash 可能继续去执行脚本，这样就影响到脚本的其余部分（会最终导致逻辑错误）。用下面的行的方式在遇到命令失败时来退出脚本执行：

# 如果命令运行失败让脚本退出执行
set -o errexit 
# 或
set -e

3、 当 Bash 用未声明变量时使脚本退出

Bash 也可能会使用能导致起逻辑错误的未声明的变量。因此用下面行的方式去通知 bash 当它尝试去用一个未声明变量时就退出脚本执行：

# 若有用未设置的变量即让脚本退出执行
set -o nounset
# 或
set -u

4、 使用双引号来引用变量

当引用时（使用一个变量的值）用双引号有助于防止由于空格导致单词分割开和由于识别和扩展了通配符而导致的不必要匹配。

看看下面的例子：

#!/bin/bash
# 若命令失败让脚本退出
set -o errexit 
# 若未设置的变量被使用让脚本退出
set -o nounset
echo "Names without double quotes" 
echo

names="Tecmint FOSSMint Linusay"

for name in $names; do
  echo "$name"
done

echo
echo "Names with double quotes" 
echo

for name in "$names"; do
  echo "$name"
done

exit 0

保存文件并退出，接着如下运行一下：

$ ./names.sh

在脚本中用双引号

5、 在脚本中使用函数

除了非常小的脚本（只有几行代码），总是记得用函数来使代码模块化且使得脚本更可读和可重用。

写函数的语法如下所示：

function check_root(){
  command1; 
  command2;
}
# 或
check_root(){
  command1; 
  command2;
}

写成单行代码时，每个命令后要用终止符号：

check_root(){ command1; command2; }

6、 字符串比较时用 = 而不是 ==

注意 == 是 = 的同义词，因此仅用个单 = 来做字符串比较，例如：

value1=”tecmint.com”
value2=”fossmint.com”
if [ "$value1" = "$value2" ]

7、 用 $(command) 而不是老旧的 command 来做代换

命令代换 是用这个命令的输出结果取代命令本身。用 $(command) 而不是引号 command 来做命令代换。

这种做法也是 shellcheck tool （可针对 shell 脚本显示警告和建议）所建议的。例如：

user=`echo “$UID”`
user=$(echo “$UID”)

8、 用 readonly 来声明静态变量

静态变量不会改变；它的值一旦在脚本中定义后不能被修改：

readonly passwd_file=”/etc/passwd”
readonly group_file=”/etc/group”

9、 环境变量用大写字母命名，而自定义变量用小写

所有的 bash 环境变量用大写字母去命名，因此用小写字母来命名你的自定义变量以避免变量名冲突：

# 定义自定义变量用小写，而环境变量用大写
nikto_file=”$HOME/Downloads/nikto-master/program/nikto.pl”
perl “$nikto_file” -h  “$1”

10、 总是对长脚本进行调试

如果你在写有数千行代码的 bash 脚本，排错可能变成噩梦。为了在脚本执行前易于修正一些错误，要进行一些调试。通过阅读下面给出的指南来掌握此技巧：

1. 如何在 Linux 中启用 Shell 脚本调试模式
2. 如何在 Shell 脚本中执行语法检查调试模式
3. 如何在 Shell 脚本中跟踪调试命令的执行

本文到这就结束了，你是否有一些其他更好的 bash 脚本编程经验想要分享？若是的话，在下面评论框分享出来吧。

作者简介：

Aaron Kili 是一个 Linux 和 F.O.S.S（Free and Open-Source Software，自由及开放源代码软件）爱好者，未来的 Linux 系统管理员、Web 开发人员，目前是 TecMint 的内容创作者，他喜欢用电脑工作，且崇尚分享知识。

via: https://www.tecmint.com/useful-tips-for-writing-bash-scripts-in-linux/

作者：Aaron Kili 译者：ch-cn 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在编写高效 SQL 时，你可能遇到的最有影响的事情就是索引。但是，一个很重要的事实就是很多 SQL 客户端要求数据库做很多“不必要的强制性工作”。

跟我再重复一遍：

不必要的强制性工作

什么是“不必要的强制性工作”？这个意思包括两个方面：

不必要的

假设你的客户端应用程序需要这些信息：

这没什么特别的。我们运行着一个电影数据库（例如 Sakila 数据库），我们想要给用户显示每部电影的名称和评分。

这是能产生上面结果的查询：

SELECT title, rating
FROM film

然而，我们的应用程序（或者我们的 ORM（LCTT 译注： 对象关系映射 （ Object-Relational Mapping ） ））运行的查询却是：

SELECT *
FROM film

我们得到什么？猜一下。我们得到很多无用的信息：

甚至一些复杂的 JSON 数据全程在下列环节中加载：

• 从磁盘
• 加载到缓存
• 通过总线
• 进入客户端内存
• 然后被丢弃

是的，我们丢弃了其中大部分的信息。检索它所做的工作完全就是不必要的。对吧？没错。

强制性

这是最糟糕的部分。现今随着优化器变得越来越聪明，这些工作对于数据库来说都是强制执行的。数据库没有办法知道客户端应用程序实际上不需要其中 95% 的数据。这只是一个简单的例子。想象一下如果我们连接更多的表...

你想想那会怎样呢？数据库还快吗？让我们来看看一些之前你可能没有想到的地方：

内存消耗

当然，单次执行时间不会变化很大。可能是慢 1.5 倍，但我们可以忍受，是吧？为方便起见，有时候确实如此。但是如果你每次都为了方便而牺牲性能，这事情就大了。我们不说性能问题（单个查询的速度），而是关注在吞吐量上时（系统响应时间），事情就变得困难而难以解决。你就会受阻于规模的扩大。

让我们来看看执行计划，这是 Oracle 的：

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |   166K|
|   1 |  TABLE ACCESS FULL| FILM |  1000 |   166K|
--------------------------------------------------

对比一下：

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 | 20000 |
|   1 |  TABLE ACCESS FULL| FILM |  1000 | 20000 |
--------------------------------------------------

当执行 SELECT * 而不是 SELECT film, rating 的时候，我们在数据库中使用了 8 倍之多的内存。这并不奇怪，对吧？我们早就知道了。在很多我们并不需要其中全部数据的查询中我们都是这样做的。我们为数据库产生了不必要的强制性工作，其后果累加了起来，就是我们使用了多达 8 倍的内存（当然，数值可能有些不同）。

而现在，所有其它的步骤（比如，磁盘 I/O、总线传输、客户端内存消耗）也受到相同的影响，我这里就跳过了。另外，我还想看看...

索引使用

如今大部分数据库都有涵盖索引（LCTT 译注：covering index，包括了你查询所需列、甚至更多列的索引，可以直接从索引中获取所有需要的数据，而无需访问物理表）的概念。涵盖索引并不是特殊的索引。但对于一个特定的查询，它可以“意外地”或人为地转变为一个“特殊索引”。

看看这个查询：

SELECT *
FROM actor
WHERE last_name LIKE 'A%'

执行计划中没有什么特别之处。它只是个简单的查询。索引范围扫描、表访问，就结束了：

-------------------------------------------------------------------
| Id  | Operation                   | Name                | Rows  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                     |     8 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ACTOR               |     8 |
|*  2 |   INDEX RANGE SCAN          | IDX_ACTOR_LAST_NAME |     8 |
-------------------------------------------------------------------

这是个好计划吗？如果我们只是想要这些，那么它就不是：

当然，我们浪费了内存之类的。再来看看这个查询：

SELECT first_name, last_name 
FROM actor
WHERE last_name LIKE 'A%'

它的计划是：

----------------------------------------------------
| Id  | Operation        | Name            | Rows  |
----------------------------------------------------
|   0 | SELECT STATEMENT |                 |     8 |
|*  1 |  INDEX RANGE SCAN| IDX_ACTOR_NAMES |     8 |
----------------------------------------------------

现在我们可以完全消除表访问，因为有一个索引涵盖了我们查询需要的所有东西……一个涵盖索引。这很重要吗？当然！这种方法可以将你的某些查询加速一个数量级（如果在某个更改后你的索引不再涵盖，可能会降低一个数量级）。

你不能总是从涵盖索引中获利。索引也有它们自己的成本，你不应该添加太多索引，例如像这种情况就是不明智的。让我们来做个测试：

SET SERVEROUTPUT ON
DECLARE
  v_ts TIMESTAMP;
  v_repeat CONSTANT NUMBER := 100000;
BEGIN
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Worst query: Memory overhead AND table access
      SELECT *
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 1 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Better query: Still table access
      SELECT /*+INDEX(actor(last_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 2 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Best query: Covering index
      SELECT /*+INDEX(actor(last_name, first_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 3 : ' || (SYSTIMESTAMP - v_ts));
END;
/

结果是：

Statement 1 : +000000000 00:00:02.479000000
Statement 2 : +000000000 00:00:02.261000000
Statement 3 : +000000000 00:00:01.857000000

注意，表 actor 只有 4 列，因此语句 1 和 2 的差别并不是太令人印象深刻，但仍然很重要。还要注意我使用了 Oracle 的提示来强制优化器为查询选择一个或其它索引。在这种情况下语句 3 明显胜利。这是一个好很多的查询，也是一个十分简单的查询。

当我们写 SELECT * 语句时，我们为数据库带来了不必要的强制性工作，这是无法优化的。它不会使用涵盖索引，因为比起它所使用的 LAST_NAME 索引，涵盖索引开销更多一点，不管怎样，它都要访问表以获取无用的 LAST_UPDATE 列。

使用 SELECT * 会变得更糟。考虑一下……

SQL 转换

优化器工作的很好，因为它们转换了你的 SQL 查询（看我最近在 Voxxed Days Zurich 关于这方面的演讲）。例如，其中有一个称为“表连接消除”的转换，它真的很强大。看看这个辅助视图，我们写了这个视图是因为我们非常讨厌总是连接所有这些表：

CREATE VIEW v_customer AS
SELECT
  c.first_name, c.last_name, 
  a.address, ci.city, co.country
FROM customer c
JOIN address a USING (address_id)
JOIN city ci USING (city_id)
JOIN country co USING (country_id)

这个视图仅仅是把 CUSTOMER 和他们不同的 ADDRESS 部分所有“对一”关系连接起来。谢天谢地，它很工整。

现在，使用这个视图一段时间之后，想象我们非常习惯这个视图，我们都忘了所有它底层的表。然后，我们运行了这个查询：

SELECT *
FROM v_customer

我们得到了一个相当令人印象深刻的计划：

----------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost |
----------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |   599 | 47920 |   14 |
|*  1 |  HASH JOIN           |          |   599 | 47920 |   14 |
|   2 |   TABLE ACCESS FULL  | COUNTRY  |   109 |  1526 |    2 |
|*  3 |   HASH JOIN          |          |   599 | 39534 |   11 |
|   4 |    TABLE ACCESS FULL | CITY     |   600 | 10800 |    3 |
|*  5 |    HASH JOIN         |          |   599 | 28752 |    8 |
|   6 |     TABLE ACCESS FULL| CUSTOMER |   599 | 11381 |    4 |
|   7 |     TABLE ACCESS FULL| ADDRESS  |   603 | 17487 |    3 |
----------------------------------------------------------------

当然是这样。我们运行了所有这些表连接以及全表扫描，因为这就是我们让数据库去做的：获取所有的数据。

现在，再一次想一下，对于一个特定场景，我们真正想要的是：

是啊，对吧？现在你应该知道我的意图了。但想像一下，我们确实从前面的错误中学到了东西，现在我们实际上运行下面一个比较好的查询：

SELECT first_name, last_name
FROM v_customer

再来看看结果！

------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost  |
------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |   599 | 16173 |     4 |
|   1 |  NESTED LOOPS      |             |   599 | 16173 |     4 |
|   2 |   TABLE ACCESS FULL| CUSTOMER    |   599 | 11381 |     4 |
|*  3 |   INDEX UNIQUE SCAN| SYS_C007120 |     1 |     8 |     0 |
------------------------------------------------------------------

这是执行计划一个极大的进步。我们的表连接被消除了，因为优化器可以证明它们是不必要的，因此一旦它可以证明这点（而且你不会因使用 select * 而使其成为强制性工作），它就可以移除这些工作并不执行它。为什么会发生这种情况？

每个 CUSTOMER.ADDRESS_ID 外键保证了有且只有一个 ADDRESS.ADDRESS_ID 主键值，因此可以保证 JOIN 操作是对一连接，它不会产生或者删除行。如果我们甚至不选择行或查询行，当然我们就不需要真正地去加载行。可以证实地移除 JOIN 并不会改变查询的结果。

数据库总是会做这些事情。你可以在大部分数据库上尝试它：

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT 1 / 0 FROM dual
) THEN 1 ELSE 0 END
FROM dual

-- 更合理的 SQL 语句，例如 PostgreSQL
SELECT EXISTS (SELECT 1 / 0)

在这种情况下，当你运行这个查询时你可能预料到会抛出算术异常：

SELECT 1 / 0 FROM dual

产生了：

ORA-01476: divisor is equal to zero

但它并没有发生。优化器（甚至解析器）可以证明 EXISTS (SELECT ..) 谓词内的任何 SELECT 列表达式不会改变查询的结果，因此也就没有必要计算它的值。呵！

同时……

大部分 ORM 最不幸问题就是事实上他们很随意就写出了 SELECT * 查询。事实上，例如 HQL / JPQL，就设置默认使用它。你甚至可以完全抛弃 SELECT 从句，因为毕竟你想要获取所有实体，正如声明的那样，对吧？

例如：

FROM v_customer

例如 Vlad Mihalcea（一个 Hibernate 专家和 Hibernate 开发倡导者）建议你每次确定不想要在获取后进行任何更改时再使用查询。ORM 使解决对象图持久化问题变得简单。注意：持久化。真正修改对象图并持久化修改的想法是固有的。

但如果你不想那样做，为什么要抓取实体呢？为什么不写一个查询？让我们清楚一点：从性能角度，针对你正在解决的用例写一个查询总是会胜过其它选项。你可以不会在意，因为你的数据集很小，没关系。可以。但最终，你需要扩展并重新设计你的应用程序以便在强制实体图遍历之上支持查询语言，就会变得很困难。你也需要做其它事情。

计算出现次数

资源浪费最严重的情况是在只是想要检验存在性时运行 COUNT(*) 查询。例如：

这个用户有没有订单？

我们会运行：

SELECT count(*)
FROM orders
WHERE user_id = :user_id

很简单。如果 COUNT = 0：没有订单。否则：是的，有订单。

性能可能不会很差，因为我们可能有一个 ORDERS.USER_ID 列上的索引。但是和下面的这个相比你认为上面的性能是怎样呢：

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
) THEN 1 ELSE 0 END
FROM dual

-- 更合理的 SQL 语句，例如 PostgreSQL
SELECT EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
)

它不需要火箭科学家来确定，一旦它找到一个，实际存在谓词就可以马上停止寻找额外的行。因此，如果答案是“没有订单”，速度将会是差不多。但如果结果是“是的，有订单”，那么结果在我们不计算具体次数的情况下就会大幅加快。

因为我们不在乎具体的次数。我们告诉数据库去计算它（不必要的），而数据库也不知道我们会丢弃所有大于 1 的结果（强制性）。

当然，如果你在 JPA 支持的集合上调用 list.size() 做同样的事情，情况会变得更糟！

近期我有关于该情况的博客以及在不同数据库上的测试。去看看吧。

总结

这篇文章的立场很“明显”。别让数据库做不必要的强制性工作。

它不必要，因为对于你给定的需求，你知道一些特定的工作不需要完成。但是，你告诉数据库去做。

它强制性，因为数据库无法证明它是不必要的。这些信息只包含在客户端中，对于服务器来说无法访问。因此，数据库需要去做。

这篇文章大部分在介绍 SELECT *，因为这是一个很简单的目标。但是这并不仅限于数据库。这关系到客户端要求服务器完成不必要的强制性工作的任何分布式算法。你的 AngularJS 应用程序平均有多少个 N+1 问题，UI 在服务结果 A 上循环，多次调用服务 B，而不是把所有对 B 的调用打包为一个调用？这是一个复发的模式。

解决方法总是相同。你给执行你命令的实体越多信息，（理论上）它能更快执行这样的命令。每次都写一个好的查询。你的整个系统都会为此感谢你的。

如果你喜欢这篇文章...

再看看近期我在 Voxxed Days Zurich 的演讲，其中我展示了一些在数据处理算法上为什么 SQL 总是会胜过 Java 的双曲线例子。

（题图：Pixabay， CC0）

via: https://blog.jooq.org/2017/03/08/many-sql-performance-problems-stem-from-unnecessary-mandatory-work

作者：jooq 译者：ictlyh 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

学习如何用 PHP 和温度传感器实现树莓派控制 GPIO 并操作继电器

你是否曾经想知道怎样使用手机或者电脑在任何地方控制你的风扇和灯等一些家用电器？

我现在想控制我的圣诞彩灯，是使用手机呢，还是使用平板电脑呢，或者是使用笔记本电脑呢？都不是，而是仅仅使用一个树莓派。让我来告诉你如何使用 PHP 和温度传感器实现树莓派控制 GPIO 引脚并操作继电器。我使用 AJAX 把它们整合在了一起。

硬件要求：

• 树莓派
• 安装有 Raspbian 系统的 SD 卡（任何一张 SD 卡都可以，但是我更偏向使用大小为 32GB 等级为 class 10 的 SD 卡）
• 电源适配器
• 跳线（母对母跳线和公转母跳线）
• 继电器板（我使用一个用于 12V 继电器的继电器板）
• DS18B20 温度传感器
• 树莓派的 Wi-Fi 适配器
• 路由器（为了访问互联网，你需要有一个拥有端口转发的路由器）
• 10KΩ 的电阻

软件要求：

• 下载并安装 Raspbian 系统到你的 SD 卡
• 有效的互联网连接
• Apache web 服务器
• PHP
• WiringPi
• 基于 Mac 或者 Windows 的 SSH 客户端

一般的配置和设置

1、 插入 SD 卡到树莓派，然后使用以太网网线将它连接到路由器；

2、 连接 WiFi 适配器；

3、 使用 SSH 方式登录到树莓派，然后使用下面的命令编辑 interfaces 文件：

sudo nano /etc/network/interfaces

这个命令会用一个叫做 nano 的编辑器打开这个文件。它是一个非常简单又易于使用的文本编辑器。如果你不熟悉基 Linux 的操作系统，可以使用键盘上的方向键来操作。

用 nano 打开这个文件后，你会看到这样一个界面：

4、要配置你的无线网络，按照下面所示修改这个文件：

iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
   wpa-ssid "Your Network SSID"
   wpa-psk "Your Password"

5、 按 CTRL+O 保存，然后按 CTRL+X 退出编辑器。

到目前为止，一切都已经配置完成，接下来你需要做的就是使用命令重新加载网络：

sudo service networking reload

（警告：如果你是使用远程连接的方式连接的树莓派，连接将会中断。)

软件配置

安装 Apache web 服务器

Apache 是一个受欢迎的服务器应用，你可以在树莓派安装这个程序让它提供网页服务。Apache 原本就可以通过 HTTP 方式提供 HTML 文件服务，添加其他模块后，Apache 还可以使用像 PHP 这样的脚本语言来提供动态网页的服务。

可以在命令行输入下面命令安装 Apache：

sudo apt-get install apache2 -y

安装完成后，可以在浏览器地址栏输入树莓派的 IP 地址来测试 web 服务器。如果你可以获得下面图片的内容，说明你已经成功地安装并设置好了你的服务器。

要改变这个默认的页面和添加你自己的 html 文件，进入 var/www/html 目录：

cd /var/www/html

添加一些文件来测试是否成功。

安装 PHP

PHP 是一个预处理器，这意味着它是当服务器收到网页请求时才会运行的一段代码。它开始运行，处理网页上需要被显示的内容，然后把网页发送给浏览器。不像静态的 HTML，PHP 在不同的环境下可以显示不同的内容。其他的语言也可以做到这一点，但是由于 WordPress 是用 PHP 编写的，有些时候你需要使用它。PHP 是 web 上一种非常受欢迎的语言，像 Facebok 和 Wikipeadia 这样的大型项目都是用 PHP 编写的。

使用下面的命令安装 PHP 和 Apache 软件包：

sudo apt-get install php5 libapache2-mod-php5 -y

测试 PHP

创建文件 index.php：

sudo nano index.php

在里面写入一些 PHP 内容：

<?php echo "hello world"; ?>

保存文件，接下来删除 index.html，因为它比 index.php 的优先级更高：

sudo rm index.html

刷新你的浏览器，你会看到 “hello world”。这并不是动态的，但是它仍然由 PHP 提供服务。如果你在上面看到提原始的 PHP 文件而不是“hello world”，重新加载和重启 Apahce（LCTT 译注，重启即可）：

sudo /etc/init.d/apache2 reload
sudo /etc/init.d/apache2 restart

安装 WiringPi

为了可以对代码的更改进行跟踪，WiringPi 的维护采用 git。但假如你因为某些原因而没法使用 git，还有一种可以替代的方案。（通常你的防火墙会把你隔离开来，所以请先检查一下你的防火墙的设置情况！）

如果你还没有安装 git，那么在 Debian 及其衍生版本中（比如 Raspbian），你可以这样安装它：

sudo apt-get install git-core

若是你遇到了一些错误，请确保你的树莓派是最新版本的 Raspbian 系统：

sudo apt-get update sudo apt-get upgrade

使用 git 获取最 WiringPi：

sudo git clone git://git.drogon.net/wiringPi

如果你之前已经使用过 clone 操作，那么可以使用下面命令：

cd wiringPi && git pull origin

这个命令会将会获取更新的版本，你然后可以重新运行下面的构建脚本。

有一个新的简化的脚本来构建和安装:

cd wiringPi && ./build

这个新的构建脚本将会为你完成编译和安装 WiringPi。它曾一度需要使用 sudo 命令，所以在运行这它之前你可能需要检查一下这个脚本。

测试 WiringPi

运行 gpio 命令来检查安装成功与否:

gpio -v gpio readall

这将给你一些信心，软件运行良好。

连接 DS18B20 传感器到树莓派

• 传感器上的黑线用于 GND。
• 红线用于 VCC。
• 黄线是 GPIO 线。

连线：

• VCC 连接 3V 的 1 号引脚。
• GPIO 线连接 7 号引脚（GPIO4）。
• 地线连接 GND 的 9 号引脚。

软件配置

为了用 PHP 使用 DS18B20 温度传感器模块，你需要执行下面的命令来激活用于树莓派上 GPIO 引脚和 DS18B20 的内核模块：

sudo modprobe w1-gpio
sudo modprobe w1-therm

你不想每次 Raspberry 重启后都手动执行上述命令，所以你想每次开机能自动启动这些模块。可以在文件 /etc/modules 中添加下面的命令行来做到：

sudo nano /etc/modules/

添加下面的命令行到它里面:

w1-gpio
w1-therm

为了测试，输入:

cd /sys/bus/w1/devices/

现在输入 ls。

你会看到你的设备信息。在设备驱动程序中，你的 DS18B20 传感器应该作为一串字母和数字被列出。在本例中，设备被记录为 28-000005e2fdc3。然后你需要使用 cd 命令来访问传感器，用你自己的序列号替代我的： cd 28-000005e2fdc3。

DS18B20 会周期性的将数据写入文件 w1_slave，所以你只需要使用命令 cat来读出数据： cat w1_slave。

这会生成下面的两行文本，输出中 t= 表示摄氏单位的温度。在前两位数后面加上一个小数点(例如，我收到的温度读数是 30.125 摄氏度)。

连接继电器

1、 取两根跳线，把其中一根连接到树莓派上的 GPIO24（18 号引脚），另一根连接 GND 引脚。你可以参考下面这张图。

2、 现在将跳线的另一端连接到继电器板。GND 连接到继电器上的 GND，GPIO 输出线连接到继电器的通道引脚号，这取决于你正使用的继电器型号。记住，将树莓派上的 GND 与继电器上的 GND 连接连接起来，树莓派上的 GPIO 输出连接继电器上的输入引脚。

注意！将继电器连接树莓派的时候小心一些，因为它可能会导致电流回流，这会造成短路。

3、 现在将电源连接继电器，可以使用 12V 的电源适配器，也可以将 VCC 引脚连接到什么破上的 3.3V 或 5.5V 引脚。

使用 PHP 控制继电器

让我们先写一个借助于 WiringPi 软件用来控制 Paspberry Pi 上 GPIO 引脚的 PHP 脚本。

1、在 Apache 服务器的网站根目录下创建一个文件，使用下面命令切换到该目录：

cd /var/www/html

2、 新建一个叫 Home 的文件夹：

sudo mkdir Home

3、 新建一个叫 on.php的脚本

sudo nano on.php

4、 在脚本中加入下面的代码：

<?php
        system("gpio-g mode 24 out");
        system("gpio-g write 24 1");
?>

5、 使用 CTRL+O 保存文件，CTRL+X 退出。

上面的代码中，你在第一行使用命令将 24 号 GPIO引脚设置为 output 模式：

system("gpio-g mode 24 out");

在第二行，你使用 1 将 24 号引脚 GPIO 打开，在二进制中"1"表示打开，"0"表示关闭。

6、 为了关闭继电器，可以创建另外一个 off.php 文件，并用 0 替换 1。

<?php
        system(" gpio-g mode 24 out ");
        system(" gpio-g write 24 1 ");
?>

7、 如果你已经将继电器连接了树莓派，可以在浏览器中输入你的树莓派的 IP 地址，并在后面加上目录名和文件名来进行访问：

http://{IPADDRESS}/home/on.php 

这将会打开继电器。

8、 要关闭它，可以访问叫 off.php 的文件：

http://{IPADDRESS}/home/off.php

现在你需要能够在一个单独的页面来控制这两样事情，而不用单独的刷新或者访问这两个页面。你可以使用 AJAX 来完成。

9、 新建一个 HTML 文件，并在其中加入下面代码：

<html>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script type="text/javascript">// <![CDATA[
$(document).ready(function() {
  $('#on').click(function(){
  var a= new XMLHttpRequest();
  a.open("GET", "on.php"); a.onreadystatechange=function(){
    if (a.readyState==4){   
      if(a.status ==200){
      } else alert ("http error");   
      }  
    }
    a.send();
  });
});
$(document).ready(function()
  {  
    $('#Off').click(function(){
      var a= new XMLHttpRequest();
      a.open("GET", "off.php");
      a.onreadystatechange=function(){
        if(a.readyState==4){
          if(a.status ==200){
          } else alert ("http error");   
          }   
        }
      a.send();
    });
  });
</script>
<button id="on" type="button"``Switch Lights On </button>
<button id="off" type="button"``Switch Lights Off </button>

10、 保存文件，进入你的 web 浏览器目录，然后打开那个网页。你会看到两个按钮，它们可以打开和关闭灯泡。基于同样的想法，你还可以使用 bootstrap 和 CSS 来创建一个更加漂亮的 web 界面。

在这个网页上观察温度

1、 新建一个 temperature.php 的文件：

sudo nano temperature.php

2、 在文件中加入下面的代码，用你自己的设备 ID 替换 10-000802292522：

<?php
//File to read
$file = '/sys/devices/w1_bus_master1/10-000802292522/w1_slave';
//Read the file line by line
$lines = file($file);
//Get the temp from second line
$temp = explode('=', $lines[1]);
//Setup some nice formatting (i.e., 21,3)
$temp = number_format($temp[1] / 1000, 1, ',', '');
//And echo that temp
echo $temp . " °C";
?>

3、 打开你刚刚创建的 HTML 文件，并创建一个新的带有 id 为 “screen” 的 <div>标签

<div id="screen"></div>

4、 在这个标签后或者这个文档的尾部下面的代码：

<script>
$(document).ready(function(){
  setInterval(function(){
    $("#screen").load('temperature.php')
  }, 1000);
});
</script>

其中，#screen 是标签 <div> 的 id ，你想在它里面显示温度。它会每隔 1000 毫秒加载一次 temperature.php 文件。

我使用了 bootstrap 框架来制作一个漂亮的面板来显示温度，你还可以加入多个图标和图形让网页更有吸引力。

这只是一个控制继电器板并显示温度的基础的系统，你可以通过创建基于定时和从恒温器读数等基于事件触发来进一步地对系统进行开发。

（ 题图：opensource.com）

作者简介：

Abdul Hannan Mustajab: 我 17 岁，生活在印度。我正在追求科学，数学和计算机科学方面的教育。我在 spunkytechnology.com 上发表关于我的项目的博客。我一直在对使用不同的微控制器和电路板的基于物联网的 AI 进行研究。

via: https://opensource.com/article/17/3/operate-relays-control-gpio-pins-raspberry-pi

作者：Abdul Hannan Mustajab 译者：zhousiyu325 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出