Skip to content

Latest commit

 

History

History
 
 

go

README.md

title
Go

This file is generated by /src/clients/docs_generate.zig.

tigerbeetle-go

The TigerBeetle client for Go.

Go Reference

Make sure to import github.com/tigerbeetledb/tigerbeetle-go, not this repo and subdirectory.

Prerequisites

Linux >= 5.6 is the only production environment we support. But for ease of development we also support macOS and Windows.

  • Go >= 1.17

Additionally on Windows: you must install Zig 0.9.1 and set the CC environment variable to zig.exe cc. Use the full path for zig.exe.

Setup

First, create a directory for your project and cd into the directory.

Then, install the TigerBeetle client:

$ go mod init tbtest
$ go mod tidy

Now, create main.go and copy this into it:

package main

import _ "github.com/tigerbeetledb/tigerbeetle-go"
import "fmt"

func main() {
	fmt.Println("Import ok!")
}

Finally, build and run:

$ go run main.go

Now that all prerequisites and dependencies are correctly set up, let's dig into using TigerBeetle.

Sample projects

This document is primarily a reference guide to the client. Below are various sample projects demonstrating features of TigerBeetle.

  • Basic: Create two accounts and transfer an amount between them.
  • Two-Phase Transfer: Create two accounts and start a pending transfer between them, then post the transfer.

Sidenote: uint128

Throughout this README there will be a reference to a helper, uint128, that converts a string to TigerBeetle's representation of a 128-bit integer. That helper can be defined like so:

func uint128(value string) tb_types.Uint128 {
	x, err := tb_types.HexStringToUint128(value)
	if err != nil {
		panic(err)
	}
	return x
}

Creating a Client

A client is created with a cluster ID and replica addresses for all replicas in the cluster. The cluster ID and replica addresses are both chosen by the system that starts the TigerBeetle cluster.

Clients are thread-safe. But for better performance, a single instance should be shared between multiple concurrent tasks.

Multiple clients are useful when connecting to more than one TigerBeetle cluster.

In this example the cluster ID is 0 and there is one replica. The address is read from the TB_ADDRESS environment variable and defaults to port 3000.

tbAddress := os.Getenv("TB_ADDRESS")
if len(tbAddress) == 0 {
  tbAddress = "3000"
} 
client, err := tb.NewClient(0, []string{tbAddress}, 32)
if err != nil {
	log.Printf("Error creating client: %s", err)
	return
}
defer client.Close()

The third argument to NewClient is a uint max concurrency setting. 32 is a good default and can increase to 4096 as you need increased throughput.

The following are valid addresses:

  • 3000 (interpreted as 127.0.0.1:3000)
  • 127.0.0.1:3000 (interpreted as 127.0.0.1:3000)
  • 127.0.0.1 (interpreted as 127.0.0.1:3001, 3001 is the default port)

Creating Accounts

See details for account fields in the Accounts reference.

accountsRes, err := client.CreateAccounts([]tb_types.Account{
	{
		ID:     	uint128("137"),
		UserData:	tb_types.Uint128{},
		Reserved:   	[48]uint8{},
		Ledger:		1,
		Code:   	718,
		Flags:   	0,
		DebitsPending: 	0,
		DebitsPosted: 	0,
		CreditsPending:	0,
		CreditsPosted: 	0,
		Timestamp: 	0,
	},
})
if err != nil {
	log.Printf("Error creating accounts: %s", err)
	return
}

for _, err := range accountsRes {
	log.Printf("Error creating account %d: %s", err.Index, err.Result)
	return
}

The tb_types package can be imported from "github.com/tigerbeetledb/tigerbeetle-go/pkg/types".

Account Flags

The account flags value is a bitfield. See details for these flags in the Accounts reference.

To toggle behavior for an account, use the tb_types.AccountFlags struct to combine enum values and generate a uint16. Here are a few examples:

  • tb_types.AccountFlags{Linked: true}.ToUint16()
  • tb_types.AccountFlags{DebitsMustNotExceedCredits: true}.ToUint16()
  • tb_types.AccountFlags{CreditsMustNotExceedDebits: true}.ToUint16()

For example, to link two accounts where the first account additionally has the debits_must_not_exceed_credits constraint:

account0 := tb_types.Account{ /* ... account values ... */ }
account1 := tb_types.Account{ /* ... account values ... */ }
account0.Flags = tb_types.AccountFlags{Linked: true}.ToUint16()

accountErrors, err := client.CreateAccounts([]tb_types.Account{account0, account1})
if err != nil {
	log.Printf("Error creating accounts: %s", err)
	return
}

Response and Errors

The response is an empty array if all accounts were created successfully. If the response is non-empty, each object in the response array contains error information for an account that failed. The error object contains an error code and the index of the account in the request batch.

See all error conditions in the create_accounts reference.

account2 := tb_types.Account{ /* ... account values ... */ }
account3 := tb_types.Account{ /* ... account values ... */ }
account4 := tb_types.Account{ /* ... account values ... */ }

accountErrors, err = client.CreateAccounts([]tb_types.Account{account2, account3, account4})
if err != nil {
	log.Printf("Error creating accounts: %s", err)
	return
}
for _, err := range accountErrors {
	log.Printf("Error creating account %d: %s", err.Index, err.Result)
	return
}

To handle errors you can either 1) exactly match error codes returned from client.createAccounts with enum values in the CreateAccountError object, or you can 2) look up the error code in the CreateAccountError object for a human-readable string.

Account Lookup

Account lookup is batched, like account creation. Pass in all IDs to fetch. The account for each matched ID is returned.

If no account matches an ID, no object is returned for that account. So the order of accounts in the response is not necessarily the same as the order of IDs in the request. You can refer to the ID field in the response to distinguish accounts.

accounts, err := client.LookupAccounts([]tb_types.Uint128{uint128("137"), uint128("138")})
if err != nil {
	log.Printf("Could not fetch accounts: %s", err)
	return
}
log.Println(accounts)

Create Transfers

This creates a journal entry between two accounts.

See details for transfer fields in the Transfers reference.

transfer := tb_types.Transfer{
	ID:			uint128("1"),
	PendingID:		tb_types.Uint128{},
	DebitAccountID:		uint128("1"),
	CreditAccountID:	uint128("2"),
	UserData:		uint128("2"),
	Reserved:		tb_types.Uint128{},
	Timeout:		0,
	Ledger:			1,
	Code:			1,
	Flags:			0,
	Amount:			10,
	Timestamp:		0,
}

transfersRes, err := client.CreateTransfers([]tb_types.Transfer{transfer})
if err != nil {
	log.Printf("Error creating transfer batch: %s", err)
	return
}

Response and Errors

The response is an empty array if all transfers were created successfully. If the response is non-empty, each object in the response array contains error information for an transfer that failed. The error object contains an error code and the index of the transfer in the request batch.

See all error conditions in the create_transfers reference.

for _, err := range transfersRes {
	log.Printf("Batch transfer at %d failed to create: %s", err.Index, err.Result)
	return
}

Batching

TigerBeetle performance is maximized when you batch API requests. The client does not do this automatically for you. So, for example, you can insert 1 million transfers one at a time like so:

for i := 0; i < len(transfers); i++ {
	errors := client.CreateTransfers(transfers[i]);
	// error handling omitted
}

But the insert rate will be a fraction of potential. Instead, always batch what you can.

The maximum batch size is set in the TigerBeetle server. The default is 8191.

BATCH_SIZE := 8191
for i := 0; i < len(transfers); i += BATCH_SIZE {
	batch := BATCH_SIZE
	if i + BATCH_SIZE > len(transfers) {
		i = BATCH_SIZE - i
	}
	transfersRes, err := client.CreateTransfers(transfers[i:i + batch])
	// error handling omitted
}

Queues and Workers

If you are making requests to TigerBeetle from workers pulling jobs from a queue, you can batch requests to TigerBeetle by having the worker act on multiple jobs from the queue at once rather than one at a time. i.e. pulling multiple jobs from the queue rather than just one.

Transfer Flags

The transfer flags value is a bitfield. See details for these flags in the Transfers reference.

To toggle behavior for an account, use the tb_types.TransferFlags struct to combine enum values and generate a uint16. Here are a few examples:

  • tb_types.TransferFlags{Linked: true}.ToUint16()
  • tb_types.TransferFlags{Pending: true}.ToUint16()
  • tb_types.TransferFlags{PostPendingTransfer: true}.ToUint16()
  • tb_types.TransferFlags{VoidPendingTransfer: true}.ToUint16()

For example, to link transfer0 and transfer1:

transfer0 := tb_types.Transfer{ /* ... account values ... */ }
transfer1 := tb_types.Transfer{ /* ... account values ... */ }
transfer0.Flags = tb_types.TransferFlags{Linked: true}.ToUint16()
transfersRes, err = client.CreateTransfers([]tb_types.Transfer{transfer0, transfer1})

Two-Phase Transfers

Two-phase transfers are supported natively by toggling the appropriate flag. TigerBeetle will then adjust the credits_pending and debits_pending fields of the appropriate accounts. A corresponding post pending transfer then needs to be sent to post or void the transfer.

Post a Pending Transfer

With flags set to post_pending_transfer, TigerBeetle will post the transfer. TigerBeetle will atomically roll back the changes to debits_pending and credits_pending of the appropriate accounts and apply them to the debits_posted and credits_posted balances.

transfer = tb_types.Transfer{
	ID:		uint128("2"),
	PendingID:	uint128("1"),
	Flags:		tb_types.TransferFlags{PostPendingTransfer: true}.ToUint16(),
	Timestamp:	0,
}
transfersRes, err = client.CreateTransfers([]tb_types.Transfer{transfer})

Void a Pending Transfer

In contrast, with flags set to void_pending_transfer, TigerBeetle will void the transfer. TigerBeetle will roll back the changes to debits_pending and credits_pending of the appropriate accounts and not apply them to the debits_posted and credits_posted balances.

transfer = tb_types.Transfer{
	ID:		uint128("2"),
	PendingID:	uint128("1"),
	Flags:		tb_types.TransferFlags{VoidPendingTransfer: true}.ToUint16(),
	Timestamp:	0,
}
transfersRes, err = client.CreateTransfers([]tb_types.Transfer{transfer})
log.Println(transfersRes, err)

Transfer Lookup

NOTE: While transfer lookup exists, it is not a flexible query API. We are developing query APIs and there will be new methods for querying transfers in the future.

Transfer lookup is batched, like transfer creation. Pass in all ids to fetch, and matched transfers are returned.

If no transfer matches an id, no object is returned for that transfer. So the order of transfers in the response is not necessarily the same as the order of ids in the request. You can refer to the id field in the response to distinguish transfers.

transfers, err := client.LookupTransfers([]tb_types.Uint128{uint128("1"), uint128("2")})
if err != nil {
	log.Printf("Could not fetch transfers: %s", err)
	return
}
log.Println(transfers)

Linked Events

When the linked flag is specified for an account when creating accounts or a transfer when creating transfers, it links that event with the next event in the batch, to create a chain of events, of arbitrary length, which all succeed or fail together. The tail of a chain is denoted by the first event without this flag. The last event in a batch may therefore never have the linked flag set as this would leave a chain open-ended. Multiple chains or individual events may coexist within a batch to succeed or fail independently.

Events within a chain are executed within order, or are rolled back on error, so that the effect of each event in the chain is visible to the next, and so that the chain is either visible or invisible as a unit to subsequent events after the chain. The event that was the first to break the chain will have a unique error result. Other events in the chain will have their error result set to linked_event_failed.

batch := []tb_types.Transfer{}
linkedFlag := tb_types.TransferFlags{Linked: true}.ToUint16()

// An individual transfer (successful):
batch = append(batch, tb_types.Transfer{ID: uint128("1"), /* ... */ })

// A chain of 4 transfers (the last transfer in the chain closes the chain with linked=false):
batch = append(batch, tb_types.Transfer{ID: uint128("2"), /* ... , */ Flags: linkedFlag }) // Commit/rollback.
batch = append(batch, tb_types.Transfer{ID: uint128("3"), /* ... , */ Flags: linkedFlag }) // Commit/rollback.
batch = append(batch, tb_types.Transfer{ID: uint128("2"), /* ... , */ Flags: linkedFlag }) // Fail with exists
batch = append(batch, tb_types.Transfer{ID: uint128("4"), /* ... , */ }) // Fail without committing

// An individual transfer (successful):
// This should not see any effect from the failed chain above.
batch = append(batch, tb_types.Transfer{ID: uint128("2"), /* ... */ })

// A chain of 2 transfers (the first transfer fails the chain):
batch = append(batch, tb_types.Transfer{ID: uint128("2"), /* ... */ Flags: linkedFlag })
batch = append(batch, tb_types.Transfer{ID: uint128("3"), /* ... */ })

// A chain of 2 transfers (successful):
batch = append(batch, tb_types.Transfer{ID: uint128("3"), /* ... */ Flags: linkedFlag })
batch = append(batch, tb_types.Transfer{ID: uint128("4"), /* ... */ })

transfersRes, err = client.CreateTransfers(batch)
log.Println(transfersRes, err)

Development Setup

On Linux and macOS

In a POSIX shell run:

$ git clone https://github.com/tigerbeetledb/tigerbeetle
$ cd tigerbeetle
$ git submodule update --init --recursive
$ ./scripts/install_zig.sh
$ ./scripts/build.sh go_client -Drelease-safe
$ cd src/clients/go
$ if [ "$TEST" = "true" ]; then go test; else echo "Skipping client unit tests"; fi

On Windows

In PowerShell run:

$ git clone https://github.com/tigerbeetledb/tigerbeetle
$ cd tigerbeetle
$ git submodule update --init --recursive
$ .\scripts\install_zig.bat
$ .\scripts\build.bat go_client -Drelease-safe
$ cd src\clients\go
$ if ($env:TEST -eq 'true') { go test } else { echo "Skipping client unit test" }