I was about to post some of what Paul just did

On mobile devices the bottlenecks are in CPU and flash storage, erlang (and
therefore couch) dont have a true idle state, but they do very well at
limiting battery usage on devices, the Android version is now down to 4/5 MB
of flash storage which is comparatively small (adobe flash takes up 20MB)

The phones do generally have a lot of storage to spare, which is where couch
keeps its data, and as both replies have already said, the typical use case
is for a small subset of a users data.

Cheers
Dale

On 30 June 2011 01:50, Jens Alfke <j...@mooseyard.com> wrote:

>
> On Jun 29, 2011, at 4:59 PM, Zdravko Gligic wrote:
>
> > In many places I have read how Erlang runs on small devices and how
> > (as a result) it is very frugal with resources.  I think that I have
> > read that or at least something to that effect.
>
> I’m not an Erlang expert, but the “typical” use-case Erlang was designed
> for was running Ericsson’s telecom switches, which are not small devices.
> The resource advantage it has is very lightweight parallelism, so you can
> run tens of thousands of ‘processes’ at once without consuming huge amounts
> of RAM in stack space.
>
> > Whenever I come across such CouchDB resources related postings, I keep
> > thinking about all of those Couches on all of those mobile devices (at
> > least in all of those presentations and slides) and asking my self
> > "how do they do that" ?
>
> A mobile device is typically going to use CouchDB to store personal-sized
> data sets, like your to-do list or phone book or bug queue, or your save
> state in a game. And it’s probably going to have one client at a time,
> connected by loopback on localhost, sometimes making a single sync
> connection to an upstream server database.
>
> In other words, it’s not going to be serving a million-document corporate
> database to thousands of clients simultaneously.
>
> For those sort of workloads, CouchDB runs fine on a mobile device,
> especially if the client compacts the database frequently.
>
> SQLite might be a good comparison — you could use it to manage very large
> databases [although maybe not so well as MySQL or Postgres] and for that
> purpose you’ll want a good amount of RAM and disk space. But for small data
> sets, it fits fine into embedded devices like iPhones and even microwave
> ovens.
>
> —Jens

Reply via email to