commit | 05d858a829fa91fdf49d333e6984f2aca76e543e | [log] [tgz] |
---|---|---|
author | Gao Hongtao <hanahmily@gmail.com> | Wed Aug 10 12:00:09 2022 +0800 |
committer | GitHub <noreply@github.com> | Wed Aug 10 12:00:09 2022 +0800 |
tree | 6531fc352e045aacbd4755ec06c908d215ec54f8 | |
parent | 4391412ba4f79e9b614e145a8f61fe7acc60d49e [diff] |
Parameterize memory size and some key improvements (#153) * Parameterize memory size * Fix checking failure * Extract default values as several constants * Print strategy manager state after testing * Add a mock clock trigger to send the "now" to "ticker.C" in each verification round * Update LICENSE Signed-off-by: Gao Hongtao <hanahmily@gmail.com>
BanyanDB, as an observability database, aims to ingest, analyze and store Metrics, Tracing and Logging data. It's designed to handle observability data generated by observability platform and APM system, like Apache SkyWalking etc.
BanyanDB, as an observability database, aims to ingest, analyze and store Metrics, Tracing, and Logging data. It's designed to handle observability data generated by Apache SkyWalking. Before BanyanDB emerges, the Databases that SkyWalking adopted are not ideal for the APM data model, especially for saving tracing and logging data. Consequently, There’s room to improve the performance and resource usage based on the nature of SkyWalking data patterns.
The database research community usually uses RUM conjecture to describe how a database access data. BanyanDB combines several access methods to build a comprehensive APM database to balance read cost, update cost, and memory overhead.
For developers who want to contribute to this project, see Contribution Guide