优化的批量（组块）物件上传到IndexedDB的

我想对象添加到IndexedDB的一些表中的一个交易：优化的批量（组块）物件上传到IndexedDB的

_that.bulkSet = function(data, key) { 
    var transaction = _db.transaction([_tblName], "readwrite"), 
     store = transaction.objectStore(_tblName), 
     ii = 0; 

    _bulkKWVals.push(data); 
    _bulkKWKeys.push(key); 

    if (_bulkKWVals.length == 3000) { 
     insertNext(); 
    } 

    function insertNext() { 
     if (ii < _bulkKWVals.length) { 
      store.add(_bulkKWVals[ii], _bulkKWKeys[ii]).onsuccess = insertNext; 
      ++ii; 
     } else { 
      console.log(_bulkKWVals.length); 
     } 
    } 
};

看起来，它工作正常，但它是不是很优化做的方式特别是如果对象的数量非常高（〜50.000-500.000）。我怎么可能优化它？理想情况下，我想添加第一个3000，然后从阵列中删除它，然后添加另一个3000，即分块。有任何想法吗？

来源

2014-03-07 Kanan Farzali

连续插入多行，不可能获得良好的性能。

我是IndexedDB dev并且在您所谈论的规模（连续编写数十万行）中拥有IndexedDB的实际经验。它不太漂亮。

在我看来，IDB并不适合用于需要连续写入大量数据的情况。如果我要构建一个需要大量数据的IndexedDB应用程序，我会想出一种方法来慢慢播种它。

问题在于写入，而我所看到的问题是写入缓慢，加上其I/O密集性质，随着时间的推移会变得更糟。（IDB的阅读速度一直很快，因为它值得。）

首先，您将从重新使用交易中节省开支。因为你的第一本能可能是试图将所有东西塞进同一个事务中。但是，从我在Chrome中发现的情况来看，例如，浏览器似乎不喜欢长时间运行的写入，这可能是因为某种机制旨在遏制行为不当标签。

我不确定你看到了什么样的表现，但根据测试的大小，平均数可能会欺骗你。限制速度更快是吞吐量，但是如果您试图连续插入大量数据，请特别注意随时写入。

我碰巧正在处理一个有数十万行的演示程序，并拥有统计信息。在禁用了可视化功能的情况下，在IDB上运行纯破折号，这就是我在单个对象存储中的Chrome 32中看到的内容，它带有一个具有自动递增主键的非唯一索引。我看到一个更小的27k行数据集，我看到每秒60-70个条目：
*〜30秒：平均每秒921个条目（在开始时总是有大量插入），62 /第二个在我抽样
*〜60秒：389 /秒平均值（持续减少开始超过效果初始突发）时71秒/秒
*〜1:30:258 /秒，在时刻67 /秒
*〜2：00（〜1/3完成）：平均每秒188个，瞬间66个/秒

一些数据集小得多的例子表现出好得多的表现，但类似的特征cteristics。同样大得多的数据集 - 效果非常夸张，我在离开多个小时时看到的每秒只有1个条目。

来源

2014-03-11 02:35:17 buley

我也做了一些基准测试，在1000个事务中插入了1000个，并猜测：[创建trasaction +获取存储] = 20秒，[inserts] = 10秒...第一个问题严重错误 – lisak

@buley，你有网站吗？ – MB34

优化的批量（组块）物件上传到IndexedDB的

回答

相关问题