This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aleph (1)
- # architecture (1)
- # bangalore-clj (14)
- # beginners (15)
- # boot (89)
- # braveandtrue (1)
- # cider (1)
- # cljs-dev (33)
- # cljsjs (1)
- # cljsrn (147)
- # clojure (149)
- # clojure-quebec (1)
- # clojure-russia (82)
- # clojure-spec (18)
- # clojure-taiwan (2)
- # clojure-uk (15)
- # clojurescript (97)
- # cursive (11)
- # datomic (22)
- # funcool (2)
- # hoplon (53)
- # immutant (16)
- # jobs-rus (8)
- # lambdaisland (1)
- # off-topic (13)
- # om (7)
- # onyx (58)
- # parinfer (6)
- # planck (19)
- # protorepl (2)
- # re-frame (17)
- # reagent (201)
- # rum (6)
- # specter (9)
- # test-check (68)
- # untangled (47)
- # yada (94)
Are there any interesting strategies for dealing with data spread over geographical regions? The single transactor seems like a weakness here, although it's easy to replicate the storage for reads.
Just accept slightly slower writes? Separate DBs for different regions and accept slower reads when you have to query across DBs from other regions?
Those are the obvious trade-offs I can think of
Wait, in fact you don't have to accept slower reads if storage is replicated...That seems like the best choice, having different DBs per region and querying across multiple DBs?
Use case: I have an application served from multiple regions all making writes and a cron job in the background which needs to compile an XML using data from all regions to send off to a third party..
@danielstockton: I would definitely try to see if I can live with slow writes and 1 transactor before jumping to geographical sharding 🙂
@val_waeselynck: yeah, my application isn't very write heavy, that would probably be just fine
@danielstockton: do you need transactionality across regions? or can you consider them to be sharded from each other?
i would definitely try 1-transactor first, and see what the latency does to reads and writes from other regions
I know that's what my SQL-users friends do: they distribute their read replicas and have one master write replica
And this is so much easier to do with Datomic that we have no excuse for not trying it 🙂
Surprisingly, low-latency writes is not such a common requirement
i can consider them to be sharded, i think, but i do need to be able to see a full view of the data from the background job
the requirements are forever changing, which makes it difficult
one thing that worries me is making a bad choice that is hard to reverse
how to create a nil reference when the entity has a cyclic reference?
of cardinality one
you can just omit the attribute
hm, that's odd, it's saying that I'm inserting a string type, even when I ommit
seems like an odd change in the schema that made my db react
just deleted it and now its ok
I'd like to use Datomic on Postgres but I have a deep concern about it using one table with a Primary Key (which means a BTree index in postgres). Is the uniqueness constraint actually necessary for it to work or could I create the datomic_kvs table without declaring the id column as the Primary Key and instead creating a hash index for it?