From: Gavin Andresen <gavinandresen@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] LevelDB benchmarking
Date: Tue, 19 Jun 2012 11:05:21 -0400 [thread overview]
Message-ID: <CABsx9T3pQFqL0xsvRfnixYEATO61qMCCDdLmtqZkbVLW0Vxytg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2q9a_0rFh+oo6iUFF1goWs0OJO1xPvxC9zqNA-6VnFAQ@mail.gmail.com>
> OK, to make progress on this work I need a few decisions (Gavin?)
>
> 1) Shall we do it?
What problem does it solve?
If the problem it will solve is "it will only take 4 hours to download
the entire blockchain next year instead of taking 16 hours" then no, I
don't think we should do it, both 4 and 16 hours to get fully up and
running is too long.
If the problem it will solve is the "too easy to get a DB_RUNRECOVERY
error" because bdb is fragile when it comes to its environment... then
LevelDB looks very interesting.
If the problem is bdb is creaky and old and has obscure semantics and
a hard-to-work-with API, then yes, lets switch (I'm easily seduced by
a pretty API and blazing fast performance).
> 2) LevelDB is obscure, new and has a very minimalist build system. It
> supports "make" but not "make install", for example, and is unlikely
> to be packaged. It's also not very large. I suggest we just check the
> source into the main Bitcoin tree and link it statically rather than
> complicate the build.
As long as it compiles and runs on mac/windows/linux that doesn't
really worry me. I just tried it, and it compiled quickly with no
complaints on my mac.
Lack of infrastructure because it is new does worry me; for example,
could I rework bitcointools to read the LevelDB blockchain? (are
there python bindings for LevelDB?)
> 3) As the DB format would change and a slow migration period
> necessary, any other tweaks to db format we could make at the same
> time? Right now the key/values are the same as before, though using
> satoshi serialization for everything is a bit odd.
Satoshi rolled his own network serialization because he didn't trust
existing serialization solutions to be 100% secure against remote
exploits. Then it made sense to use the same solution for disk
serialization; I don't see a compelling reason to switch to some other
serialization scheme.
Modifying the database schema during migration to better support
applications like InstaWallet (tens of thousands of separate wallets)
or something like Pieter's ultra-pruning makes sense.
--
--
Gavin Andresen
next prev parent reply other threads:[~2012-06-19 15:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 18:41 Mike Hearn
[not found] ` <CAAS2fgTNqUeYy+oEFyQWrfs4Xyb=3NXutvCmLusknF-18JmFQg@mail.gmail.com>
2012-06-19 9:05 ` Mike Hearn
2012-06-19 11:38 ` Pieter Wuille
2012-06-19 15:05 ` Gavin Andresen [this message]
2012-06-19 16:06 ` Mike Hearn
2012-06-19 19:22 ` Stefan Thomas
2012-06-20 9:44 ` Mike Hearn
2012-06-20 9:53 ` Mike Hearn
2012-06-20 11:37 ` Pieter Wuille
2012-06-20 12:41 ` Mike Hearn
2012-06-25 16:32 ` Mike Hearn
2012-07-21 18:49 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABsx9T3pQFqL0xsvRfnixYEATO61qMCCDdLmtqZkbVLW0Vxytg@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox