Skip to content
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

Move blockchain out of memory #7

Open
cosme12 opened this issue Jan 14, 2018 · 8 comments
Open

Move blockchain out of memory #7

cosme12 opened this issue Jan 14, 2018 · 8 comments

Comments

@cosme12
Copy link
Owner

cosme12 commented Jan 14, 2018

As blockchain gets bigger, it will be necessary to be moved out of memory. Since this is a simplified version of a blockchain, saving it in a text file may be enough.

@kennethgoodman
Copy link

feather and pandas should do it if we only allow one input to one output transactions.

For more complex transactions, json with a fast json library: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-json-libraries/

@rdenadai
Copy link

Perhaps TinyDB could be a option? If you don't need concurrent access to the file...

http://tinydb.readthedocs.io/en/latest/

Just store the blockchain in it as a json format...

@Aareon
Copy link
Contributor

Aareon commented Feb 1, 2018

I would suggest a combination of SQLite/PostgreSQL and SQLAlchemy. Preferably Postgres in production.

I’ve never personally used Feather or Pandas, but I have seen the combo that I’ve suggested used in production by other block chains, and it works more than well.

In my opinion, I don’t believe TinyDB or any flat file option would be efficient enough.

@rdenadai
Copy link

rdenadai commented Feb 1, 2018

@Aareon as i said, if concurrent access is not necessary...

I use TinyDB in a project, but since then i need concurrent access to my database so i change it to rethinkdb.

It was a simple migration between both of the, by simple rewriting my DAO class...

Postgresql + SQLAlchemy are always welcome but it brings a new layer of complexy to the project which main goal claims to be simple...

@Aareon
Copy link
Contributor

Aareon commented Feb 1, 2018

Neither one of those solutions are ACID compliant. I don’t think we want to use something that has a chance of losing data. It may be simpler, but does not by any means mean better. My solution may be more complicated, but it will be much more reliable. If you’re okay with losing data in your ledger, be my guest.

@HourGlss
Copy link

Right now I can mine between 33-36 blocks, depending on how I choose to handle the Pipes. The limiting factor is the Pipe though, not the size of the blockchain in memory. do a test and don't send information around in pipes. I can handle thousands of them, with pipes, less than 40.

@HourGlss
Copy link

I fixed it using Queue and restructuring the way that multiprocessing works

@HourGlss
Copy link

HourGlss commented Nov 2, 2018

Implemented a blockchain class which utilizes a sqldatabase https://github.com/hourglss/hourcrypto WORK IS ONGOING, PROJECT IS CURRENTLY nonfunctional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants