From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Sgwm5-00019L-8S for bitcoin-development@lists.sourceforge.net; Tue, 19 Jun 2012 11:39:09 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Sgwm4-00075S-9s for bitcoin-development@lists.sourceforge.net; Tue, 19 Jun 2012 11:39:09 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id 8DF5C618D0; Tue, 19 Jun 2012 13:38:59 +0200 (CEST) Date: Tue, 19 Jun 2012 13:38:59 +0200 From: Pieter Wuille To: Mike Hearn Message-ID: <20120619113857.GA29542@vps7135.xlshosting.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1Sgwm4-00075S-9s Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] LevelDB benchmarking X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 11:39:09 -0000 On Tue, Jun 19, 2012 at 11:05:20AM +0200, Mike Hearn wrote: > OK, to make progress on this work I need a few decisions (Gavin?) > > 1) Shall we do it? I'm all for moving away from BDB. It's a very good system for what it is intended for, but that is not how we use it. The fact that it is tied to a database environment (but people want to copy the files themselves between systems), that is provides consistency in case of failures (but because we remove old log files, we still see very frequent corrupted systems), the fact that its environments are sometimes not even forward- compatible, ... Assuming LevelDB is an improvement in these areas as well as resulting in a speed improvement, I like it. > 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. How portable is LevelDB? How well tested is it? What compatibility guarantees exist between versions of the system? I don't mind including the source code; it doesn't seem particularly large, and the 2-clause BSD license shouldn't be a problem. > 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. > > We'd need UI for migration as well. Jeff was working on splitting the database into several files earlier, and I'm working on the database/validation logic as well. Each of these will require a rebuild of the databases anyway. If possible, we should try to get them in a single release, so people only need to rebuild once. PS: can we see the code? -- Pieter