存储后端如何影响 Datomic? [英] How does the storage backend influence Datomic?

问题描述

我应该如何选择 Datomic 的后端存储服务?

How should I pick the backend storage service for Datomic?

选择 DynamoDB 而不是 Postgres 是偏好问题，还是每个选项都有不同的权衡?如果有，它们是什么?

Is it a matter of preference to select, say, DynamoDB instead of Postgres, or does each option have different tradeoffs? If so, what are they?

推荐答案

存储服务要求

Datomic 的存储服务一般应满足 3 个要求:

Storage Services Requirements

Datomic' storage services should generally meet 3 requirements:

1. 实现键值存储语义:使用索引键的值进行高效的读/写访问
2. 支持一致读取.例如阅读你自己的作品.理想情况下，无争用/无锁读取.
3. 支持条件看跌.例如乐观锁定 + 快照隔离.

1. Implement key-value store semantics: efficient read/write access using indexed keys’ values
2. Support consistent reads. e.g. read your own writes. Ideally, no-contention/lock-free reads.
3. Support conditional puts. e.g. optimistic locking + snapshot isolation.

Datomic 使用存储服务来存储已排序、压缩的 datom 块，类似于传统数据库系统使用文件系统的方式，上述要求几乎是底层存储服务和 Datomic 之间的 API.因此，存储服务的选择取决于它们对这三个要求的支持程度.

Datomic uses storages services to store blocks of sorted, compressed datoms, similar to the way traditional database systems use file systems and the requirements above are pretty much the API between the underlying storage service and Datomic. So the choice in storage services depend on how well they support those three requirements.

Datomic 通常不会对底层存储服务施加很大的写入压力，因为只有一个组件写入它，即 Transactor.此外，Datomic 使用后台索引作业将新颖性集成到存储中，一旦积累了足够的新颖性(默认情况下约为 32MB，但可以配置)，这进一步减少了持续的写入负载.Datomic 唯一立即写入的是事务日志.

Datomic doesn't usually put a lot of write pressure on the underlying storage service since there's only one component writing to it, the Transactor. Also, Datomic uses a background indexing job to integrate novelty into storage once enough of it has been accumulated (by default ~32MB but can be configured) which further reduces the constant write load. The only thing Datomic immediately writes is the transaction log.

Datomic 使用多层缓存，即 memcached 和对等缓存，因此在理想情况下，即当工作集适合内存时，系统也不会施加太大的读取压力.

Datomic uses multiple layers of caching i.e. memcached and peers cache so in ideal circumstances i.e. when the working set fits in memory, the systems won't put a lot o read pressure either.

如果您的系统不需要巨大的写入可扩展性并且您的应用程序数据往往适合内存，那么特定存储服务的选择是无关的，除了当然，因为它们与 Datomic 无关的操作能力(备份、管理工具等).

If your system doesn't require huge write scalability and your application data tends to fit in memory, then the choice of a particular storage service is irrelevant except, of course, for their operational capabilities (backups, admin tools, etc.) which have nothing to do with Datomic.

另一方面，如果您的系统确实需要巨大的写入可扩展性，或者您有大量的对等方，他们每个人处理的数据都超出了他们的内存(迫使很多要从存储中获取的数据段)，您将需要一个可以水平扩展的存储系统，例如动态数据库.正如其中一条评论所提到的，如果您需要任意写入可扩展性，那么 Datomic 无论如何都不是适合您的系统.

If, on the other hand, you system does require huge write scalability or you have a great number of peers, each of them working with more data than can fit in their memory (forcing a lot of data segments to be brought from storage), you'll require a storage system that can horizontally scale e.g. DynamoDB. As mentioned in one of the comments, if you need arbitrary write scalability, Datomic is not the right system for you anyway.

这篇关于存储后端如何影响 Datomic?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！