存储后端如何影响数据体系？ [英] How does the storage backend influence datomic?

问题描述

如何选择Datomic的后端存储服务？是选择，例如，DynamoDB而不是Postgres的偏好，或者每个选项有不同的权衡？

How should I pick the backend storage service for Datomic? 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使用存储服务来存储排序的压缩数据块，类似于传统数据库系统使用文件系统和上面的要求几乎是底层存储服务和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和对等缓存，所以在理想情况下，即当工作集合适合内存时，系统不会放置很多o读取压力。

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.

如果您的系统不需要巨大的写入可扩展性，并且您的应用程序数据往往适合内存，那么特定存储服务的选择 >

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.

如果，on，on，则不相关，除非他们的操作能力（备份，管理工具等）与Datomic无关。另一方面，您的系统确实需要巨大的写入可扩展性，或者您有大量的对等体，每个对象使用的数据超过了它们的内存（迫使大量的数据段被带入从存储），您将需要一个存储系统，可以水平缩放例如DynamoDB。正如在其中一条评论中提到的，如果你需要任意写可扩展性，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.

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