lmdb-store - npm Package Compare versions

Comparing version 0.3.7 to 0.3.8

package.json

		{
		"name": "lmdb-store",
		"author": "Kris Zyp",
		"version": "0.3.7",
		"version": "0.3.8",
		"description": "Simple, effiecent, scalable data store wrapper for LDMB",
		@@ -6,0 +6,0 @@ "license": "MIT",

README.md

		@@ -7,3 +7,3 @@ LMDB is probably the fastest and most efficient database on the planet, if used correctly. `lmdb-store` provides a simple interface for interacting with LMDB, as a key-value store, that makes it easy to properly leverage the power, crash-proof design, and efficiency of LMDB. Used directly, LMDB has certain characteristics that can be very challenging, including fixed db size, inefficieny with flushing small transactions, and complicated cursors usage. `lmdb-store` offers several key features that make it NodeJS idiomatic, highly performant, and easy to use than LMDB efficiently:

		`lmdb-store` is build on the excellent `node-lmdb` package.
		`lmdb-store` is build on the excellent [node-lmdb](https://github.com/Venemo/node-lmdb) package.

		@@ -13,5 +13,5 @@ ## Design

		`lmdb-store` is designed for synchronous reads, and asynchronous writes. In idiomatic NodeJS code, I/O operations are performed asynchronously. `lmdb-store` observes this design pattern; because LMDB is a memory-mapped database, read operations do not use any I/O (other than the slight possibility of a page fault), and can almost always be performed faster than Node's event queue callbacks can even execute, and it is easier to for code get instant synchronous values from reads. On the otherhand, in default mode with sync'ed/flushed transactions, write operations do involve I/O, and furthermore can achieve vastly higher throughput by batching operations. The entire transaction of batch operation are performed in a separate thread. Consequently, `lmdb-store` is designed for writes to go through this batching process and return a simple promise that resolves once the write is completed and flushed to disk.
		`lmdb-store` is designed for synchronous reads, and asynchronous writes. In idiomatic NodeJS code, I/O operations are performed asynchronously. `lmdb-store` observes this design pattern; because LMDB is a memory-mapped database, read operations do not use any I/O (other than the slight possibility of a page fault), and can almost always be performed faster than Node's event queue callbacks can even execute, and it is easier to write code for instant synchronous values from reads. On the otherhand, in default mode with sync'ed/flushed transactions, write operations do involve I/O, and furthermore can achieve vastly higher throughput by batching operations. The entire transaction of batch operation are performed in a separate thread. Consequently, `lmdb-store` is designed for writes to go through this asynchronous batching process and return a simple promise that resolves once the write is completed and flushed to disk.

		LMDB supports multiple modes of transactions, including disabling of file sync'ing (noSync), which makes transaction commits much faster. We _highly_ discourage turning off sync'ing as it leaves the database prone to data corruption. With the default sync'ing enabled, LMDB has a crash-proof design; a machine can be turned off at any point, and data can only be corrupted if the written data is actually corrupted/changed. This does make transactions slower. However, by batching writes, when a database is under load, slower transactions just enable more writes per transaction, and lmdb-store is able to drive LMDB to achieve the same levels of throughput with safe sync'ed transactions as without, while still preserving the durability/safety of sync'ed transactions.
		LMDB supports multiple modes of transactions, including disabling of file sync'ing (noSync), which makes transaction commits much faster. We _highly_ discourage turning off sync'ing as it leaves the database prone to data corruption. With the default sync'ing enabled, LMDB has a crash-proof design; a machine can be turned off at any point, and data can only be corrupted if the written data is actually corrupted/changed. This does make transactions slower (although not necessarily less efficient). However, by batching writes, when a database is under load, slower transactions just enable more writes per transaction, and lmdb-store is able to drive LMDB to achieve the same levels of throughput with safe sync'ed transactions as without, while still preserving the durability/safety of sync'ed transactions.

		@@ -97,8 +97,8 @@ `lmdb-store` supports and encourages the use of conditional writes; this allows for atomic operations that are dependendent on previously read data, and most transactional types of operations can be written with an optimistic-locking based, atomic-conditional-write pattern.
		The following options map to LMDB's env flags, <a href="http://www.lmdb.tech/doc/group__mdb.html">described here</a>:
		* useWritemap - Use writemaps (this is the only flag we recommend using)
		* useWritemap - Use writemaps (this is the main flag we recommend using), as it improves performance by reducing malloc calls.
		* noSubdir - Treat `path` as a filename instead of directory (this is the default if the path appears to end with an extension, has '.' in it)
		* noSync - Doesn't sync the data to disk. We highly discourage this flag, since it can result in data corruption and lmdb-store mitigates performance issues associated with disk syncs by batching.
		* noMetaSync - This isn't as dangerous as `noSync`, but doesn't improve performance much either.
		* readOnly
		* mapAsync
		* readOnly - Self-descriptive.
		* mapAsync - Not recommended, lmdb-store provides the means to ensure commits are performed in a separate thread (asyncronous to JS), and this prevents accurate notification of when flushes finish.

		@@ -119,3 +119,5 @@ ## Events

		`node-lmdb`
		lmdb-store is built on top of [node-lmdb](https://github.com/Venemo/node-lmdb)
		cobase is built on top of lmdb-store: [cobase](https://github.com/DoctorEvidence/cobase)

		<a href="https://dev.doctorevidence.com/"><img src="./assets/powers-dre.png" width="203"/></a>

util/ArrayLikeIterable.js

		@@ -97,2 +97,3 @@ const when = require('./when')
		}
		array.iterable = iterable
		resolve(iterable._asArray = array)
		@@ -102,2 +103,3 @@ }
		})
		promise.iterable = this
		return this._asArray \|\| (this._asArray = promise)
		@@ -104,0 +106,0 @@ }

lmdb-store - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics