-
Notifications
You must be signed in to change notification settings - Fork 813
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
refactor indexers #424
refactor indexers #424
Conversation
Moved the indexer itself to: https://github.com/tuxcanfly/bindex This PR will be limited to the plugin integration, migration etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Nice to have the plugin separated out. I guess this is probably similar to the approach we'll want to do at some point with bwallet.
lib/node/fullnode.js
Outdated
const chain = await this.chain.getMetaByAddress(addrs); | ||
return chain.concat(mempool); | ||
return mempool.concat(chain); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why reverse this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This case would occur if indexes are disabled, so I think it should just return mempool actually. Will check that.
lib/node/node.js
Outdated
@@ -81,6 +81,11 @@ class Node extends EventEmitter { | |||
if (config.has('logger')) | |||
logger = config.obj('logger'); | |||
|
|||
const plugins = this.config.array('plugins', []); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean we add bindex
by default if indexing is turned on? Does it make a difference that it's in a separate module now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By implicitly enabling bindex
plugin we can ease the migration. No config files need be changed.
@@ -968,7 +968,7 @@ class RPC extends RPCBase { | |||
if (hash) { | |||
block = await this.chain.getBlock(hash); | |||
} else if (this.chain.options.indexTX) { | |||
const tx = await this.chain.getMeta(last); | |||
const tx = await this.node.getMeta(last); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is the difference with having indexing as a plugin on the node rather than built into the chain huh? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup :) Since indexing happens outside the chain.
@@ -0,0 +1,82 @@ | |||
'use strict'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have an explicit note somewhere that this basically just removes your old db and does a fresh sync with the new indexing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we can add that to the CHANGELOG
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added to CHANGELOG
Thinking this through, I think the indexing interface and nested plugins add unnecessary complexity. Also, splitting out tx, addr as plugins etc would make it hard to query them back, since we would need to know which keys the plugins are writing to. To keep things simple, I propose that the core indexers be a part of the indexing plugin directly. Alternate implementations can fork the index plugin for specific use cases (utxo set, colored coins) etc. Thanks @bucko13 for the discussion. |
lib/node/fullnode.js
Outdated
@@ -147,6 +144,14 @@ class FullNode extends Node { | |||
noAuth: this.config.bool('no-auth') | |||
}); | |||
|
|||
// Index needs access to the node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed for some of the events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, we need it to listen to the chain events. This specific comment can be improved though, will update it.
There's an issue with the way re-orgs are handled. Working to fix that and add more tests. |
Needs rebase on top of master. |
@chjj I realized I need to store all the blockhashes similar to wallet, because a re-org will leave my client out of sync and I wouldn't know where to rescan from. I might need to borrow some code from the wallet, specifically |
My case is simpler, because |
Making |
0867be8
to
08b38b3
Compare
Needs some updates to handle different databases for different indexers. |
c6cd319
to
3287508
Compare
*/ | ||
|
||
async getHashesByAddress(addrs) { | ||
const set = new BufferSet(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably could use an array here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a side note, if there are a lot of txids for an address this will likely have performance issues. The largest number of transactions for an address right now is over 3 million.
Worth considering as this code, and database, is being changed. There is an issue with the existing txindex. The tx index is keeping an entire copy of the transaction https://github.com/bcoin-org/bcoin/blob/master/lib/primitives/txmeta.js#L239 so there is a duplicate of the transaction on disk. I've documented this more at #585 Edit: The existing issues with txindex and addrindex can be addressed in another PR, this PR I think is mainly around having those indexes be separated into another database (one for each index). |
module indexer introduces a extensible architecture for indexing the chain. It provides a base class which handles syncing with the chain, handling re-orgs, interruptions, dynamic toggling, etc. TXIndexer and AddrIndexer are provided for indexing transactions and addresses, using the same flags as before i.e --index-tx and --index-address. Indexes are stored in a different database and can be maintained independently of the chain.
also rebase on top of master, fix conflicts
3287508
to
2abc3e2
Compare
Similar to #532 need to decide how we want to handle re-index in case of spv, pruned nodes. We might want to ask the user to reset the chain. |
cfc50f6
to
4decdcf
Compare
Added an error when re-indexing when pruned, the only case where it's not possible to re-index. |
Indexing, in this case, I think really only applies to full nodes, not pruned or spv. Aside from anything that can be indexed headers, or select transactions such as the wallet. It's currently technically possible for the |
Agreed, but we already support indexing when pruned, so disabling this would probably need a deprecation notice. Re-indexing was never supported, but with this PR, it is supported for full nodes, but not for pruned nodes. The error applies to the latter case. |
Some continued work on this is at an indexer branch that is being merged with changes from file block store in #703 and some of the additional addrindex fixes. |
Closing this in favor of #758 reworked to support the new flat file backend. |
This PR refactors the indexers into a lib with it's own db.
Refs #422