mirror of
https://github.com/featurebasedb/featurebase.git
synced 2026-10-16 15:53:35 +00:00
bcb32addaf
* Formatting adjustments made during code review.
While reviewing the BULK INSERT logic (in order to decide how best to
approach "ingest via sql" in the cloud), I made a few formatting and
comment changes. I'm just adding them here as a separate commit so they
don't muddy up my actual work.
* Parser modifications to support mulitple tuples in INSERT INTO
This commit doesn't include all of the changes required in the
planner. Fow now, the planner is simply modified to continue supporting
a single tuple (the first tuple in the list).
* Update the planner to handle multiple INSERT INTO tuples
This is part 1. It's still using the existing logic which builds an
ImportRequest for every record (and every field!).
The next step will involve using a client.Batch to handle the records.
* Introduce client.Importer interface (used by client.Batch)
Instead of the Batch having a pointer to a client, this puts an
interface there instead (which the client implements). It also allows us
to inject a different importer (i.e. other than a featurebase.client)
into the Batch.
* Decouple batch from client
This commit pulls batch-specific code out of the client package and into
a new batch package. It introduces the batch.Importer interface, the
methods of which replace all the calls that batch was previously making
directly to client methods.
Finally, it contains two implementations of the batch.Importer
interface: one is a wrapper around client, and the other is a wrapper
around featurebase.API.
* Use docker (instead of MustRunCluster) for internal batch tests
Because the `batch` package tests are internal, using
test.MustRunCluster() resulted in an import loop (because it eventually
imports `server`, and we can't have that). So this commit replaces the
use of `test.MustRunCluster()` with docker. The setup is basically the
same as that used in the idk docker tests.
Here we also remove all client-side references to `UseIngestAPI`, which
is an experimental (json) ingest api. It's still suppored on the server,
but here we remove the external usage of it.
* cherry-pick fix
* Use batch.Import() for sql3 INSERT INTO statements
* Thread logger into sql3
* fix batch test
* Fix some shadowing complaint by linter
* Address some test issues related to stringsets
* Exclude batch integration tests from CI
* Address PR feedback
- Added description to batch.README
- Consolidated grep commands in .gitlab-ci.yml
- Removed some debugging comments
- Replaces some inadvertantly removed license headers
* Add batch package to gitlab CI
* Updated CI for batch package
Updated CI include path
Update gitlab ci
Update CI
Update CI
Trying new include path for ci
Updated gitlab ci include path
Made idk race job optional for sonarcloud upload
add testdata directory
remove testenv from dockercompose file
use GIT_STRATEGY clone in batch CI
add testdata volume to dockercompose
Co-authored-by: Fletcher Haynes <fletcher.haynes@generalassemb.ly>
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| gen | ||
| testdata | ||
| all-field-types.go | ||
| bank.go | ||
| claim.go | ||
| cmd.go | ||
| common.go | ||
| custom.go | ||
| custom_test.go | ||
| customer.go | ||
| customer_segmentation.go | ||
| customer_segmentation_test.go | ||
| equipment.data.go | ||
| equipment.go | ||
| example.go | ||
| hobbies.data.go | ||
| item.go | ||
| kitchen-sink-keyed.go | ||
| kitchen-sink.go | ||
| locations.data.go | ||
| network.go | ||
| README.md | ||
| shared.go | ||
| sites.data.go | ||
| sites.go | ||
| sizing.go | ||
| skills.data.go | ||
| stringpk.go | ||
| timeseries.go | ||
| titles.data.go | ||
| transactions.go | ||
| transactions_scenario_1.go | ||
| uscities.data.go | ||
| warranty.go | ||
| zip_codes.data.go | ||
Datagen Tool
Help Usage
Usage of datagen:
-c, --concurrency int Number of concurrent sources and indexing routines to launch. (default 1)
--dry-run Dry run - just flag parsing.
-e, --end-at uint ID at which to stop generating records.
--kafka.batch-size int Number of records to generate before sending them to Kafka all at once. Generally, larger means better throughput and more memory usage. (default 1000)
--kafka.hosts strings Comma separated list of host:port pairs for Kafka. (default [])
--kafka.registry-url string Location of Confluent Schema Registry. Must start with 'https://' if you want to use TLS.
--kafka.subject string Kafka schema subject.
--kafka.topic string Kafka topic to post to.
--pilosa.batch-size int Number of records to read before indexing all of them at once. Generally, larger means better throughput and more memory usage. 1,048,576 might be a good number.
--pilosa.cache-length uint Number of batches of ID mappings to cache. (default 64)
--pilosa.hosts strings Comma separated list of host:port pairs for Pilosa. (default [])
--pilosa.index string Name of Pilosa index.
--seed int Seed to use for any random number generation.
-s, --source string Source generator type. Running datagen with no arguments will list the available source types.
-b, --start-from uint ID at which to start generating records.
-t, --target string Destination for the generated data: [kafka, pilosa]. (default "pilosa")
--track-progress Periodically print status updates on how many records have been sourced.
Example Usage
The following command will create 100 records in Pilosa index (starting at ID 0 and ending at ID 99)
in the equipment index using the equipment data generator.
datagen --source=equipment --pilosa.index=equipment --end-at=99
Adding New Sources
TODO: redo README (or delete?)
If you're looking to add a new Source to datagen, the best thing to do is use the special "custom" datagen source (datagen --source=custom --custom-config=somefile.yaml) and write a somefile.yaml which describes the data you want to generate. An example can be found in datagen/testdata/custom.yaml, and there are some more in the molecula/technical-validation repo.