{ "componentChunkName": "component---src-templates-issues-tsx", "path": "/issues/46", "result": {"data":{"issuesJson":{"id":"8970fb4a-9ca2-530d-8671-8b31427fca15","title":"etcd-io/bbolt: Go 语言开发的嵌入式键/值数据库","number":46,"bodyHTML":"
\n



\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Reposetcd-io/bbolt
Views\"views\"
Stars\"stars\"
Forks\"forks\"
License\"license\"
UpdatedAt\"last-commit\"
CreatedAt\"create-at\"
\n\n

\"\"

\n\n
\n

bbolt

\n

\"Go
\n\"Go
\n\"Releases\"
\n\"LICENSE\"

\n

bbolt is a fork of Ben Johnson's Bolt key/value
\nstore. The purpose of this fork is to provide the Go community with an active
\nmaintenance and development target for Bolt; the goal is improved reliability
\nand stability. bbolt includes bug fixes, performance enhancements, and features
\nnot found in Bolt while preserving backwards compatibility with the Bolt API.

\n

Bolt is a pure Go key/value store inspired by Howard Chu's
\nLMDB project. The goal of the project is to provide a simple,
\nfast, and reliable database for projects that don't require a full database
\nserver such as Postgres or MySQL.

\n

Since Bolt is meant to be used as such a low-level piece of functionality,
\nsimplicity is key. The API will be small and only focus on getting values
\nand setting values. That's it.

\n

Project Status

\n

Bolt is stable, the API is fixed, and the file format is fixed. Full unit
\ntest coverage and randomized black box testing are used to ensure database
\nconsistency and thread safety. Bolt is currently used in high-load production
\nenvironments serving databases as large as 1TB. Many companies such as
\nShopify and Heroku use Bolt-backed services every day.

\n

Project versioning

\n

bbolt uses semantic versioning.
\nAPI should not change between patch and minor releases.
\nNew minor versions may add additional features to the API.

\n

Table of Contents

\n\n

Getting Started

\n

Installing

\n

To start using bbolt, install Go and run go get:

\n
$ go get go.etcd.io/bbolt@latest
\n

This will retrieve the library and update your go.mod and go.sum files.

\n

To run the command line utility, execute:

\n
$ go run go.etcd.io/bbolt/cmd/bbolt@latest
\n

Run go install to install the bbolt command line utility into
\nyour $GOBIN path, which defaults to $GOPATH/bin or $HOME/go/bin if the
\nGOPATH environment variable is not set.

\n
$ go install go.etcd.io/bbolt/cmd/bbolt@latest
\n

Importing bbolt

\n

To use bbolt as an embedded key-value store, import as:

\n
import bolt \"go.etcd.io/bbolt\"\n\ndb, err := bolt.Open(path, 0600, nil)\nif err != nil {\n  return err\n}\ndefer db.Close()
\n

Opening a database

\n

The top-level object in Bolt is a DB. It is represented as a single file on
\nyour disk and represents a consistent snapshot of your data.

\n

To open your database, simply use the bolt.Open() function:

\n
package main\n\nimport (\n\t\"log\"\n\n\tbolt \"go.etcd.io/bbolt\"\n)\n\nfunc main() {\n\t// Open the my.db data file in your current directory.\n\t// It will be created if it doesn't exist.\n\tdb, err := bolt.Open(\"my.db\", 0600, nil)\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n\tdefer db.Close()\n\n\t...\n}
\n

Please note that Bolt obtains a file lock on the data file so multiple processes
\ncannot open the same database at the same time. Opening an already open Bolt
\ndatabase will cause it to hang until the other process closes it. To prevent
\nan indefinite wait you can pass a timeout option to the Open() function:

\n
db, err := bolt.Open(\"my.db\", 0600, &bolt.Options{Timeout: 1 * time.Second})
\n

Transactions

\n

Bolt allows only one read-write transaction at a time but allows as many
\nread-only transactions as you want at a time. Each transaction has a consistent
\nview of the data as it existed when the transaction started.

\n

Individual transactions and all objects created from them (e.g. buckets, keys)
\nare not thread safe. To work with data in multiple goroutines you must start
\na transaction for each one or use locking to ensure only one goroutine accesses
\na transaction at a time. Creating transaction from the DB is thread safe.

\n

Transactions should not depend on one another and generally shouldn't be opened
\nsimultaneously in the same goroutine. This can cause a deadlock as the read-write
\ntransaction needs to periodically re-map the data file but it cannot do so while
\nany read-only transaction is open. Even a nested read-only transaction can cause
\na deadlock, as the child transaction can block the parent transaction from releasing
\nits resources.

\n

Read-write transactions

\n

To start a read-write transaction, you can use the DB.Update() function:

\n
err := db.Update(func(tx *bolt.Tx) error {\n\t...\n\treturn nil\n})
\n

Inside the closure, you have a consistent view of the database. You commit the
\ntransaction by returning nil at the end. You can also rollback the transaction
\nat any point by returning an error. All database operations are allowed inside
\na read-write transaction.

\n

Always check the return error as it will report any disk failures that can cause
\nyour transaction to not complete. If you return an error within your closure
\nit will be passed through.

\n

Read-only transactions

\n

To start a read-only transaction, you can use the DB.View() function:

\n
err := db.View(func(tx *bolt.Tx) error {\n\t...\n\treturn nil\n})
\n

You also get a consistent view of the database within this closure, however,
\nno mutating operations are allowed within a read-only transaction. You can only
\nretrieve buckets, retrieve values, and copy the database within a read-only
\ntransaction.

\n

Batch read-write transactions

\n

Each DB.Update() waits for disk to commit the writes. This overhead
\ncan be minimized by combining multiple updates with the DB.Batch()
\nfunction:

\n
err := db.Batch(func(tx *bolt.Tx) error {\n\t...\n\treturn nil\n})
\n

Concurrent Batch calls are opportunistically combined into larger
\ntransactions. Batch is only useful when there are multiple goroutines
\ncalling it.

\n

The trade-off is that Batch can call the given
\nfunction multiple times, if parts of the transaction fail. The
\nfunction must be idempotent and side effects must take effect only
\nafter a successful return from DB.Batch().

\n

For example: don't display messages from inside the function, instead
\nset variables in the enclosing scope:

\n
var id uint64\nerr := db.Batch(func(tx *bolt.Tx) error {\n\t// Find last key in bucket, decode as bigendian uint64, increment\n\t// by one, encode back to []byte, and add new key.\n\t...\n\tid = newValue\n\treturn nil\n})\nif err != nil {\n\treturn ...\n}\nfmt.Println(\"Allocated ID %d\", id)
\n

Managing transactions manually

\n

The DB.View() and DB.Update() functions are wrappers around the DB.Begin()
\nfunction. These helper functions will start the transaction, execute a function,
\nand then safely close your transaction if an error is returned. This is the
\nrecommended way to use Bolt transactions.

\n

However, sometimes you may want to manually start and end your transactions.
\nYou can use the DB.Begin() function directly but please be sure to close
\nthe transaction.

\n
// Start a writable transaction.\ntx, err := db.Begin(true)\nif err != nil {\n    return err\n}\ndefer tx.Rollback()\n\n// Use the transaction...\n_, err := tx.CreateBucket([]byte(\"MyBucket\"))\nif err != nil {\n    return err\n}\n\n// Commit the transaction and check for error.\nif err := tx.Commit(); err != nil {\n    return err\n}
\n

The first argument to DB.Begin() is a boolean stating if the transaction
\nshould be writable.

\n

Using buckets

\n

Buckets are collections of key/value pairs within the database. All keys in a
\nbucket must be unique. You can create a bucket using the Tx.CreateBucket()
\nfunction:

\n
db.Update(func(tx *bolt.Tx) error {\n\tb, err := tx.CreateBucket([]byte(\"MyBucket\"))\n\tif err != nil {\n\t\treturn fmt.Errorf(\"create bucket: %s\", err)\n\t}\n\treturn nil\n})
\n

You can retrieve an existing bucket using the Tx.Bucket() function:

\n
db.Update(func(tx *bolt.Tx) error {\n\tb := tx.Bucket([]byte(\"MyBucket\"))\n\tif b == nil {\n\t\treturn errors.New(\"bucket does not exist\")\n\t}\n\treturn nil\n})
\n

You can also create a bucket only if it doesn't exist by using the
\nTx.CreateBucketIfNotExists() function. It's a common pattern to call this
\nfunction for all your top-level buckets after you open your database so you can
\nguarantee that they exist for future transactions.

\n

To delete a bucket, simply call the Tx.DeleteBucket() function.

\n

You can also iterate over all existing top-level buckets with Tx.ForEach():

\n
db.View(func(tx *bolt.Tx) error {\n\ttx.ForEach(func(name []byte, b *bolt.Bucket) error {\n\t\tfmt.Println(string(name))\n\t\treturn nil\n\t})\n\treturn nil\n})
\n

Using key/value pairs

\n

To save a key/value pair to a bucket, use the Bucket.Put() function:

\n
db.Update(func(tx *bolt.Tx) error {\n\tb := tx.Bucket([]byte(\"MyBucket\"))\n\terr := b.Put([]byte(\"answer\"), []byte(\"42\"))\n\treturn err\n})
\n

This will set the value of the \"answer\" key to \"42\" in the MyBucket
\nbucket. To retrieve this value, we can use the Bucket.Get() function:

\n
db.View(func(tx *bolt.Tx) error {\n\tb := tx.Bucket([]byte(\"MyBucket\"))\n\tv := b.Get([]byte(\"answer\"))\n\tfmt.Printf(\"The answer is: %s\\n\", v)\n\treturn nil\n})
\n

The Get() function does not return an error because its operation is
\nguaranteed to work (unless there is some kind of system failure). If the key
\nexists then it will return its byte slice value. If it doesn't exist then it
\nwill return nil. It's important to note that you can have a zero-length value
\nset to a key which is different than the key not existing.

\n

Use the Bucket.Delete() function to delete a key from the bucket:

\n
db.Update(func (tx *bolt.Tx) error {\n    b := tx.Bucket([]byte(\"MyBucket\"))\n    err := b.Delete([]byte(\"answer\"))\n    return err\n})
\n

This will delete the key answers from the bucket MyBucket.

\n

Please note that values returned from Get() are only valid while the
\ntransaction is open. If you need to use a value outside of the transaction
\nthen you must use copy() to copy it to another byte slice.

\n

Autoincrementing integer for the bucket

\n

By using the NextSequence() function, you can let Bolt determine a sequence
\nwhich can be used as the unique identifier for your key/value pairs. See the
\nexample below.

\n
// CreateUser saves u to the store. The new user ID is set on u once the data is persisted.\nfunc (s *Store) CreateUser(u *User) error {\n    return s.db.Update(func(tx *bolt.Tx) error {\n        // Retrieve the users bucket.\n        // This should be created when the DB is first opened.\n        b := tx.Bucket([]byte(\"users\"))\n\n        // Generate ID for the user.\n        // This returns an error only if the Tx is closed or not writeable.\n        // That can't happen in an Update() call so I ignore the error check.\n        id, _ := b.NextSequence()\n        u.ID = int(id)\n\n        // Marshal user data into bytes.\n        buf, err := json.Marshal(u)\n        if err != nil {\n            return err\n        }\n\n        // Persist bytes to users bucket.\n        return b.Put(itob(u.ID), buf)\n    })\n}\n\n// itob returns an 8-byte big endian representation of v.\nfunc itob(v int) []byte {\n    b := make([]byte, 8)\n    binary.BigEndian.PutUint64(b, uint64(v))\n    return b\n}\n\ntype User struct {\n    ID int\n    ...\n}
\n

Iterating over keys

\n

Bolt stores its keys in byte-sorted order within a bucket. This makes sequential
\niteration over these keys extremely fast. To iterate over keys we'll use a
\nCursor:

\n
db.View(func(tx *bolt.Tx) error {\n\t// Assume bucket exists and has keys\n\tb := tx.Bucket([]byte(\"MyBucket\"))\n\n\tc := b.Cursor()\n\n\tfor k, v := c.First(); k != nil; k, v = c.Next() {\n\t\tfmt.Printf(\"key=%s, value=%s\\n\", k, v)\n\t}\n\n\treturn nil\n})
\n

The cursor allows you to move to a specific point in the list of keys and move
\nforward or backward through the keys one at a time.

\n

The following functions are available on the cursor:

\n
First()  Move to the first key.\nLast()   Move to the last key.\nSeek()   Move to a specific key.\nNext()   Move to the next key.\nPrev()   Move to the previous key.\n
\n

Each of those functions has a return signature of (key []byte, value []byte).
\nYou must seek to a position using First(), Last(), or Seek() before calling
\nNext() or Prev(). If you do not seek to a position then these functions will
\nreturn a nil key.

\n

When you have iterated to the end of the cursor, then Next() will return a
\nnil key and the cursor still points to the last element if present. When you
\nhave iterated to the beginning of the cursor, then Prev() will return a nil
\nkey and the cursor still points to the first element if present.

\n

If you remove key/value pairs during iteration, the cursor may automatically
\nmove to the next position if present in current node each time removing a key.
\nWhen you call c.Next() after removing a key, it may skip one key/value pair.
\nRefer to pull/611 to get more detailed info.

\n

During iteration, if the key is non-nil but the value is nil, that means
\nthe key refers to a bucket rather than a value. Use Bucket.Bucket() to
\naccess the sub-bucket.

\n

Prefix scans

\n

To iterate over a key prefix, you can combine Seek() and bytes.HasPrefix():

\n
db.View(func(tx *bolt.Tx) error {\n\t// Assume bucket exists and has keys\n\tc := tx.Bucket([]byte(\"MyBucket\")).Cursor()\n\n\tprefix := []byte(\"1234\")\n\tfor k, v := c.Seek(prefix); k != nil && bytes.HasPrefix(k, prefix); k, v = c.Next() {\n\t\tfmt.Printf(\"key=%s, value=%s\\n\", k, v)\n\t}\n\n\treturn nil\n})
\n

Range scans

\n

Another common use case is scanning over a range such as a time range. If you
\nuse a sortable time encoding such as RFC3339 then you can query a specific
\ndate range like this:

\n
db.View(func(tx *bolt.Tx) error {\n\t// Assume our events bucket exists and has RFC3339 encoded time keys.\n\tc := tx.Bucket([]byte(\"Events\")).Cursor()\n\n\t// Our time range spans the 90's decade.\n\tmin := []byte(\"1990-01-01T00:00:00Z\")\n\tmax := []byte(\"2000-01-01T00:00:00Z\")\n\n\t// Iterate over the 90's.\n\tfor k, v := c.Seek(min); k != nil && bytes.Compare(k, max) <= 0; k, v = c.Next() {\n\t\tfmt.Printf(\"%s: %s\\n\", k, v)\n\t}\n\n\treturn nil\n})
\n

Note that, while RFC3339 is sortable, the Golang implementation of RFC3339Nano does not use a fixed number of digits after the decimal point and is therefore not sortable.

\n

ForEach()

\n

You can also use the function ForEach() if you know you'll be iterating over
\nall the keys in a bucket:

\n
db.View(func(tx *bolt.Tx) error {\n\t// Assume bucket exists and has keys\n\tb := tx.Bucket([]byte(\"MyBucket\"))\n\n\tb.ForEach(func(k, v []byte) error {\n\t\tfmt.Printf(\"key=%s, value=%s\\n\", k, v)\n\t\treturn nil\n\t})\n\treturn nil\n})
\n

Please note that keys and values in ForEach() are only valid while
\nthe transaction is open. If you need to use a key or value outside of
\nthe transaction, you must use copy() to copy it to another byte
\nslice.

\n

Nested buckets

\n

You can also store a bucket in a key to create nested buckets. The API is the
\nsame as the bucket management API on the DB object:

\n
func (*Bucket) CreateBucket(key []byte) (*Bucket, error)\nfunc (*Bucket) CreateBucketIfNotExists(key []byte) (*Bucket, error)\nfunc (*Bucket) DeleteBucket(key []byte) error
\n

Say you had a multi-tenant application where the root level bucket was the account bucket. Inside of this bucket was a sequence of accounts which themselves are buckets. And inside the sequence bucket you could have many buckets pertaining to the Account itself (Users, Notes, etc) isolating the information into logical groupings.

\n
// createUser creates a new user in the given account.\nfunc createUser(accountID int, u *User) error {\n    // Start the transaction.\n    tx, err := db.Begin(true)\n    if err != nil {\n        return err\n    }\n    defer tx.Rollback()\n\n    // Retrieve the root bucket for the account.\n    // Assume this has already been created when the account was set up.\n    root := tx.Bucket([]byte(strconv.FormatUint(accountID, 10)))\n\n    // Setup the users bucket.\n    bkt, err := root.CreateBucketIfNotExists([]byte(\"USERS\"))\n    if err != nil {\n        return err\n    }\n\n    // Generate an ID for the new user.\n    userID, err := bkt.NextSequence()\n    if err != nil {\n        return err\n    }\n    u.ID = userID\n\n    // Marshal and save the encoded user.\n    if buf, err := json.Marshal(u); err != nil {\n        return err\n    } else if err := bkt.Put([]byte(strconv.FormatUint(u.ID, 10)), buf); err != nil {\n        return err\n    }\n\n    // Commit the transaction.\n    if err := tx.Commit(); err != nil {\n        return err\n    }\n\n    return nil\n}
\n

Database backups

\n

Bolt is a single file so it's easy to backup. You can use the Tx.WriteTo()
\nfunction to write a consistent view of the database to a writer. If you call
\nthis from a read-only transaction, it will perform a hot backup and not block
\nyour other database reads and writes.

\n

By default, it will use a regular file handle which will utilize the operating
\nsystem's page cache. See the Tx
\ndocumentation for information about optimizing for larger-than-RAM datasets.

\n

One common use case is to backup over HTTP so you can use tools like cURL to
\ndo database backups:

\n
func BackupHandleFunc(w http.ResponseWriter, req *http.Request) {\n\terr := db.View(func(tx *bolt.Tx) error {\n\t\tw.Header().Set(\"Content-Type\", \"application/octet-stream\")\n\t\tw.Header().Set(\"Content-Disposition\", `attachment; filename=\"my.db\"`)\n\t\tw.Header().Set(\"Content-Length\", strconv.Itoa(int(tx.Size())))\n\t\t_, err := tx.WriteTo(w)\n\t\treturn err\n\t})\n\tif err != nil {\n\t\thttp.Error(w, err.Error(), http.StatusInternalServerError)\n\t}\n}
\n

Then you can backup using this command:

\n
$ curl http://localhost/backup > my.db
\n

Or you can open your browser to http://localhost/backup and it will download
\nautomatically.

\n

If you want to backup to another file you can use the Tx.CopyFile() helper
\nfunction.

\n

Statistics

\n

The database keeps a running count of many of the internal operations it
\nperforms so you can better understand what's going on. By grabbing a snapshot
\nof these stats at two points in time we can see what operations were performed
\nin that time range.

\n

For example, we could start a goroutine to log stats every 10 seconds:

\n
go func() {\n\t// Grab the initial stats.\n\tprev := db.Stats()\n\n\tfor {\n\t\t// Wait for 10s.\n\t\ttime.Sleep(10 * time.Second)\n\n\t\t// Grab the current stats and diff them.\n\t\tstats := db.Stats()\n\t\tdiff := stats.Sub(&prev)\n\n\t\t// Encode stats to JSON and print to STDERR.\n\t\tjson.NewEncoder(os.Stderr).Encode(diff)\n\n\t\t// Save stats for the next loop.\n\t\tprev = stats\n\t}\n}()
\n

It's also useful to pipe these stats to a service such as statsd for monitoring
\nor to provide an HTTP endpoint that will perform a fixed-length sample.

\n

Read-Only Mode

\n

Sometimes it is useful to create a shared, read-only Bolt database. To this,
\nset the Options.ReadOnly flag when opening your database. Read-only mode
\nuses a shared lock to allow multiple processes to read from the database but
\nit will block any processes from opening the database in read-write mode.

\n
db, err := bolt.Open(\"my.db\", 0600, &bolt.Options{ReadOnly: true})\nif err != nil {\n\tlog.Fatal(err)\n}
\n

Mobile Use (iOS/Android)

\n

Bolt is able to run on mobile devices by leveraging the binding feature of the
\ngomobile tool. Create a struct that will
\ncontain your database logic and a reference to a *bolt.DB with a initializing
\nconstructor that takes in a filepath where the database file will be stored.
\nNeither Android nor iOS require extra permissions or cleanup from using this method.

\n
func NewBoltDB(filepath string) *BoltDB {\n\tdb, err := bolt.Open(filepath+\"/demo.db\", 0600, nil)\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n\n\treturn &BoltDB{db}\n}\n\ntype BoltDB struct {\n\tdb *bolt.DB\n\t...\n}\n\nfunc (b *BoltDB) Path() string {\n\treturn b.db.Path()\n}\n\nfunc (b *BoltDB) Close() {\n\tb.db.Close()\n}
\n

Database logic should be defined as methods on this wrapper struct.

\n

To initialize this struct from the native language (both platforms now sync
\ntheir local storage to the cloud. These snippets disable that functionality for the
\ndatabase file):

\n

Android

\n
String path;\nif (android.os.Build.VERSION.SDK_INT >=android.os.Build.VERSION_CODES.LOLLIPOP){\n    path = getNoBackupFilesDir().getAbsolutePath();\n} else{\n    path = getFilesDir().getAbsolutePath();\n}\nBoltmobiledemo.BoltDB boltDB = Boltmobiledemo.NewBoltDB(path)
\n

iOS

\n
- (void)demo {\n    NSString* path = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,\n                                                          NSUserDomainMask,\n                                                          YES) objectAtIndex:0];\n\tGoBoltmobiledemoBoltDB * demo = GoBoltmobiledemoNewBoltDB(path);\n\t[self addSkipBackupAttributeToItemAtPath:demo.path];\n\t//Some DB Logic would go here\n\t[demo close];\n}\n\n- (BOOL)addSkipBackupAttributeToItemAtPath:(NSString *) filePathString\n{\n    NSURL* URL= [NSURL fileURLWithPath: filePathString];\n    assert([[NSFileManager defaultManager] fileExistsAtPath: [URL path]]);\n\n    NSError *error = nil;\n    BOOL success = [URL setResourceValue: [NSNumber numberWithBool: YES]\n                                  forKey: NSURLIsExcludedFromBackupKey error: &error];\n    if(!success){\n        NSLog(@\"Error excluding %@ from backup %@\", [URL lastPathComponent], error);\n    }\n    return success;\n}\n
\n

Resources

\n

For more information on getting started with Bolt, check out the following articles:

\n\n

Comparison with other databases

\n

Postgres, MySQL, & other relational databases

\n

Relational databases structure data into rows and are only accessible through
\nthe use of SQL. This approach provides flexibility in how you store and query
\nyour data but also incurs overhead in parsing and planning SQL statements. Bolt
\naccesses all data by a byte slice key. This makes Bolt fast to read and write
\ndata by key but provides no built-in support for joining values together.

\n

Most relational databases (with the exception of SQLite) are standalone servers
\nthat run separately from your application. This gives your systems
\nflexibility to connect multiple application servers to a single database
\nserver but also adds overhead in serializing and transporting data over the
\nnetwork. Bolt runs as a library included in your application so all data access
\nhas to go through your application's process. This brings data closer to your
\napplication but limits multi-process access to the data.

\n

LevelDB, RocksDB

\n

LevelDB and its derivatives (RocksDB, HyperLevelDB) are similar to Bolt in that
\nthey are libraries bundled into the application, however, their underlying
\nstructure is a log-structured merge-tree (LSM tree). An LSM tree optimizes
\nrandom writes by using a write ahead log and multi-tiered, sorted files called
\nSSTables. Bolt uses a B+tree internally and only a single file. Both approaches
\nhave trade-offs.

\n

If you require a high random write throughput (>10,000 w/sec) or you need to use
\nspinning disks then LevelDB could be a good choice. If your application is
\nread-heavy or does a lot of range scans then Bolt could be a good choice.

\n

One other important consideration is that LevelDB does not have transactions.
\nIt supports batch writing of key/values pairs and it supports read snapshots
\nbut it will not give you the ability to do a compare-and-swap operation safely.
\nBolt supports fully serializable ACID transactions.

\n

LMDB

\n

Bolt was originally a port of LMDB so it is architecturally similar. Both use
\na B+tree, have ACID semantics with fully serializable transactions, and support
\nlock-free MVCC using a single writer and multiple readers.

\n

The two projects have somewhat diverged. LMDB heavily focuses on raw performance
\nwhile Bolt has focused on simplicity and ease of use. For example, LMDB allows
\nseveral unsafe actions such as direct writes for the sake of performance. Bolt
\nopts to disallow actions which can leave the database in a corrupted state. The
\nonly exception to this in Bolt is DB.NoSync.

\n

There are also a few differences in API. LMDB requires a maximum mmap size when
\nopening an mdb_env whereas Bolt will handle incremental mmap resizing
\nautomatically. LMDB overloads the getter and setter functions with multiple
\nflags whereas Bolt splits these specialized cases into their own functions.

\n

Caveats & Limitations

\n

It's important to pick the right tool for the job and Bolt is no exception.
\nHere are a few things to note when evaluating and using Bolt:

\n\n

Reading the Source

\n

Bolt is a relatively small code base (<5KLOC) for an embedded, serializable,
\ntransactional key/value database so it can be a good starting point for people
\ninterested in how databases work.

\n

The best places to start are the main entry points into Bolt:

\n\n

If you have additional notes that could be helpful for others, please submit
\nthem via pull request.

\n

Known Issues

\n\n

Other Projects Using Bolt

\n

Below is a list of public, open source projects that use Bolt:

\n\n

If you are using Bolt in a project please send a pull request to add it to the list.

","updatedAt":"2025-05-21T15:49:57Z","upvoteCount":null,"author":{"login":"eryajf","avatarUrl":"https://avatars.githubusercontent.com/u/33259379?u=e4a4090a38ac2473aaed4ef9945233636776c6c3&v=4","url":"https://github.com/eryajf"},"category":null,"labels":{"edges":[{"node":{"name":"更多","color":"25B472"}},{"node":{"name":"Database","color":"3fbc9d"}},{"node":{"name":"etcd-io","color":"5a1fed"}}]},"comments":{"edges":[]}}},"pageContext":{"number":46,"previous":{"title":"sharkdp/bat: 类似 cat 命令，但带有 git 集成和语法高亮.","number":45},"next":{"title":"elastic/beats: Elasticsearch 和 Logstash 的轻量级传输器","number":47}}}, "staticQueryHashes": ["151096407","2861350382"]}