[HN Gopher] CRDT Benchmarks
___________________________________________________________________
CRDT Benchmarks
Author : streamich
Score : 121 points
Date : 2023-05-22 12:59 UTC (10 hours ago)
(HTM) web link (jsonjoy.com)
(TXT) w3m dump (jsonjoy.com)
| simonw wrote:
| I'm still hoping for a CRDT implementation with robust,
| thoroughly tested libraries for both Python and JavaScript that
| can talk to each other - I want to run Python on the server and
| JavaScript in the client and keep the two in sync with each
| other.
|
| Closest I've seen to that is automerge but the Python version
| doesn't appear to be actively maintained or packaged for PyPI
| yet: https://github.com/automerge/automerge-py
|
| UPDATE: It looks like this might be what I'm after:
| https://github.com/y-crdt/ypy
| tantaman wrote:
| Wouldn't any of the Rust implementations be what you need (Yrs,
| Diamond Types or the Automerge rust re-write)? Given you can
| bind to a Rust implementation in JS or Python or whatever else.
| digdugdirk wrote:
| That ypy library looks very interesting. Do you have any idea
| what considerations would need to be kept in mind when trying
| to implement CRDTs?
|
| I'm thinking about something relatively basic, let's say a
| shared markdown document and/or shared dataframe view of a
| database table?
| alserio wrote:
| What I have not understood yet is how do you preserve invariants
| over a merge of JSON crdt. What do you do when a document has a
| structure that can be represented as a json, but not every valid
| json is a valid document? How do you avoid merges producing valid
| jsons but invalid documents?
| fnordsensei wrote:
| General CRDTs will guarantee valid data structures, but not
| schema/domain model validity. Kind of like how CRDTs applied to
| text will guarantee a string, but not valid English.
| paulgb wrote:
| This is a great analogy for something I've struggled to put
| into words.
|
| I'll add: if you have invariants, you almost by definition
| have conflicts. The C in CRDT is for conflict-free, so if you
| can have conflicts in the data domain you probably want
| something that can preserve them (like state machine
| synchronization) rather than a CRDT.
| jitl wrote:
| You need to design your document to minimize these kinds of
| issues. You can treat properties in the document as a last-
| write-wins register to minimize "strange merge" consistency
| within that property.
|
| For use cases with a central server, you can use server
| reconciliation to handle "true conflicts", essentially doing
| layer of OT-style ops at the application level _around_ CRDT
| structures provided by a library. See how Replicache suggests
| handling text for example. They provide a server reconciliation
| framework, and suggest you use a CRDT for text within that
| semantics.
| samwillis wrote:
| I need to dig into this more, but I'm sceptical of only
| benchmarking ops/second, that's not really a problem that needs
| solving, the existing toolkits are fast enough. Also, this
| benchmark doesn't show document size and growth, that is
| something where more research is needed.
|
| Always excited for any CRDT innovations though, and I'm sure
| there is stuff to learn from this work.
| johncalvinyoung wrote:
| Not always fast enough. Automerge with 32MB of JSON to parse
| is... painfully slow.
| yboris wrote:
| Direct link to _GitHub_ : https://github.com/streamich/json-joy
| refulgentis wrote:
| Holy s**.
| syncerr wrote:
| The death stroke for these types of projects seems to be lack of
| funding. This project is sponsored by nlnet[0] providing between
| 5k - 50k EU per year. Let's hope this gets additional resources.
|
| As a note, it appears to use Elastic's 2.0 license preventing
| selling software that includes this library [1]
|
| [0] https://nlnet.nl/project/JSON-Joy/
|
| [1] https://github.com/streamich/json-joy/blob/master/LICENSE
| johncalvinyoung wrote:
| Apache 2.0 as of... 18min ago?
| hankman86 wrote:
| [1] is a bummer. Turns this project into a technology showcase
| without any practical use.
| [deleted]
| johncalvinyoung wrote:
| Very interested in seeing progress, JSON CRDTs benchmarked with
| JS objects and arrays, I currently have an implementation based
| on Automerge but it's borderline nonviable on our largest data
| structures.
| jasonjmcghee wrote:
| What's the future of this work? Is it planned to be entirely
| standalone? Planning to build integration with popular editors?
| Planning a websocket server implementation with hooks etc / a
| hosted solution?
| fnordsensei wrote:
| I think the idea of the Rust implementations of Y and A is
| portability, primarily. A JS implementation alone is very
| opinionated about, for example, what your backend should look
| like. A Rust ditto will be less opinionated and more accessible
| in a variety of environments.
|
| I don't think the main point is the supposed superiority of WASM
| vs JS in terms of performance, as the article surmises.
| lynxaegon wrote:
| Great work! Looking forward to the CRDT
| tin7in wrote:
| Great to see this comparison! I haven't heard about Json-joy yet,
| so I'm curious to learn more. We are using Yjs in production and
| it works like magic!
| MrOwnPut wrote:
| That's crazy. But the main draw of Y.JS is how easy it is to use.
|
| It has many providers, easy persistence, and many integrations.
|
| Maybe make a compatibility layer to use the Y.JS ecosystem?
___________________________________________________________________
(page generated 2023-05-22 23:00 UTC)