-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for ingesting via precomputed TxMeta in Horizon #4911
Comments
1 (DatabaseBackend) will be removed on completion of #4855 |
We have added a ledger backend implementation which will read precomputed Tx Meta from a data lake: https://github.com/stellar/go/blob/master/ingest/ledgerbackend/buffered_storage_backend.go The work remaining to complete this issue is:
|
We should make sure that we are streamlining the flags passed that specify captive-core vs data lake source system ingestion so that operators cannot configure invalid variants. The flags should be simple and easy for the operator to understand. We should also add a flag warning if an operator decides to run real time ingestion using the datastore ledgerbackend. Running off a datastore will introduce a lag and might be too slow to work properly with synchronous transaction submission. |
out of scope: productionalizing the code so that Horizon can fetch files from the GCS bucket. This will require coordination with ops |
How about adding an option only to |
@urvisavla , I think your suggestion could be woven in as a toggle for live and reingest, I've updated the acceptance sub-tasks in the description of ticket to capture. please re-write if not on target. I can work one of tasks in parallel, let me know, thanks. |
…to re execute them with clean args state
…ess and rw db, migrated
…ds for DataStore, BufferedStorageBackend, review feedback
…xec error, make sure close db conn regardless during test shutdown
…me parameters_test cases due to ingest bug stated in comments
Horizon currently has two modes of ingestion:
We need to add a third mode which is ingesting from the precomputed TxMeta backend. This will require adding new LedgerBackend implementation and configuration flags for Horizon that allow operators to select the new ledger backend.
Initial scope is to enable precomputed for reingestion only, not live/forward ingestion. We will implement the following changes to the Horizon reingest command to support the new mode of ingestion:
When using precomputed TxMeta we may need to adjust the minimum batch size and we may not need to round the batch sizes to multiples of 64.- deferring this optimization for initial pass.parallel-job-size
parameter needs to be reduced. (experimentally I found 100 to be the most efficient on production hw).As part of scope considerations, we will not address the following on first deliverable, and these can be done in later iterations:
horizon db reingest
The text was updated successfully, but these errors were encountered: