XuperUnion-master.zip

# BadgerDB [](https://godoc.org/github.com/dgraph-io/badger) [](https://goreportcard.com/report/github.com/dgraph-io/badger) [](https://sourcegraph.com/github.com/dgraph-io/badger?badge) [/statusIcon.svg)](https://teamcity.dgraph.io/viewLog.html?buildTypeId=Badger_UnitTests&buildId=lastFinished&guest=1)  [](https://coveralls.io/github/dgraph-io/badger?branch=master)  BadgerDB is an embeddable, persistent and fast key-value (KV) database written in pure Go. It's meant to be a performant alternative to non-Go-based key-value stores like [RocksDB](https://github.com/facebook/rocksdb). ## Project Status [Oct 27, 2018] Badger is stable and is being used to serve data sets worth hundreds of terabytes. Badger supports concurrent ACID transactions with serializable snapshot isolation (SSI) guarantees. A Jepsen-style bank test runs nightly for 8h, with `--race` flag and ensures maintainance of transactional guarantees. Badger has also been tested to work with filesystem level anomalies, to ensure persistence and consistency. Badger v1.0 was released in Nov 2017, with a Badger v2.0 release coming up in a few months. The [Changelog] is kept fairly up-to-date. [Changelog]:https://github.com/dgraph-io/badger/blob/master/CHANGELOG.md ## Table of Contents * [Getting Started](#getting-started) + [Installing](#installing) + [Opening a database](#opening-a-database) + [Transactions](#transactions) - [Read-only transactions](#read-only-transactions) - [Read-write transactions](#read-write-transactions) - [Managing transactions manually](#managing-transactions-manually) + [Using key/value pairs](#using-keyvalue-pairs) + [Monotonically increasing integers](#monotonically-increasing-integers) * [Merge Operations](#merge-operations) + [Setting Time To Live(TTL) and User Metadata on Keys](#setting-time-to-livettl-and-user-metadata-on-keys) + [Iterating over keys](#iterating-over-keys) - [Prefix scans](#prefix-scans) - [Key-only iteration](#key-only-iteration) + [Stream](#stream) + [Garbage Collection](#garbage-collection) + [Database backup](#database-backup) + [Memory usage](#memory-usage) + [Statistics](#statistics) * [Resources](#resources) + [Blog Posts](#blog-posts) * [Contact](#contact) * [Design](#design) + [Comparisons](#comparisons) + [Benchmarks](#benchmarks) * [Other Projects Using Badger](#other-projects-using-badger) * [Frequently Asked Questions](#frequently-asked-questions) ## Getting Started ### Installing To start using Badger, install Go 1.11 or above and run `go get`: ```sh $ go get github.com/dgraph-io/badger/v2/... ``` This will retrieve the library and install the `badger` command line utility into your `$GOBIN` path. ### Opening a database The top-level object in Badger is a `DB`. It represents multiple files on disk in specific directories, which contain the data for a single database. To open your database, use the `badger.Open()` function, with the appropriate options. The `Dir` and `ValueDir` options are mandatory and must be specified by the client. They can be set to the same value to simplify things. ```go package main import ( "log" badger "github.com/dgraph-io/badger/v2" ) func main() { // Open the Badger database located in the /tmp/badger directory. // It will be created if it doesn't exist. opts := badger.DefaultOptions opts.Dir = "/tmp/badger" opts.ValueDir = "/tmp/badger" db, err := badger.Open(opts) if err != nil { log.Fatal(err) } defer db.Close()  // Your code here… } ``` Please note that Badger obtains a lock on the directories so multiple processes cannot open the same database at the same time. ### Transactions #### Read-only transactions To start a read-only transaction, you can use the `DB.View()` method: ```go err := db.View(func(txn *badger.Txn) error {  // Your code here…  return nil }) ``` You cannot perform any writes or deletes within this transaction. Badger ensures that you get a consistent view of the database within this closure. Any writes that happen elsewhere after the transaction has started, will not be seen by calls made within the closure. #### Read-write transactions To start a read-write transaction, you can use the `DB.Update()` method: ```go err := db.Update(func(txn *badger.Txn) error {  // Your code here…  return nil }) ``` All database operations are allowed inside a read-write transaction. Always check the returned error value. If you return an error within your closure it will be passed through. An `ErrConflict` error will be reported in case of a conflict. Depending on the state of your application, you have the option to retry the operation if you receive this error. An `ErrTxnTooBig` will be reported in case the number of pending writes/deletes in the transaction exceed a certain limit. In that case, it is best to commit the transaction and start a new transaction immediately. Here is an example (we are not checking for errors in some places for simplicity): ```go updates := make(map[string]string) txn := db.NewTransaction(true) for k,v := range updates { if err := txn.Set([]byte(k),[]byte(v)); err == ErrTxnTooBig { _ = txn.Commit() txn = db.NewTransaction(true) _ = txn.Set([]byte(k),[]byte(v)) } } _ = txn.Commit() ``` #### Managing transactions manually The `DB.View()` and `DB.Update()` methods are wrappers around the `DB.NewTransaction()` and `Txn.Commit()` methods (or `Txn.Discard()` in case of read-only transactions). These helper methods will start the transaction, execute a function, and then safely discard your transaction if an error is returned. This is the recommended way to use Badger transactions. However, sometimes you may want to manually create and commit your transactions. You can use the `DB.NewTransaction()` function directly, which takes in a boolean argument to specify whether a read-write transaction is required. For read-write transactions, it is necessary to call `Txn.Commit()` to ensure the transaction is committed. For read-only transactions, calling `Txn.Discard()` is sufficient. `Txn.Commit()` also calls `Txn.Discard()` internally to cleanup the transaction, so just calling `Txn.Commit()` is sufficient for read-write transaction. However, if your code doesn’t call `Txn.Commit()` for some reason (for e.g it returns prematurely with an error), then please make sure you call `Txn.Discard()` in a `defer` block. Refer to the code below. ```go // Start a writable transaction. txn := db.NewTransaction(true) defer txn.Discard() // Use the transaction... err := txn.Set([]byte("answer"), []byte("42")) if err != nil { return err } // Commit the transaction and check for error. if err := txn.Commit(); err != nil { return err } ``` The first argument to `DB.NewTransaction()` is a boolean stating if the transaction should be writable. Badger allows an optional callback to the `Txn.Commit()` method. Normally, the callback can be set to `nil`, and the method will return after all the writes have succeeded. However, if this callback is provided, the `Txn.Commit()` method returns as soon as it has checked for any conflicts. The actual writing to the disk happens asynchronously, and the callback is invoked once the writing has finished, or an error has occurred. This can improve the throughput of the application in some cases. But it also m