征求意见:在发布版 tar 压缩包中附带区块链的第 1–74000 号区块?

中本聪SN-3684

看起来你倾向于认定什么都有问题,把情况想得比实际更糟。

It seems like you're inclined to assume everything is wrong more than is actually so.

写区块索引是轻量工作。构建交易索引时,每个区块都需要多得多的随机访问。我怀疑慢就慢在读取所有前序交易输入上。读缓存对此会有帮助。最好由 DB 来做。也许它有设置缓存内存大小的选项。

Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use.

引用 · 发言者未注明

1) 比特币应该在程序启动时就打开数据库而不只是环境,并在程序关闭时关闭数据库。

1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.

中本聪回应

它已经这么做了。见 CDB。(比如)CTxDB 对象的生命周期只是为了支持数据库事务,以及关闭时判断数据库是否还有人在用。

Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.

引用 · 发言者未注明

而且,比特币还强制执行一次数据库检查点操作,把日志里的全部事务写入主数据库。

And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.

中本聪回应

如果它真在那么做,会慢得多。它本该只是一分钟一次或 500 区块一次:

If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks:

if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
        nMinutes = 1;
    dbenv.txn_checkpoint(0, nMinutes, 0);

或许应该加上这个:

Probably should add this:

if (!fReadOnly)

if (!fReadOnly)

dbenv.txn_checkpoint(0, nMinutes, 0);

dbenv.txn_checkpoint(0, nMinutes, 0);

引用 · 发言者未注明

2) 对于初始区块下载,应该每处理 N 条记录才提交一次事务,而不是每条记录都提交一次。我建议 N=1000。

2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.

中本聪回应

事务提交意味着刷盘吗?这让我很意外。我以为包在事务里的数据库操作会像其他数据库操作一样被记日志。很多数据库应用几乎每一对操作都得包进事务,比如把钱从一个账户挪到另一个。(借记 a,贷记 b)我无法想象它们还被要求自己把操作攒成批。

Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves.

在下面两种情况下,情况 1 刷一次盘、情况 2 刷两次吗?

In the following cases, would case 1 flush once and case 2 flush twice?

情况 1:

case 1:

write

write

write

write

write

write

write

write

checkpoint

checkpoint

情况 2:

case 2:

begin transaction

begin transaction

write

write

write

write

commit transaction

commit transaction

begin transaction

begin transaction

write

write

write

write

commit transaction

commit transaction

checkpoint

checkpoint

扭曲我们的数据库用法不会是正确的路子。出路在于 BDB 设置和缓存。

Contorting our database usage will not be the right approach. It's going to be BDB settings and caching.

译文校对、修订与纠错

当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。

查看历史审校与代表修订 →

译文内容版本:b25174e94ccf。用于比对文本,不代表校对等级或更新时间。

准备纠错说明

请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交;此处不会自动发送。

来源
英文原标题

RFC: ship block chain 1-74000 with release tarballs?

Bitcointalk · 原始链接 ↗ 记录编号 SN-3684

阅读字号

选择适合你的字号,之后阅读会继续使用。