|
|
@ -7,7 +7,40 @@ const model = require('./model.js') |
|
|
|
const storage = require('./storage.js') |
|
|
|
const storage = require('./storage.js') |
|
|
|
|
|
|
|
|
|
|
|
/** |
|
|
|
/** |
|
|
|
* Handle every persistence-related task |
|
|
|
* Under the hood, NeDB's persistence uses an append-only format, meaning that all |
|
|
|
|
|
|
|
* updates and deletes actually result in lines added at the end of the datafile, |
|
|
|
|
|
|
|
* for performance reasons. The database is automatically compacted (i.e. put back |
|
|
|
|
|
|
|
* in the one-line-per-document format) every time you load each database within |
|
|
|
|
|
|
|
* your application. |
|
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
* You can manually call the compaction function |
|
|
|
|
|
|
|
* with `yourDatabase.persistence.compactDatafile` which takes no argument. It |
|
|
|
|
|
|
|
* queues a compaction of the datafile in the executor, to be executed sequentially |
|
|
|
|
|
|
|
* after all pending operations. The datastore will fire a `compaction.done` event |
|
|
|
|
|
|
|
* once compaction is finished. |
|
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
* You can also set automatic compaction at regular intervals |
|
|
|
|
|
|
|
* with `yourDatabase.persistence.setAutocompactionInterval(interval)`, `interval` |
|
|
|
|
|
|
|
* in milliseconds (a minimum of 5s is enforced), and stop automatic compaction |
|
|
|
|
|
|
|
* with `yourDatabase.persistence.stopAutocompaction()`. |
|
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
* Keep in mind that compaction takes a bit of time (not too much: 130ms for 50k |
|
|
|
|
|
|
|
* records on a typical development machine) and no other operation can happen when |
|
|
|
|
|
|
|
* it does, so most projects actually don't need to use it. |
|
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
* Compaction will also immediately remove any documents whose data line has become |
|
|
|
|
|
|
|
* corrupted, assuming that the total percentage of all corrupted documents in that |
|
|
|
|
|
|
|
* database still falls below the specified `corruptAlertThreshold` option's value. |
|
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
* Durability works similarly to major databases: compaction forces the OS to |
|
|
|
|
|
|
|
* physically flush data to disk, while appends to the data file do not (the OS is |
|
|
|
|
|
|
|
* responsible for flushing the data). That guarantees that a server crash can |
|
|
|
|
|
|
|
* never cause complete data loss, while preserving performance. The worst that can |
|
|
|
|
|
|
|
* happen is a crash between two syncs, causing a loss of all data between the two |
|
|
|
|
|
|
|
* syncs. Usually syncs are 30 seconds appart so that's at most 30 seconds of |
|
|
|
|
|
|
|
* data. [This post by Antirez on Redis persistence](http://oldblog.antirez.com/post/redis-persistence-demystified.html)
|
|
|
|
|
|
|
|
* explains this in more details, NeDB being very close to Redis AOF persistence |
|
|
|
|
|
|
|
* with `appendfsync` option set to `no`. |
|
|
|
*/ |
|
|
|
*/ |
|
|
|
class Persistence { |
|
|
|
class Persistence { |
|
|
|
/** |
|
|
|
/** |
|
|
|