文件数据库与应用服务器数据库的并发性能&大容量数据

Question

我问了一个关于Ripple数据库实现的问题，并收到了这一反应：

纹波服务器使用SQLite作为结构化数据，使用可配置的“后端”存储非结构化“大容量”存储。结构化数据由事务等内容组成，这些事务被它们所影响的帐户编入索引。非结构化数据由构成网络历史部分的哈希索引的“块”数据组成。大容量存储的首选后端当前是Linux平台上的RocksDB。

这让我觉得很奇怪，因为Ripple的结构允许开发人员向服务器操作员提供几乎任何他们想要的需求。换句话说，为什么不使用数据库服务器，特别是PostgreSQL？

我找到了这个有趣的故障 of PostgreSQL vs SQLite和这一解释：

详细分析了它们是如何实现快照隔离的。SQLite使用文件锁定作为隔离事务的一种方法，只允许在所有读取完成后才命中写入。相反，Postgres使用了一种更复杂的方法，称为多并发版本控制(mvcc)，它允许多个写入与多个读取并行进行。

首先，大容量存储的理想实现是使用文件数据库吗？

第二，对于并发读写，PostgreSQL的性能远远优于文件数据库，这是真的吗？

最后，当表的长度接近数十亿行时，为了并发性能，文件数据库还是PostgreSQL？

请假设这两种选择都是理想的调整。

Answer 1

首先，大容量存储的理想实现是使用平面文件数据库，这是真的吗？

如果您说的是SQLite，那么它不是一个“平面文件数据库”。当然，它是一个单一的文件数据库，但是它是高度结构化的。

第二，对于并发读写，PostgreSQL的性能远远优于平面文件数据库，这是真的吗？

对于同时进行读写的工作负载，PostgreSQL通常会大大优于SQLite，因为读者可以在表被写入时继续操作。对于具有非琐碎事务的多个并发读取器和作者，没有竞争。为了使这种可能性成为可能，PostgreSQL必须至少写两次每个更改，然后进行“真空”清理工作。

通常，您可以序列化许多短读和写事务，因此它们看起来执行得非常快，即使它们都在锁上等待一段时间。因此，对于简单的读写，即使在多个并发客户端中，只要锁持续时间短，SQLite也可能做得很好。对长期交易来说，这是完全没有希望的。

换句话说，为什么不使用数据库服务器，特别是PostgreSQL？

可能是因为设置和运行SQLite非常简单，所以嵌入到应用程序中要容易得多。

PostgreSQL不支持进程内嵌入.虽然捆绑数据库服务器很容易，但仍然存在许多开发人员不想要的麻烦。升级PostgreSQL也是一件痛苦的事情，因为每个主要版本的文件格式都会发生变化，并且需要一个升级步骤，而SQLite的文件格式是难以置信的向上和向下兼容。