"数据库不适合你"之类的废话

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的支持至少可以说是“次优”的，但它至少表明，有人最终理解了纯粹依靠文件系统获取元数据和索引是无法扩展的。

“氢气”你说呢?

Sonatype为Nexus使用的H2数据库是什么?它是一个内嵌的进程内数据库，旨在为Nexus提供一条逃离其Maven2布局监狱的路线。它好吗?它是!在使用Nexus进行生产时，它是否有可能临时需要的商业支持?法官为自己!我将引用:

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

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