3. WHY?
¢ In-memory is faster than I/O
¢ SQLite is great but there is no NoSQL / document-oriented equivalent of it
¢ SQLite is cumbersome in a mobile / embedded context (who can be bothered
with SQL in a mobile app?)
¢ Phonegap and Node-Webkit apps would benefit from a javascript database where
data is plain javascript objects, and persisted on disk as JSON.
¢ Traditional databases rely on platform libraries which impose portability contraints
and version conflicts. Data is frequently 'locked-in'
¢ For many applications NoSql is a far more preferable and better performing
approach than relational data when working with complex object stores which are
built for consumption.
4. Enter Loki
¢
LokiJS is compatible with browser and node.js
¢
Persistence to disk on inserts/updates/deletes (in node.js, node-webkit and cordova
environments)
¢
Available on bower and npm
¢
Extremely low footprint - 28KB uncompressed!!
¢
Supports indexing, and uses Binary Search for search granting fast performance
¢
NoSQL jargon: documents, collections, map, reduce
¢
Compatibility: dependency free, native, pure javascript runs across many js environments
¢
Portablility : entire database state can be serialized as a single entity to be restored in an
identical state or transferred across environments as a single JSON entity.
¢
Performs better than similar products (NeDB, TaffyDB, PouchDB etc.), and it's much smaller
6. Updates
¢ Updates are optional. LokiJS holds references
to objects so there's no need to update an
object. However, update(obj) can be called to
force re-indexing of collections.
8. Querying (Mongo Style)
Mongo style queries will benefit from access to
index optimizations.
¢ Declarative query definition via a query object
¢ Current supported operators include $eq, $gt,
$gte, $lt, $lte, $ne, $regex, $in, $contains
¢ Supports dot notation for deep querying
9. Querying (Javascript views)
¢ Means of specifying complex 'edge case' query filters
¢ Write your own javascript filter function which can be
anonymous or persisted with a name as a view.
¢ Has access to the entire (possibly hierarchical) document
object
¢ Used for chained queries and dynamic views
¢ Worse performance / cant be serialized (need to be
reattach to dynview on load)
10. Fluent API
You can resort to functions to obtain your data by
leveraging the built-in ResultSet class:
doctors.chain()
??.find({?doctor:?{?'$gte':?9?}})
??.where(function?(obj)?{?return?
obj.name.indexOf(^t ̄)?!=??1;?})
??.simplesort(^name ̄)
??.data();?//?this?exposes?the?data
11. Dynamic Views
Views hold references to filtered data to optmize search even further
(avoiding to scan the entire collection).
Thet maintain freshness of query results optimally as they are notified of
data inserts, updates and deletes.
var?view?=?doctors.addDynamicView(^latestDoctors ̄);
view.applyFind({?doctor:?{?'$gte':?8}});
view.applySort(function?(a,?b)?{
??return?a.doctor?<?b.doctor;
});
//?inspect?the?data
console.log(view.data());
12. Persistence
¢ Loki now supports three primary persistence methods : filesystem
(Node), localStorage (cordova/browser), and indexedDB
(cordova/browser)
¢ A new persistence adapter interface allows for interoperability with
other popular and/or custom data stores. Community members can
develop and submit adapters for popular datastores and submit a pull
request to share them.
¢ Autosave/Autoload capabilities exist for you to optionally utilize for
automating and bootstrapping persistence.
13. IndexedDB Support for browsers
¢ Loki now implements an indexedDB App/Key/Value Catalog,
implemented using the new persistence adapter interface.
¢ This catalog can contain as many databases as your storage
quota allows, organized by application. This allows grouping,
listing and querying the catalog of databases by 'application'
groups.
¢ Loki's indexedDB adapter supports console use for easily
managing your catalog from a browser console.
14. Summary
¢ Use collection operations (insert, update, delete)
for document-oriented maintenance
¢ Use collection operations (find, where) for optimal
query performance
¢ Use resultset with fluent-like syntax for defining
complex query-oriented pipelines
¢ Use dynamic view for defining views which inherit
the resultset pipeline, yet avoid needing to requery
15. RoadMap
¢ MRU cache / Key-value store option
¢ TCP and HTTP Wrappers to enable running
LokiJS on dedicated (virtual) machines
¢ Replication
¢ Horizontal scaling
¢ MongoDB API subset compatibility