| Table of Contents | ||||
|---|---|---|---|---|
|
...
The purpose of this document is to describe an approach that may be used to analyze FIO read performance of state in the FIO chain plugin and FIO contracts
Objective
The objective is to. Specifically it will:
Document all of the uses of get table rows within the chain plugin within fio.
Document all of the uses of table find within the fio.contracts.
...
Analyze each from a “read performance” perspective and publish a list of the reads along with a level of concern for each.
Decide on next steps.
Summary of Results
...
and Next Steps
The “Deploy high-powered / modified API plugin” solution was determined to be the easiest solution to deploy and it maintains decentralization. The analysis is tracked here. Development and rollout will be tracked in FIP-46 and this epic.
Alternative Options
Option | Status | Description | Pros | Cons | Centralized | Dev Effort Low: weeks | QA Effort Low: 1 week | Data Migration Effort |
|---|---|---|---|---|---|---|---|---|
Table redesign and migration | Not viable | Redesign tables with proper scope and/or indexes and migrate data to new tables |
|
| No | High | Med - High | High |
Possible medium to long term solution | Create secondary lookup tables alongside existing tables |
|
| No | Med | Med | Med | |
Large transaction solution | An off-chain database can be created and the data indexed for specific lookups. |
|
| Yes | Med-High | High | High | |
Off-chain - block crawling | Crawl each block looking for specific transactions and index those into a local database |
|
| Yes | Med (depends on validation) | Low | Low (if you have someone who knows history nodes) | |
#2? | Can a history node solve any of this? Initial research shows this may be an offline centralized solution. Needs further research with exchange integrators. | No | ||||||
Brute force searches (as a service) | #3? | Runtime Javascript code to page through the entire table and pull out needed data. Could be deployed as an API service endpoint on AWS or an integrator can deploy the code in their wallet. |
|
| Yes | Low | Low | Low |
Brute force searches (via SDK) | #3? | First try simple version, if more data, do the more complex query. | No | |||||
#1 | Remove cpu and other limits on query time for fio API nodeTodo: can we make this a general API plugin? |
|
| No | Low | Med | Low | |
Deploy high-powered / modified API node that we host | #1.b | Yes | ||||||
Limits on number of table entries | Not viable | Put limits in the contracts for table size (as we do for mapped addresses). |
|
| Low | Low | Low |
...