You are viewing a single comment's thread from:
RE: Update on web scalable EOS History API
I have to get back to you on ES cluster size after we are fully synced.
We only record data in ES that is used by History API. It saves a lot of space.
I have to get back to you on ES cluster size after we are fully synced.
We only record data in ES that is used by History API. It saves a lot of space.
Yep, I agree, and besides saving space, is very scalable (machine wise)! And that's the beauty of ES.
Also, because History has lots of "ends" in my view and can be dealt with in several ways. I can only see several standards emerging, and the use of a single API format for consumers will gradually disappear (my view). But I like the idea from @greymass (I believe it was from them) saying the API should be queriable for the format, after being proposed and accepted onchain. Then anyone can talk to the format they most wish... and even select the "type" of data (if the format allows you so) you want to access.
And from here, I see lots of advantages in having the history data in several types of databases. Some might even have offline data that if needed to be accessed, can be, but at a cost (of time). It would also allow many savings on "hot" data since this one can be stored/accessed in many IO performance flavours. Not necessarily has to be in the API, but would help if the API had some kind of tiering that eases the user cost (in case speed is not needed) or provides performance requirements if the user is keen on paying for it.
Anyway, I would really like to see the ES solution more adopted, to be honest. Along with some of the other tweaks I have been seeing around where to go with the History API format.
Cheers and Happy New Year!