Fork me on GitHub
#datomic
<
2018-05-16
>
souenzzo01:05:16

transducers + entity api is powerfull as datalog, with some different properties. great combination

alexmiller02:05:57

pull is even better than entity

val_waeselynck07:05:24

@U064X3EF3 @U2J4FRT2T I think the comparison deserves more nuance. Entity is good for navigating on one data path and making late-bound decisions along the way. Pull is good for collecting data along a bunch of data paths with less control and expressiveness. Entity can be a good substrate for implementing a richer version of Pull (e.g Om Next parsers or GraphQL). Finally, let's not forget that these 2 compose!

souenzzo09:05:40

pull with transducers is less cool then with entity. If I swap entity with pull, I will need to write a pattern that "matches" with the transducers. And with pull, I will not be able to be lazy as I am in entity

souenzzo15:05:39

Example

(eduction 
    (map :cart/itens)
    (filter custom-item-pred?)
    (map :cart/_itens)
    (d/entity db id))
If I ask for empty? on this, It will be way faster then datalog or pull's

alexmiller15:05:06

fair enough! I’ve mostly been using client lately, which doesn’t have the entity api…

souenzzo15:05:01

But peer's will never be deprecated, right? 😉 Peer is a different product. Client API feels like traditional DB's (sure, with the awesome of datomic model)

alexmiller16:05:51

I’m not on the Datomic team, so can’t answer any questions about future direction (as I don’t know)

dustingetz23:05:34

Entity is more general, pull can be implemented in terms of entity, but not vice versa

danielstockton13:05:17

Does Datomic cloud allow bypassing the load balancer and controlling which peer you hit? In other words, can I direct similar queries at particular peers to get the most out of the object cache?

marshall13:05:43

Datomic Cloud or On-Prem?

marshall13:05:47

Cloud does not have peers

danielstockton13:05:25

That's my question really. The use-case i'm considering it for requires high frequency, very low latency reads (not write heavy). Should I try on-prem if this kind of read optimization might be necessary?

marshall13:05:27

Cloud uses an “affinity” to automatically route requests to the correct nodes

marshall13:05:09

no, Cloud will use things like sticky sessions / query affinity /etc to route multiple subsequent queries to the same node

marshall13:05:42

additionally, when Query Groups become available, you will be able to provision and specify a query group dedicated to any particular workload you have

👌 4
danielstockton13:05:55

Ok, cool. Is there documentation on how query affinity is determined?

danielstockton13:05:44

Do I also have control over the size of memcached? I basically want memcached to be the primary storage and misses to be extremely rare.

marshall13:05:30

valcache + EFS cache together mean misses are indeed extremely rare

danielstockton13:05:26

Great, sounds good. I'll have to evaluate it in practice. Thanks a lot.

chris_johnson14:05:58

Operations question about the on-prem topography running on AWS, which if there’s an answer in the docs I apologize for missing but I haven’t found: is there a way to discover, at a given moment in time, the IP address of every peer connected to a given transactor?

val_waeselynck15:05:25

I seem to recall someone saying than using SQUUIDs was no longer necessary, but having switched to regular UUID generation, I suspect that this is no the case for my Datomic version because of how slow indexing is (v 5.0.5407) - can someone confirm that ?

alexmiller16:05:39

as I understand it, squuids are not necessary in cloud, have no idea if anything changed re on-prem

marshall16:05:22

@val_waeselynck Adaptive indexing is the change that i would have expected to remove most of the advantage of SQUUIDS (http://blog.datomic.com/2014/03/datomic-adaptive-indexing.html) It was released in version 0.9.4699

val_waeselynck17:05:03

Ok, that's what I thought. I'll benchmark tomorrow

marshall17:05:33

Ok. Let me know if that doesn’t agree with your observations

val_waeselynck08:05:36

@U05120CBV solved it. The culprit was not slow index writes due to dispersion of values; it was actually slow index reads in a transaction function due to a high dispersion of EAVT lookups, resulting in lots of cache misses. Reordering the imports sensibly solved it. Adaptative indexing works fine AFAICT.