[Haskell-cafe] pure Haskell database
Sterling Clover
s.clover at gmail.com
Fri Oct 3 20:46:31 EDT 2008
So the issue is one writer, many readers across processes? Creating
an actual mini-db-server might be the proper way to do this. Expose a
simple socket by which other processes can query the DB state. If you
need persistence between runs of your main server you can always
snapshot on shutdown, or for error-tolerance you can also write to a
transactional log (probably with a single writer thread that takes
input over a chan). Assuming its still in good shape, haxr [http://
www.haskell.org/haxr/] would simplify writing the socket portion.
Depending on how you wrote the surrounding server, you might be able
to avoid mvars altogether (i.e. if your server was built in an
"agent" style with only a single request handler thread, then state
could just be passed between recursive calls [or even stashed in a
State monad] and the request serialization would handle concurrency
issues for you).
Regards,
S.
On Oct 1, 2008, at 3:09 PM, Manlio Perillo wrote:
> Graham Fawcett ha scritto:
>> [...]
>>> Never though about sparse array, what is the advantage?
>>> For the complexity, the same of a good hash map.
>> Almost certainly worse complexity than a hash map; but the overhead
>> could be much smaller. If (for example) you only needed a small
>> number
>> of key/value pairs (say, hundreds of thousands), you could implement
>> your "database" trivially, e.g. a NULL-terminated array of key/value
>> structs in shared memory. (Though having separate arrays for keys and
>> values might help cache locality and boost performance). Lookup might
>> be O(n) but with a small-ish N and with such a low overhead, it could
>> perform very, very well.
>
>
> This seems an interesting idea, thanks.
>
>
> Manlio Perillo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
More information about the Haskell-Cafe
mailing list