mirror/dolt
1
0
Fork 0
mirror of https://github.com/dolthub/dolt.git synced 2026-02-09 03:09:12 -06:00
Code Issues Packages Projects Releases 127 Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Rafael Weinstein
2017-01-23 16:24:43 -08:00
committed by GitHub
parent 7e5af655e7
commit aaa66ea86f
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
go/nbs/README.md
View File

@@ -8,9 +8,9 @@ An experimental storage layer for [noms](https://github.com/attic-labs/noms).
- Writers need not worry about re-writing duplicate chunks. NBS will efficiently detect and drop (most) duplicates.
# Status
NBS is more-or-less "alpha". There's still work we want to do, but it basically works. The most obvious things that aren't implemented are Compaction and GC. In particular, there's currently no upper bound on the set of "tables" which comprise a store and now way to reduce the number.
NBS is more-or-less "alpha". There's still work we want to do, but it basically works. The most obvious things that aren't implemented are Compaction and GC. In particular, there's currently no upper bound on the set of "tables" which comprise a store and no way to reduce the number.
However, there are two full "back-ends", one for storage on a file-system and one for storage in AWS. The later requires a dynamo table and an s3 bucket.
There are two full "back-ends", one for storage on a file-system and one for storage in AWS. The later requires a dynamo table and an s3 bucket.
For the file back-end, perf is substantially better than LevelDB for two reasons (1) LDB does quite alot of compaction which burns IO but doesn't benenfit noms at all. (2) NBS locates related chunks together and thus reading data from a NBS store can be done quite alot faster (on a current Macbook Pro, you can read large blobs at 100s of MB/s, whereas LDB tops out at about 75 MB/s).