4 ms·

I wonder what it looks like in terms of resource usage. I think there's a strong case for something like this for IoT type devices. Imagine the simple case of

by davidw 9y ago

I wonder what it looks like in terms of resource usage. I think there's a strong case for something like this for IoT type devices. Imagine the simple case of adding a name to a contact list on a mobile device, and wanting that to get synced up with a series of other devices.

Xeoncross 9y ago
It's written in erlang so should be better ram usage than a Java database.
- cmeiklejohn 9y ago
  I wouldn't say "better"; I'd probably say that the memory profile would be completely different. It all depends on the number of actors, the size of objects, and the workload. Remember: for large binary objects, references on a shared heap are sent and messages are not explicitly copied per actor. This means it's dependent on the workload and both the structure of how many processes are involved in a single request.
cmeiklejohn 9y ago
(committer on Antidote, author of Lasp, both SyncFree projects) Antidote is designed for DC deployments, in the hundreds of clusters. It provides causal consistency and transactions. Lasp is designed for high-churn, edge deployments (with CRDTs) and provides eventual consistency: it's designed for 1,000+ nodes. They share a bit of code, and you might want to evaluate both to determine which is a better use case: Lasp might be a better fit for the IoT application, because it was designed for that. Here's a HN post on Lasp's scalability: https://news.ycombinator.com/item?id=15444156 https://news.ycombinator.com/item?id=15444156 Here's a HN post on Lasp: https://news.ycombinator.com/item?id=14300763 https://news.ycombinator.com/item?id=14300763
- takeda 9y ago
  This is based on riak which is written in erlang. Those nodes connect in a mesh, and actually the limit of scaling is about 100 nodes in one cluster.
  - cmeiklejohn 9y ago
    See my comment above that you specifically replied to. Lasp [in high-scalability mode] does not connect in a mesh, and the links I provided demonstrate that we do not connect in a mesh. I specifically provided a link in the comment [with a link to an academic publication and a paper] you responded to about how we do non-full mesh and achieve 1000+ nodes. Antidote only uses distributed Erlang inside of a single cluster limiting a single cluster to 100+ nodes. The multi-DC protocol is not based on distributed Erlang, and therefore, is not limited by distributed Erlang (but, is limited by other factors.) Additionally, there are Riak Core modifications (authored by myself and others) that bypass distributed Erlang using the same semantics, and therefore, don't have the 100+ node cluster restriction. And finally, the 100+ node cluster restriction is highly-debated, by myself and other academics, because the restrictions are based on use of the global module, where systems that don't use this module will experience higher scalability numbers (based on empirical evidence, not yet published.) For reference, Ericsson, has run 200+ node Erlang clusters.

by davidw 9y ago

Xeoncross 9y ago

It's written in erlang so should be better ram usage than a Java database.

cmeiklejohn 9y ago
I wouldn't say "better"; I'd probably say that the memory profile would be completely different. It all depends on the number of actors, the size of objects, and the workload. Remember: for large binary objects, references on a shared heap are sent and messages are not explicitly copied per actor. This means it's dependent on the workload and both the structure of how many processes are involved in a single request.

cmeiklejohn 9y ago

(committer on Antidote, author of Lasp, both SyncFree projects) Antidote is designed for DC deployments, in the hundreds of clusters. It provides causal consistency and transactions. Lasp is designed for high-churn, edge deployments (with CRDTs) and provides eventual consistency: it's designed for 1,000+ nodes. They share a bit of code, and you might want to evaluate both to determine which is a better use case: Lasp might be a better fit for the IoT application, because it was designed for that. Here's a HN post on Lasp's scalability: https://news.ycombinator.com/item?id=15444156 https://news.ycombinator.com/item?id=15444156 Here's a HN post on Lasp: https://news.ycombinator.com/item?id=14300763 https://news.ycombinator.com/item?id=14300763

takeda 9y ago
This is based on riak which is written in erlang. Those nodes connect in a mesh, and actually the limit of scaling is about 100 nodes in one cluster.
- cmeiklejohn 9y ago
  See my comment above that you specifically replied to. Lasp [in high-scalability mode] does not connect in a mesh, and the links I provided demonstrate that we do not connect in a mesh. I specifically provided a link in the comment [with a link to an academic publication and a paper] you responded to about how we do non-full mesh and achieve 1000+ nodes. Antidote only uses distributed Erlang inside of a single cluster limiting a single cluster to 100+ nodes. The multi-DC protocol is not based on distributed Erlang, and therefore, is not limited by distributed Erlang (but, is limited by other factors.) Additionally, there are Riak Core modifications (authored by myself and others) that bypass distributed Erlang using the same semantics, and therefore, don't have the 100+ node cluster restriction. And finally, the 100+ node cluster restriction is highly-debated, by myself and other academics, because the restrictions are based on use of the global module, where systems that don't use this module will experience higher scalability numbers (based on empirical evidence, not yet published.) For reference, Ericsson, has run 200+ node Erlang clusters.