Go to file
Ray Jenkins bb9b9d2471
OpenTelemetry API Tracing. (#6478)
* OTEL Span Implementation.

* Addi trace logging, refactor constructors, unit tests.

* Unit tests for creating OTELSpans

* refactor flag names

* Additional comments.

* Formatting.

* Add back Arena.h include

* cleanup header includes

* Remove include cstddef.

* Remove memory include.

* Remove trailing commas on enums.

* Enum formatting.

* Changing SpanStatus enum from ERROR to ERR to see if it is clashing with Windows.h.

* Move OTELEvents to SmallVectorRef<KeyValueRef>.

* Clean up unused includes.

* Unit tests

* Const reference arguments for OTEL constructors and additional addAttribute
unit tests. Adding return of OTELSpan reference on addAttribute.

* Formatting.

* Begin messagepack encoding tests.

* Formatting.

* MessagePack encoding unit tests.

* Formatting.

* Remove swapBinary.

* remove ambiguous helper methods

* Formatting fixes

* Fix ambiguous calls in AddEvents unit tests.

* Include AddAttributes unit test.

* descope windows for UDP encoding test

* Move ifndef WIN32 around MPEncoding unit test.

* Fix AddEvents Attributes size assertion.

* Formatting.

* Enable AddLinks unit test.

* Full MP encoding testing.

* Fix for encoding longer strings with MessagePack and unit test.

* Remove unnecessary header includes and serialize_string_ref function.

* Fix typos

* Update flow/Tracing.actor.cpp

Co-authored-by: Lukas Joswiak <lukas.joswiak@snowflake.com>

* Update flow/Tracing.actor.cpp

Co-authored-by: Lukas Joswiak <lukas.joswiak@snowflake.com>

* Use ASSERT_WE_THINK and add logging.

We don't want people creating incredibly large traces, so we are only
supporting a subset of MessagePack collection and string sizes. Assert
and log when we hit these unsupported sizes.

* Remove TODOs no longer applicable.

* Refactor OTELEvent to OTELEventRef.

* Remove unnecessary public declaration in struct.

* fix OTELEventRef attribute size assertion

* Formatting

Co-authored-by: Lukas Joswiak <lukas.joswiak@snowflake.com>
2022-04-04 17:55:38 -07:00
FDBLibTLS Update copyright header dates 2022-03-21 13:36:23 -07:00
bindings Remote ikvs debugging (#6465) 2022-03-31 17:08:59 -07:00
cmake Build AWS SDK as part of FDB, and use it to acquire blob credentials. This supports IAM role-based authentication, in addition to all existing credential types. 2022-03-24 10:09:06 -05:00
contrib Tenant binding tester support (#6642) 2022-03-23 13:57:45 -07:00
design FDB Encryption data at-rest design documentation (#6629) 2022-03-28 16:37:00 -07:00
documentation Add a note that opening a tenant does not check whether that tenant exists in the cluster 2022-03-31 11:39:50 -07:00
fdbbackup Add a check on proxy format. 2022-03-29 10:17:14 -07:00
fdbcli Merge pull request #6709 from sfc-gh-ajbeamon/fix-fdbcli-bugs 2022-03-30 19:53:49 -07:00
fdbclient OpenTelemetry API Tracing. (#6478) 2022-04-04 17:55:38 -07:00
fdbkubernetesmonitor Unify flags (#25) 2021-12-14 08:44:39 -08:00
fdbmonitor fix cmake bug when use gcc 2022-03-30 23:21:22 -07:00
fdbrpc Add DNS cache. 2022-04-04 15:08:17 -07:00
fdbserver Fix the bug where use the pointer after it's cleaned 2022-04-04 11:49:41 -07:00
fdbservice Update copyright header dates 2022-03-21 13:36:23 -07:00
flow OpenTelemetry API Tracing. (#6478) 2022-04-04 17:55:38 -07:00
flowbench Update copyright header dates 2022-03-21 13:36:23 -07:00
layers Fix comments to use transaction_too_old instead of past_version 2019-04-24 18:50:57 -07:00
packaging Update copyright header dates 2022-03-21 13:36:23 -07:00
recipes Fix go style issues 2022-02-03 20:48:19 -08:00
tests Remote ikvs debugging (#6465) 2022-03-31 17:08:59 -07:00
.clang-format apply clang-format to *.c, *.cpp, *.h, *.hpp files 2021-03-10 10:18:07 -08:00
.gitignore createdTime based storage wiggler (#6219) 2022-02-04 15:04:30 -08:00
ACKNOWLEDGEMENTS Add ACKNOWLEDGEMENTS. Replace memcpy with advsimd implementation. 2021-08-23 19:12:52 -07:00
CMakeLists.txt allow command line override of release canddiate version 2021-11-29 15:11:20 -08:00
CODE_OF_CONDUCT.md Updates markdown link to Contributor Covenant homepage in the Code of Conduct. 2018-04-18 01:08:55 -04:00
CONTRIBUTING.md Update CONTRIBUTING.md 2022-02-04 13:29:49 -06:00
LICENSE Initial repository commit 2017-05-25 13:48:44 -07:00
README.md Update README.md 2022-03-29 09:16:02 -07:00
fdb.cluster.cmake Fix port to match sandbox foundationdb.conf 2019-04-03 13:49:44 -07:00
pull_request_template.md Fix markdown 2021-03-15 20:03:20 -06:00
versions.target.cmake use FDB_VERSION in lieu of PROJECT_VERSION or CMAKE_PROJECT_VERSION 2021-11-29 15:11:20 -08:00

README.md

FoundationDB logo

Build Status

FoundationDB is a distributed database designed to handle large volumes of structured data across clusters of commodity servers. It organizes data as an ordered key-value store and employs ACID transactions for all operations. It is especially well-suited for read/write workloads but also has excellent performance for write-intensive workloads. Users interact with the database using API language binding.

To learn more about FoundationDB, visit foundationdb.org

Documentation

Documentation can be found online at https://apple.github.io/foundationdb/. The documentation covers details of API usage, background information on design philosophy, and extensive usage examples. Docs are built from the source in this repo.

Forums

The FoundationDB Forums are the home for most of the discussion and communication about the FoundationDB project. We welcome your participation! We want FoundationDB to be a great project to be a part of and, as part of that, have established a Code of Conduct to establish what constitutes permissible modes of interaction.

Contributing

Contributing to FoundationDB can be in contributions to the code base, sharing your experience and insights in the community on the Forums, or contributing to projects that make use of FoundationDB. Please see the contributing guide for more specifics.

Getting Started

Binary downloads

Developers interested in using FoundationDB can get started by downloading and installing a binary package. Please see the downloads page for a list of available packages.

Compiling from source

Developers on an OS for which there is no binary package, or who would like to start hacking on the code, can get started by compiling from source.

The official docker image for building is foundationdb/build which has all dependencies installed. The Docker image definitions used by FoundationDB team members can be found in the dedicated repository..

To build outside the official docker image you'll need at least these dependencies:

  1. Install cmake Version 3.13 or higher CMake
  2. Install Mono
  3. Install Ninja (optional, but recommended)

If compiling for local development, please set -DUSE_WERROR=ON in cmake. Our CI compiles with -Werror on, so this way you'll find out about compiler warnings that break the build earlier.

Once you have your dependencies, you can run cmake and then build:

  1. Check out this repository.
  2. Create a build directory (you can have the build directory anywhere you like). There is currently a directory in the source tree called build, but you should not use it. See #3098
  3. cd <PATH_TO_BUILD_DIRECTORY>
  4. cmake -G Ninja <PATH_TO_FOUNDATIONDB_DIRECTORY>
  5. ninja # If this crashes it probably ran out of memory. Try ninja -j1

Language Bindings

The language bindings that are supported by cmake will have a corresponding README.md file in the corresponding bindings/lang directory.

Generally, cmake will build all language bindings for which it can find all necessary dependencies. After each successful cmake run, cmake will tell you which language bindings it is going to build.

Generating compile_commands.json

CMake can build a compilation database for you. However, the default generated one is not too useful as it operates on the generated files. When running make, the build system will create another compile_commands.json file in the source directory. This can than be used for tools like CCLS, CQuery, etc. This way you can get code-completion and code navigation in flow. It is not yet perfect (it will show a few errors) but we are constantly working on improving the development experience.

CMake will not produce a compile_commands.json, you must pass -DCMAKE_EXPORT_COMPILE_COMMANDS=ON. This also enables the target processed_compile_commands, which rewrites compile_commands.json to describe the actor compiler source file, not the post-processed output files, and places the output file in the source directory. This file should then be picked up automatically by any tooling.

Note that if building inside of the foundationdb/build docker image, the resulting paths will still be incorrect and require manual fixing. One will wish to re-run cmake with -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF to prevent it from reverting the manual changes.

Using IDEs

CMake has built in support for a number of popular IDEs. However, because flow files are precompiled with the actor compiler, an IDE will not be very useful as a user will only be presented with the generated code - which is not what she wants to edit and get IDE features for.

The good news is, that it is possible to generate project files for editing flow with a supported IDE. There is a CMake option called OPEN_FOR_IDE which will generate a project which can be opened in an IDE for editing. You won't be able to build this project, but you will be able to edit the files and get most edit and navigation features your IDE supports.

For example, if you want to use XCode to make changes to FoundationDB you can create a XCode-project with the following command:

cmake -G Xcode -DOPEN_FOR_IDE=ON <FDB_SOURCE_DIRECTORY>

You should create a second build-directory which you will use for building and debugging.

FreeBSD

  1. Check out this repo on your server.

  2. Install compile-time dependencies from ports.

  3. (Optional) Use tmpfs & ccache for significantly faster repeat builds

  4. (Optional) Install a JDK for Java Bindings. FoundationDB currently builds with Java 8.

  5. Navigate to the directory where you checked out the foundationdb repo.

  6. Build from source.

    sudo pkg install -r FreeBSD \
        shells/bash devel/cmake devel/ninja devel/ccache  \
        lang/mono lang/python3 \
        devel/boost-libs devel/libeio \
        security/openssl
    mkdir .build && cd .build
    cmake -G Ninja \
        -DUSE_CCACHE=on \
        -DDISABLE_TLS=off \
        -DUSE_DTRACE=off \
        ..
    ninja -j 10
    # run fast tests
    ctest -L fast
    # run all tests
    ctest --output-on-failure -v
    

Linux

There are no special requirements for Linux. A docker image can be pulled from foundationdb/build that has all of FoundationDB's dependencies pre-installed, and is what the CI uses to build and test PRs.

cmake -G Ninja <FDB_SOURCE_DIR>
ninja
cpack -G DEB

For RPM simply replace DEB with RPM.

MacOS

The build under MacOS will work the same way as on Linux. To get boost and ninja you can use Homebrew.

cmake -G Ninja <PATH_TO_FOUNDATIONDB_SOURCE>

To generate a installable package,

ninja
$SRCDIR/packaging/osx/buildpkg.sh . $SRCDIR

Windows

Under Windows, only Visual Studio with ClangCl is supported

  1. Install Visual Studio 2019 (IDE or Build Tools), and enable llvm support
  2. Install CMake 3.15 or higher
  3. Download Boost 1.77.0
  4. Unpack boost to C:\boost, or use -DBOOST_ROOT=<PATH_TO_BOOST> with cmake if unpacked elsewhere
  5. Install Python if is not already installed by Visual Studio
  6. (Optional) Install OpenJDK 11 to build Java bindings
  7. (Optional) Install OpenSSL 3.x to build with TLS support
  8. (Optional) Install WIX Toolset to build Windows installer
  9. mkdir build && cd build
  10. cmake -G "Visual Studio 16 2019" -A x64 -T ClangCl <PATH_TO_FOUNDATIONDB_SOURCE>
  11. msbuild /p:Configuration=Release foundationdb.sln
  12. To increase build performance, use /p:UseMultiToolTask=true and /p:CL_MPCount=<NUMBER_OF_PARALLEL_JOBS>