Hacker News Reader

Comment by zekenie | Hacker News Reader

(Maybe silly) question: if we're talking about the node implementation, why use this over mongodb?

Embeddable databases are nice and portable. It's like Sqlite versus Postgres - the latter may be more robust, but requiring it as a dependency greatly increases the effort needed to deploy your software. If an embedded database can do the job, it may be worth it as a matter of convenience.

Thanks!

Same reason why one might use SQLite over MySQL. Ease of configuration, no need to have a full blown DB server, lighter weight which makes it great for things like Raspberry Pi type hardware. For hackathons I've found it simpler to just use SQLite so I don't have to deal with MySQL configuration headaches that come up when IP addresses inevitably change.

Outside of NodeJS, I can see this being pretty handy for iOS development. I'm not a huge fan of taking JSON from an API, converting it into an NSDictionary, and then placing it into Core Data and RESTKit doesn't always fit my needs. I think this might work well for local persistence of API data for an offline mode.

Are there issues with concurrency though when used in a web application?

Yeah. But if you're not publishing it to the entire world, you probably won't run into them. And there are many other applications where databases are useful, that aren't network servers of any kind.

So is it possible to use this as a database in a web app? What sort of problems would come up with concurrency?

Since the storage engine is a modified version of Tokyo Cabinet, I am assuming that you can have simultaneous readers, but a writer will lock everyone else out. From the Tokyo Cabinet specs [0]:

'Tokyo Cabinet provides two modes to connect to a database: "reader" and "writer". A reader can perform retrieving but neither storing nor deleting. A writer can perform all access methods. Exclusion control between processes is performed when connecting to a database by file locking. While a writer is connected to a database, neither readers nor writers can be connected. While a reader is connected to a database, other readers can be connect, but writers can not. According to this mechanism, data consistency is guaranteed with simultaneous connections in multitasking environment.'

[0] - http://fallabs.com/tokyocabinet/spex-en.html

Use coroutine based servers, everytime there's guranteed one thread accessing the db.

I'd switch to a full DB server for a production Web App. If you're using an ORM it should be pretty trivial (the one time I've done it, Perl's DBIx::Class made it as easy as changing the connection info hash). I'm not sure how many people hand code their SQL at hackathons but I am not one of them ;).

I use SQLite in small and medium-traffic web apps (the largest one getting about 80000 hits daily) all the time with no concurrency issues whatsoever. My rule of thumb is that if you don't expect your app to require more than one server, sqlite will work just as fine as postgres or mysql.

Interesting! For pragmatic reasons, or stress testing SQLite?

For convenience mainly.. It saves me from having to install a "serious" RDBMS, import data, etc. With SQLite, deployment is simply copying the db file to the server.

Reply on news.ycombinator.com