他是CTO团队的一员，他拥有从前端站点到ED端的惊人知识。他还写了一些代码。谢谢大家。Noam，谢谢你Batel，我们开始吧。首先，什么是JFrog x射线?
XRay是一个用于开发安全操作的工具，它为您提供有关组织内部的漏洞、遵从性和许可的信息。这些工件存储在Artifactory中，它们是JFrog平台的一部分，所以我们有完整的解决方案来保护我们的二进制文件和工件。那么如何安装JFrog x射线呢?JFrog XRay支持不同的安装类型，如RPM, Docker, Kubernetes，我们可能会在未来增加更多。我们也有两个不同版本的on-prem和SaaS解决方案，以不同的方式处理DB同步过程。记住这一点，我们将在下一张幻灯片中讨论它们的区别。什么是XRay DBC?
为了扫描漏洞并验证许可证合合性，XRay使用了一个包含许多公共组件、漏洞和许可证的大型数据库。当第一次安装XRay时，下载中有一个初始的DBC，它存储所有要传输到XRay的公共数据，这是公共信息的核心知识。是的，今天数据库的压缩站点大约是6- 7g，我们的数据分析师正在非常非常努力地工作，制造越来越多的漏洞和组件，以确保我们有更多的数据可以找到，以防我们有任何安全漏洞，所以它每天都在增长。
是的，在我们得到6g的压缩数据之后我们需要打开它来提取它，我们找到45g的数据，我们需要插入到数据库中。这些数据以100兆字节的压缩文件的形式进入每一个安装。每个zip文件都有JSON文件，数字不是固定的，我们一会儿会看到原因。
当对象是组件或漏洞时，每个JSON文件有2000个对象。对象的大小不是固定的这就是JSON文件大小不同的原因也不是固定的，zip文件可以是一个JSON文件，也可以是150个JSON文件，两种情况都有。在我们做任何改进之前，最低要求是15个小时来处理整个DB同步过程，这是很多很多时间，我们不能让客户这样做。这需要很多时间来消化。所以我们试着思考如何解决这个问题，我们有几个解决方案，比如:第一个解决方案是将已经存在的数据库作为数据库分发给[听不清]，而不是在用户端免费创建它。
是的，但如果我们这样做，我们可能需要不同版本的数据集哪个数据集会与我们支持的繁荣版本相匹配有很多版本，因为我们没有。我们只是告诉客户他们需要安装，例如，prosper版本9.6和更高版本，因此，由于这个原因，这意味着对于每个prosper版本，我们需要有一个不同的数据中心，这可能会很多，因为我们不知道客户的版本是什么。
当然，我们可以将版本限制为PR支持，但我们不想走这条路，至少在一开始不是这样。是的，它也会使装置更大，对吧?它会更重而且……
是的，安装会更大，因为我们不知道它会是什么版本，我们需要也许我们需要在这之后确定版本，并准备好二进制文件供客户下载，就像DB同步一样，但我们仍然需要添加很多图像。
好吧，也许我们可以使用在线服务器来获取组件、漏洞和DB同步所需的一切信息?是的，这是一个很好的解决方案。实际上，这就是我们在云中所做的。所以你知道这是一个很好的解决方案。但对于本地客户来说，这将是棘手的，因为我们需要非常低的延迟的信息在公共组件和公众的漏洞,如果我们需要低延迟,这意味着我们需要服务器都提供相同的信息,实际上建造SCDN为了只是提供这虽然有其他选择,但这并不意味着我们没有我们不会这样,但我们要尽可能避免这种情况,我们可以发现别的东西,所以我们最后避免了这个。
好的，所以可能有一个[听不清]数据库用于那些使用较少的组件，而不是分布公共组件，有点混合。是的，没错，这是中间地带因为我们可以取公共地带组件，放在本地，然后只有1gb的数据或者类似的东西，所有其他更奇特的组件都可以通过请求下载。所以我们可以这么做。但如果我们这样做，这意味着它将更难支持离线预安装，这也是我们所支持的，因为我们不能告诉客户，只是安装XRay go与另一个命令，下载文件，然后安装数据到您的数据库与另一个命令。和你可以在两个不同的服务器这意味着你没有连接到互联网,我们可以说,好吧,我们保持相同的过程,我们已经为这种类型的客户现在有15个小时的时间来处理数据库同步,但我们也发现一种更好的方式,因为我们找到了一种方法来解决客户的问题,在做离线同步,现在我们要讨论这个。
最终，我们选择了增量，我们将在这个演示中看到如何改进DB同步，我们来讨论一下。我们从第一个工具Pprof开始研究。Pprof是谷歌开发的用于分析多线程应用程序的CPU执行程序。Pprof提供了在图形上生成问题可视化的能力。
结果表明，X-Ray在数据库操作上花费了大量时间。这是一个Pprof图的例子。是的，这是一个非常好的例子，因为这是我们经常使用的东西，以便在DB同步过程中发现问题。
这是火焰图，你可能在其他语言中都能找到它你只需要找到合适的工具Pprof还有其他功能所以一定要去看看。你可以在这里看到，例如，两个ad用户问题对数据库进行了三次调用。
一，二，三。正因为如此，我们不确定这是否是我们想要的，因为也许我们需要对数据库进行三次调用但我们可能只是想添加一个用户问题，为什么要进行这么多调用呢?所以我们得核实一下。
我们不知道是否有问题，但我们需要检查一下。你还可以在右边看到，关于增加许可证的问题我们有更多的电话，我们有8到9个来自另一个广告的电话。可能有一个问题，我们想检查一下。这就是我们开始的方式，我们看到有一些东西做了很多工作，在我们找到它之后，我们去打电话，试着思考所有的电话是否都是必要的。
当然，这是一个例子，我们发现我们在数据库中做了很多单行插入。虽然我们可以对数据库进行多次批量插入。例如，如果我们有组件，我们可以插入一个组件，但我们不能合并许多组件并将它们插入到一个批处理中。
为了做到这一点，我们添加了一个通道，它可以从很多地方获取很多组件，而它们有相似的上下文，这意味着它不是真正的全局上下文，因为我们有几个通道来获取信息，并并行执行例如，对于一个文件，我们可以创建一个通道，对于另一个文件，我们可以创建另一个通道。当半秒过去或者100个条目准备插入到数据库时，我们把这个通道清空这个工作得很好，因为它确保了数据仍然有效，因为我们经常这样做。同时，一次推送了很多数据，这样我们就减少了往返数据库的次数。这是第一个改进，但是我们不能在没有做一件很重要的事情的情况下进行改进，我们必须分离DB同步的类型。
我们开始之前我们之前开始改进过程是一个数据库同步,我们没有分离每日DB数据库同步和初始同步因此意味着我们做了很多的改进数据数据库同步,因为这是我们每天都做,我们没有那么多时间投资在最初的数据库同步,因为它甚至没有分离,我们没有我们做不到具体的改进,只有最初的数据库同步首先是分开。然后我们可以做第一个改进，分离插入现在，我们可以做另一个改进，乐观插入，而不是仅仅选择和检查我们是否需要安装或更新组件，我们可以尝试插入，如果我们有问题，我们将返回到更新。
但对于每日DB同步，我们也可以这样做但对于每日DB同步，我们更新的几率要高得多，可能会花更多时间。我们这样做是因为这样会花费更多时间因为我们需要插入，然后选择，然后更新而不仅仅是选择和更新。
但如果我们知道数据库是空的，我们可以进行插入，插入值为99%甚至更大，确保插入成功除非出现与现有数据无关的错误。这是第二个改进，第三个改进是增加了更多类型的工作人员这些工作人员可以获取数据并并行处理。
我们在数据库中添加实体操作器，并像第一个改进那样，通过单个插入获取数据并将其推入数据库的实体操作器。我们想要添加更多的工作人员因为当我们看到CPU的图形时，我们看到它是一种窦状图，在开始时非常努力地工作，然后当它到达JSON文件的末尾时它就停止工作了，因为它只处理一个条目。
一个组件。因为它只做了一次，它不需要CPU，它不像我们希望的那样使用CPU。因此，这里的一个改进是添加JSON文件工作者。然后我们可以并行地获取很多json，并在这些json中添加并行实体。但是我们有另一个问题,如果你还记得我们在一开始说,一个zip文件可以包含一个JSON,或它可以包含150个JSON所以很好,我们有JSON文件的工人,但这还不够,因为zip文件工人可以帮助我们做许多并行拉链和我们有不同的问题,因为我们不知道处理的时候,如果我们能做并行的zip文件的工人,如果我们能够并行运行它们因为日常数据库同步,zip文件必须同步，他们必须我们必须插入前一天的数据之前，我们插入当前的数据。
我们不想丢失数据什么的，对吧?我们要确保我们有所有的安装。-是的。
昨天的举个例子,如果我们有一个实体,例如,如果我更新实体如果我插入,所以实体的前一天,今天我要做的另一个变化对实体将会发生什么如果我要处理现在的前一天前一天是我今天要插入新数据,然后处理之前的数据和更新新的数据所以它意味着我结束的所有数据数据库，即使我不应该。所以对于每天的DB同步，我们只和一个工人一起工作，在zip文件上，对于最初的DB同步，我们可以和更多的工人一起工作，两个或更多的工人。这是我们做的一个很大的改变我们可以看到当我们做的时候CPU图是一条直线，这意味着CPU一直在工作，为了处理DB同步，它工作得很好，所以…
让我们来看看。实际上下一个改进是两个改进。
我们把它们放在一张幻灯片上因为这是一些东西的后处理但它们之间没有关系所以一个后处理是DB sync本身的后处理当我们做DB sync的后处理时，我们想要创建索引而不是在安装期间创建索引。这是我们能做的另一件事，因为我们把每日数据库同步和初始数据库同步分开了。
我在这里的意思是，如果您查看关于如何快速将大量数据插入数据库的过程备考表，您将看到第一个建议是在最后创建索引，而不是在插入过程中创建索引，因为当您完成数据插入时，索引的构建要快得多。另一件相关的事情是我们想要并行创建索引这是我们看到的一个很大的改进，但它只支持更新的进程，我想是版本11。在我们完成这些之后，我们必须检查数据库的版本所以这意味着现在我们在为不同的版本做不同的工作，所以我们有其他的我们这样做的地方，但这意味着DB同步将更快的新版本的繁荣。另一种与第一种不相关的后处理是当我们插入组件或漏洞时的后处理当我们对每日数据库同步进行此操作时，我们将进行反向查找，看看我们是否存在漏洞，如果我们需要根据新的漏洞或更新的漏洞更新某些内容，对于组件也是如此。如果我们需要这样做，我们需要运行另一个东西但是我们需要检查我们是否需要这样做这个检查对我们很多人都有用，但是我们知道数据库是空的，所以没有理由做这个检查。这是另一个很大的改进因为我们把每日DB同步和初始DB同步分开了。
好的，我们的图形是这样的。首先，我们必须迁移到prosper因为在此之前我们使用的是不同的数据库，对吧?我们有Ongor之类的。然后我们改进查询以重用[听不清]对象，你可以很容易地看到图表下降了一点。然后我们还添加了子组件的稳定/插入，作为我们在开始时谈到的第一个改进，所以我们只是使用批处理，一个接一个地插入。缩短到10小时。这很好，但还不够好。然后我们在更新之前进行乐观插入，我们还添加了组件和漏洞隔离，只花了4个小时就获得了完整的DB同步，这是一个巨大的改进，从16个小时到几乎16个小时。然后我们还有JSON和压缩文件工作器，它们工作得很好，它帮助我们处理CPU，就像Noah提到的那样。我们还在初始DB同步之前删除了一些索引只需要两个小时就可以获得一个完整的DB同步，所以我们添加了拉出索引的后处理和使用组件时的后处理，你可以看到我们只花了56分钟就获得了一个完整的DB同步，这是一个惊人的改进，从15个小时。不仅如此,当我们使用一个更好的(听不清),我们存档9 k AI行动和读写速度,所以我们会得到更好的解决方案,需要我们只有36分钟得到一个完整的数据库同步是一个了不起的进步,你可以看到它不是相关软件只对(听不清),然后我们会得到一个更好的解决方案,数据库同步,超级快,我想我们都很高兴,我们有更安全的环境，我认为现在是提问的好时机，非常感谢各位。
谢谢，谢谢大家的加入。
你可以在Twitter上找到我们，我们的电子邮件在这里，在LinkedIn上，欢迎联系我们，问我们任何问题，留下任何评论。
是的，没错，我们是为你们而来，非常非常感谢你们的加入。
请随时联系我。
谢谢你！
