* Introduce ServiceManager and Refactor DAX Integration tests
The ServiceManager provides an interface with which to manage
featurebase (dax) services (mds, queryer, computer). It replaces the
confusing interface implementations in /dax/server/server.go (which
optionally used pointers to in-process objects to satisfy an interface)
with (for now) http implementations. The thought is that even if we're
running all services in-process, we should communicate between services
over http in order to mirror what we would do in a production
environment where the services are running on different nodes.
This batch of commits does quit a lot, most of which is captured here:
- Added `path` support to `dax.Address`. Address is now a string of the form [scheme]://[host]:[port]/[path].
- Added `Holder.directiveApplied` to determine (in tests) if the computer has completed applying the latest directive. This is somewhat temporary until we improve the mds-to-computer logic.
- Removed the "service prefix" code which was prepending client URL paths with the prefix. Instead, the serviceType (mds, queryer, computer[n] is now part of `dax.Address`).
- Removed, from the dax config, the top level `StorageMethod` and `StorageDSN` and now just have `MDS.Config.DataDir`.
- Added `Computer.Config.N` to specify the number of computers to run in-process.
- Moved the `pilosa.MDS` interface to `computer.Registrar`. This is an example of getting the interfaces defined in the right packages.
- Added `SnapshotTable()` method to the mds client (to align with its API).
- Changed `Balancer.AddJob()` to `Balancer.AddJobs()` to support, for example, adding 256 partitions in a single call. Refactored some of the naive Balancer to account for this.
- Added a `Seed` to the top-level config. It's not really useful because of package `crypto/rand`.
- Added an in-memory implementation of the DisCo interface and disabled etcd in a computer service.
- Create sepearte data-dirs for each in-process computer.
- Disabled grpc in dax.
- Modified the sql3 test definition format to support multiple insert steps and separate query results (to align with those steps).
* Changes necessary to get multiple computer instance running in-process
For now the config looks like this:
```
[computer]
run = true
n = 4
```
but we can probably just change that to be something like:
```
[computer]
run = 4
```
*Issues found running multiple "computers" in-process*
- grpc was trying to bind on the same port
- changed GRPCListener from `*net.TCPListener` to `net.Listener`
- created a nopListener and set to that for now (i.e. disabled grpc)
- etcd was starting more than once
- changed dax to use in-memory implementations of the disco interfaces (i.e. stop using etcd)
- IDAllocator (which uses boltdb) was trying to open the `idalloc.db` file more than once
- realized we have to set separate data-dirs for each holder. that fixed it.
* Port dax integration tests to ManagedCommand
* Modify Balancer-related methods like AddJob to AddJobs
There were (and still are) a lot of places where we were adding on job
at a time, even when we had a long list of jobs to add. This resulted in
every job add (for example adding 1 of 256 shards) taking ~40ms, or over
10s to create a keyed table. One reason was because each job add was
making multiple boltdb transactions.
* Port over more dax integration test stuff
* Add DirectiveApplied to signify that snapshot/writes have loaded.
We use this in tests to avoid using sleeps.
This should be considered temporary; we're going to need a more robust
solution for determining when a computer node is ready to serve complete
data.
* Finish porting dax integration tests
* Improve godocs
* Remove docker-based DAX integration tests.
* go mod tidy
* Move test/managed.go to avoid package conflicts
* Modify IDK integration tests to work with ServiceManager changes
This is really just computer -> computer0
And the MDS DataDir config change.
* cleanup found during review
* echo $CI_COMMIT_REF_SLUG in CI
* remove docker image arg, use build instead
(cherry picked from commit
|
||
|---|---|---|
| .github/workflows | ||
| api/client | ||
| authn | ||
| authz | ||
| batch | ||
| boltdb | ||
| client | ||
| cmd | ||
| context | ||
| ctl | ||
| dax | ||
| debugstats | ||
| disco | ||
| encoding/proto | ||
| errors | ||
| etcd | ||
| fbcloud | ||
| gcnotify | ||
| generator | ||
| gopsutil | ||
| hash | ||
| idk | ||
| install | ||
| internal | ||
| lattice | ||
| logger | ||
| lru | ||
| mock | ||
| monitor | ||
| net | ||
| pb | ||
| pql | ||
| prometheus | ||
| proto | ||
| qa | ||
| querycontext | ||
| rbf | ||
| roaring | ||
| runners | ||
| scripts | ||
| server | ||
| shardwidth | ||
| short_txkey | ||
| sql | ||
| sql3 | ||
| statik | ||
| stats | ||
| statsd | ||
| storage | ||
| systemlayer | ||
| syswrap | ||
| task | ||
| test | ||
| testdata | ||
| testhook | ||
| toml | ||
| tracing | ||
| txkey | ||
| vprint | ||
| .gitignore | ||
| .golangci.yml | ||
| api.go | ||
| api_directive.go | ||
| api_directive_internal_test.go | ||
| api_directive_test.go | ||
| api_test.go | ||
| apimethod_string.go | ||
| apply.go | ||
| arrow.go | ||
| audit.go | ||
| audit_internal_test.go | ||
| audit_test.go | ||
| broadcast.go | ||
| bsi.go | ||
| bsi_test.go | ||
| cache.go | ||
| cache_test.go | ||
| catcher.go | ||
| cluster.go | ||
| cluster_internal_test.go | ||
| CODE_OF_CONDUCT.md | ||
| const_amd64.go | ||
| const_other.go | ||
| dataframe_test.go | ||
| dbshard.go | ||
| dbshard_internal_test.go | ||
| dbshard_test.go | ||
| delete_test.go | ||
| diagnostics.go | ||
| diagnostics_internal_test.go | ||
| doc.go | ||
| Dockerfile | ||
| Dockerfile-clustertests | ||
| Dockerfile-clustertests-client | ||
| Dockerfile-datagen | ||
| Dockerfile-dax | ||
| Dockerfile-dax-quick | ||
| et_test.go | ||
| event.go | ||
| executor.go | ||
| executor_internal_test.go | ||
| executor_test.go | ||
| field.go | ||
| field_internal_test.go | ||
| field_test.go | ||
| filesystem.go | ||
| fragment.go | ||
| fragment_internal_test.go | ||
| gc.go | ||
| gid.go | ||
| go.mod | ||
| go.sum | ||
| hack.go | ||
| handler.go | ||
| handler_test.go | ||
| holder.go | ||
| holder_internal_test.go | ||
| holder_test.go | ||
| http_handler.go | ||
| http_handler_internal_test.go | ||
| http_handler_test.go | ||
| http_translator.go | ||
| http_translator_test.go | ||
| idalloc.go | ||
| idalloc_test.go | ||
| index.go | ||
| index_internal_test.go | ||
| index_test.go | ||
| internal_client.go | ||
| internal_client_test.go | ||
| iterator.go | ||
| iterator_internal_test.go | ||
| LICENSE-2.0.txt | ||
| license.exceptions | ||
| like.go | ||
| like_test.go | ||
| main_test.go | ||
| Makefile | ||
| metrics.go | ||
| nfpm.yaml | ||
| NOTICE | ||
| pilosa.go | ||
| pilosa_internal_test.go | ||
| pilosa_test.go | ||
| pprof.go | ||
| rbf.go | ||
| README.md | ||
| row.go | ||
| row_test.go | ||
| serializer.go | ||
| server.go | ||
| server_internal_test.go | ||
| server_test.go | ||
| sql_test.go | ||
| stattx.go | ||
| systemlayer.go | ||
| time.go | ||
| time_internal_test.go | ||
| tracker.go | ||
| tracker_test.go | ||
| transaction.go | ||
| transaction_test.go | ||
| translate.go | ||
| translator_test.go | ||
| tx.go | ||
| tx_internal_test.go | ||
| tx_test.go | ||
| txfactory.go | ||
| txfactory_internal_test.go | ||
| util.go | ||
| util_test.go | ||
| utils_internal_test.go | ||
| version.go | ||
| view.go | ||
| view_internal_test.go | ||
| wire_response.go | ||
FeatureBase
Pilosa is now FeatureBase
As of September 7, 2022, the Pilosa project is now FeatureBase. The core of the project remains the same: FeatureBase is the first real-time distributed database built entirely on bitmaps. (More information about updated capabilities and improvements below.)
FeatureBase delivers low-latency query results, regardless of throughput or query volumes, on fresh data with extreme efficiency. It works because bitmaps are faster, simpler, and far more I/O efficient than traditional column-oriented data formats. With FeatureBase, you can ingest data from batch data sources (e.g. S3, CSV, Snowflake, BigQuery, etc.) and/or streaming data sources (e.g. Kafka/Confluent, Kinesis, Pulsar).
For more information about FeatureBase, please visit www.featurebase.com.
Getting Started
Build FeatureBase Server from source
- Install go. Ensure that your shell's search path includes the go/bin directory.
- Clone the FeatureBase repository (or download as zip).
- In the featurebase directory, run
make installto compile the FeatureBase server binary. By default, it will be installed in the go/bin directory. - In the idk directory, run
make installto compile the ingester binaries. By default, they will be installed in the go/bin directory. - Run
featurebase server --handler.allowed-origins=http://localhost:3000to run FeatureBase server with default settings (learn more about configuring FeatureBase at the link below). The--handler.allowed-originsparameter allows the standalone web UI to talk to the server; this can be omitted if the web UI is not needed. - Run
curl localhost:10101/statusto verify the server is running and accessible.
Ingest Data and Query
- Run
molecula-consumer-csv \
--index repository \
--header "language__ID_F,project_id__ID_F" \
--id-field project_id \
--batch-size 1000 \
--files example.csv
This will ingest the example.csv file into a FeatureBase table called repository. If the table does not exist, it will be automatically created. Learn more about ingesting into FeatureBase: https://docs.featurebase.com/data-ingestion/enterprise/ingesters
- Query your data.
curl localhost:10101/index/repository/query \
-X POST \
-d 'Row(example=5)'
Learn about supported SQL, native Pilosa Query Language (PQL).
Data Model
Because FeatureBase is built on bitmaps, there is bit of a learning curve to grasp how your data is represented. Data Model Guide: https://docs.featurebase.com/data-modeling-guide/data-modeling
More Information
Installation:https://docs.featurebase.com/setting-up-featurebase/enterprise/installing-featurebase
Configuration: https://docs.featurebase.com/setting-up-featurebase/enterprise/featurebase-configuration
Community
You can email us at community@featurebase.com or learn more about contributing at https://www.featurebase.com/community.
Chat with us: https://discord.gg/FBn2vEp7Na
What's Changed Since the Pilosa Days?
A lot has changed since the days of Pilosa. This list highlights some new capabilites included in FeatureBase. We have also made signficant improvements to the performance, scalability, and stability of the FeatureBase product.
- Query Languages: FeatureBase supports Pilosa Query Language (PQL), as well as SQL
- Stream and Batch Ingest: Combine real-time data streams with batch historical data and act on it within milliseconds.
- Mutable: Perform inserts, updates, and deletes at scale, in real time and on-the-fly. This is key for meeting data compliance requirements, and for reflecting the constantly-changing nature of high-volume data.
- Multi-Valued Set Fields: Store multiple comma-delimited values within a single field while increasing query performance of counts, TopKs, etc.
- Time Quantums: Setting a time quantum on a field creates extra views which allow ranged Row queries down to the time interval specified. For example, if the time quantum is set to YMD, ranged Row queries down to the granularity of a day are supported.
- RBF storage backend: this is a new compressed bitmap format which improves performance in a number of ways: ACID support on a per shard basis, prevents issues with the number of open files, reduces memory allocation and lock contention for reads, provides more consistent garbage collection, and allows backups to run concurrently with writes. However, because of this change, Pilosa backup files cannot be restored into FeatureBase.
License
FeatureBase is licensed under the Apache License, Version 2.0