“数据库不适合你”之类的谬论

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 dot McLeod在gmaildot.com)。请注意，他不是H2的主要开发者之一。”

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