Bleve has count facets only: no metric and no nested facet. So far a metric or a sub-aggregation widened the page to every match and loaded all stored fields of each, then folded the hits in Go. The stored document, extracted text included, was decoded for every match: about 1s and 780MB per 100k matches, independent of the nesting depth. Metrics and nested aggregations now go through an aggCollector hooked into bleve's collector walk via the document-match-handler context key. For every match it visits the doc values of the aggregated fields, the columnar storage bleve's own facets read, and folds them into an accumulator tree. The page stays the size the caller asked for and no stored field is loaded for an aggregation: 7x faster and 80x less memory at 100k matches, within 1.4x of a native bleve facet. Flat terms and range aggregations stay bleve facets. A range parent now carries its sub-aggregations too (the hit fold matched range bucket names against raw values and never attached them), and multi-valued fields count each value like a bleve facet does. The parity suite renders nested results and pins them on both engines: terms in terms, metrics per bucket, terms in numeric and date ranges, three levels, a page of one still aggregating every match, and a malformed bound in a nested range.
Server Backend
Tip
For general information about OpenCloud and how to install please visit OpenCloud on Github and OpenCloud GmbH.
This is the main repository of the OpenCloud server. It contains the golang codebase for the backend services.
Getting Involved
The OpenCloud server is released under Apache 2.0. The project is thrilled to receive contributions in all forms. Start hacking now, there are many ways to get involved such as:
- Reporting issues or bugs
- Requesting features
- Writing documentation
- Writing code or extend our tests
- Reviewing code
- Helping others in the community
Every contribution is meaningful and appreciated! Please refer to our Contribution Guidelines if you want to get started.
Build OpenCloud
To build the backend, follow these instructions:
Generate the assets needed by e.g., the web UI and the builtin IDP
make generate
Then compile the opencloud binary
make -C opencloud build
That will produce the binary opencloud/bin/opencloud. It can be started as a local test instance right away with a two step command:
opencloud/bin/opencloud init && opencloud/bin/opencloud server
This creates a server configuration (by default in $HOME/.opencloud) and starts the server.
For more setup- and installation options consult the Development Documentation.
Technology
Important information for contributors about the technology in use.
Authentication
The OpenCloud backend authenticates users via OpenID Connect using either an external IdP like Keycloak or the embedded LibreGraph Connect identity provider.
Database
The OpenCloud backend does not use a database. It stores all data in the filesystem. By default, the root directory of the backend is $HOME/.opencloud/.
Security
If you find a security-related issue, please contact security@opencloud.eu immediately.
