Repository navigation
Update readme - #91
lejeunerenard wants to merge 15 commits into
Conversation
|
|
||
| An append-only B-tree on top of a [Hypercore][hypercore]. | ||
| A P2P append-only multifork Bε-tree build on top of [Hypercore][hypercore]. | ||
| This is the next major version for [hyperbee](https://github.com/holepunchto/hyperbee). |
There was a problem hiding this comment.
Can be something like "This is the next generation of Hyperbee and surpasses it in both features and performance in all aspects"
There was a problem hiding this comment.
Added and elaborated on the differences pointing out:
- better batch API (
WriteBatch) - delta compression
- how tree's reference other trees to 'fork' them
noahlevenson
left a comment
noahlevenson
left a comment
There was a problem hiding this comment.
General context: I read the diff from the POV of someone mostly unfamiliar with legacy Hyperbee, who's trying to understand and evaluate Hyperbee2 for my use case, which happens to be search. So I primarily concerned myself with the "basic orientation" questions: what does this thing do and why is that useful, what kinds of workloads is it designed to support, etc.
I also read the legacy Hyperbee readme, trying to identify information we communicated there that we might want to carry over here, such that users arriving fresh to Hyperbee2 don't have to follow the pointer back to Hyperbee and merge the information delta in their brain.
A fair portion of the diff here is API docs. I found some of the docs a bit hard to grok, but I'm not sure that my opinion is valuable, because I don't understand many of the technical details. I just lobbed in a couple of comments about grammatical constructions that confused me.
| Next major version for [hyperbee](https://github.com/holepunchto/hyperbee). | ||
| Will be merged in there and released a new major when fully done. | ||
|
|
||
| An append-only B-tree on top of a [Hypercore][hypercore]. |
There was a problem hiding this comment.
I'd probably reorg this section. As a reader trying to get oriented without much context about legacy Hyperbee, I want to grok: what is this thing literally? What's the general shape of the problem it solves? Then more context about features. In that order, probably.
I want to read not just that the batch API is "better," but how is it better from the POV of an engineer? An engineer trying to solve a technical problem would be asking: "what kind of workloads is this designed for? How big is it supposed to scale? What problem motivated its design, and is that motivation similar to mine?" In the first 5 minutes of reading, just trying to understand the shape of the problem that this doohickey was designed to solve.
So maybe something like:
A P2P append-only multiwriter + multifork Bε-tree built atop Hypercore.
Hyperbee2 is the next generation of Hyperbee. It scales to billions of keys and provides conflict-free, high throughput reads and writes even under high contention.
Key features:
- Multiwriter support: one tree, thousands of concurrent writers
- Multifork capability: any tree node can hold a pointer to another core, enabling arbitrary forks
- Improved batch API: (what benefit does this provide?)
- Delta compression: (what benefit does this provide?)
- All the great features from legacy Hyperbee: sparse replication, range and prefix queries, (what else to mention?)
| An append-only B-tree on top of a [Hypercore][hypercore]. | ||
| A P2P append-only multifork Bε-tree build on top of [Hypercore][hypercore]. | ||
| This is the next generation of Hyperbee surpassing the original [hyperbee](https://github.com/holepunchto/hyperbee) in performance and features. Hyperbee2 adds a better batch API (see [WriteBatch](#writebatch)), delta compression and multiwriter capabilities. One key difference is that values in the tree can be pointers to other cores allowing for forking another tree. | ||
|
|
There was a problem hiding this comment.
Another thought from the search team POV:
Every time I look at a P2P database project, I ask myself the same question: what value/mutation semantics does it support? Meaning - what value types can be stored under a key? Is it a schema, or an arbitrary buffer, or what? What are the mutation semantics? Can I create a key that maps to an append-only set? What about mapping a key to a set that allows arbitrarily deletion? I still don't understand this aspect of Hyperbee/Hyperbee2 very well, and I'd probably want a bullet in the features about it.
|
|
||
| #### `await db.compat()` | ||
|
|
||
| Returns the block format (`type`) that the tree is currently written in, e.g. `encoding.TYPE_LATEST` or `encoding.TYPE_COMPAT`. |
There was a problem hiding this comment.
Just slightly bumped by the grammar here - could it be:
"Returns the block format of the tree"
or
"Returns the block format associated with the tree"
|
|
||
| #### `await db.cores([options])` | ||
|
|
||
| Returns an array of the [Hypercore][hypercore] keys the Hyperbee references, i.e. its own core plus any other cores linked in via cross-tree writes (see [`db.write([options])`](#dbwriteoptions)). |
There was a problem hiding this comment.
Just another grammar bump, "keys the Hyperbee references" - could it instead be:
Returns an array of the Hypercore keys referenced by the Hyperbee
?
This branch has not been deployed
3 participants
No description provided.