"数据库不适合你"之类的FUD

2015年11月更新:Sonatype在Nexus 3中引入了抽象的blob存储，几乎完全模仿了Artifactory多年来一直批评的基于校验和的存储。谈谈领导者和追随者。

---

Checksum-based存储。这是Artifactory优于竞争对手的关键功能之一。以下是Sonatype (Nexus的创建者，使用普通的Maven2文件系统作为其存储库)关于Artifactory存储的典型错误声明:

Artifactory采取了完全相反的方法，将元数据和工件本身存储在一个巨大的数据库中。他们声称需要它的原因是交易行为。使用数据库并不能保证事务性，当然也不是获得事务性行为的唯一方法。”

这些说法和模糊的推理不仅是错误的（我们这样做不仅仅是为了事务行为(我们建议将工件存储在磁盘上)，但是使用数据库对您不利的主要主张也是如此。以下是Artifactory使用基于校验和存储的真正原因:

• 重复数据删除,通过通过校验和引用二进制文件，就像Git或Dropbox一样，并且不依赖于文件系统路径，相同的内容文件永远不会存储超过一次。这是可以优化二进制文件存储的少数几种方法之一。
• 自由复制和移动-工件提升(例如，在具有不同可见性规则的存储库之间移动)对于构建连续的产品非常关键输送管道。使用基于校验和的存储，这些操作根本不涉及任何文件系统活动——只是在数据库中添加和删除文件引用。
• 高效的上传，下载和复制-通过首先发送校验和报头来优化网络操作。存储中已经存在的文件将被跳过，即使它们出现在不同的路径下。
• 文件系统性能。由于文件永远不会被覆盖，只是在存储GC期间被删除，因此正常操作不需要FS上的写锁。与普通FS存储相比，期望显著的性能提升。
• 搜索稳定性和性能
  误用最初用于全文索引的框架来搜索文件系统是脆弱和缓慢的。使用基于校验和的存储，所有存储库信息和工件元数据都存储在优化的数据库索引中:始终是最新的，非常快，而且永远不会损坏。
• 〇布局自由当元数据仅从文件系统中提取并且文件被锁定在Maven2(或任何其他)布局中时，很难甚至不可能支持其他布局。由于Artifactory使用数据库作为实际存储和显示布局之间的间接层，因此它原生支持所有布局，包括Maven2, Maven1, Ivy, Gradle, Nuget, YUM, npm, debs, Docker, PyPI或任何其他自定义布局。

明白了吗?

智能校验和存储==强大的功能和更好的性能。

当然，Artifactory支持所有主要的关系数据库，包括Oracle、MySQL、MS SQL Server和PostgreSQL。我们可以使用任何数据库，包括NoSQL数据库，但是我们选择使用关系数据库作为一种防弹技术，我们的许多客户，无论是企业还是初创公司，都对它感到很熟悉。Artifactory提供了一个捆绑的Apache Derby DB，客户可以通过修改一行配置切换到他们的生产DB。

看看是谁闯进来了!

这花了一段时间，但看起来Sonatype最终也得到了这张照片。
Тhe Maven2布局被刻入Nexus存储库信息，该信息是由Maven2造成的Lucene格式的Nexus索引和文件系统混合而成。这有效地阻碍了Nexus在支持其他系统和布局方面的灵活性。

为了解决这个问题，Sonatype模仿了Artifactory的方法使用H2来支持NuGet。这并没有多大帮助;Nexus对NuGet的支持至少可以说是“次优的”，但至少它表明有人终于明白，纯粹依赖于文件系统的元数据和索引是无法扩展的。

你说“H2”?

Sonatype为Nexus使用的H2数据库是什么?它是一个嵌入式进程内数据库，可以让Nexus从它的Maven2布局监狱中逃脱。好吗?它是!它是否具有在生产环境中使用Nexus时可能需要的商业支持?你自己判断吧!我引用他的话:

H2的商业支持可以从Steve McLeod (Steve。McLeod at gmail。com)获得。请注意，他并不是H2的主要开发者之一。”

总而言之，这绝对是朝着正确方向迈出的一步。不幸的是，它让Nexus用户处于几乎相同的位置:存储库锁定到Maven2布局文件系统，有效地使Maven以外的任何东西都成为二等公民;优化后的元数据锁定在一个生产上有问题的进程内数据库中。

了解更多关于JFrog vs. Sonatype。