You haven't sent enough information to make a reasonable judgment.<br><br>what is "lots" in the phrase "lots of state transactions per transaction" - 10? 1000? 10^10<br>what is "high" in "extremely high"<br>
<br>You need to quantity words like "lots" and "high" with numbers or ranges of numbers <br><br>How many transactions/second?<br>How many simultaneous sessions?<br>How large is the state<br>Do you want the fault-tolerance?<br>
What are the latency requirements<br>Up-time requirements<br><br>and so on.<br><br>Sounds to me like you want a fault-tolerant low-latency key-value store.<br><br>CouchDb will store all the data forever, which is probably not what you want. Scalaris or Riak <br>
sounds like a better fit.<br><br>/Joe<br><br><br><div class="gmail_quote">On Mon, May 2, 2011 at 8:56 AM, David Mitchell <span dir="ltr"><<a href="mailto:monch1962@gmail.com">monch1962@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi all,<div><br></div><div>I've got to build an enormous finite state machine (FSM) to hold state for tens of thousands of in-flight transactions.  The various state transitions aren't well known yet; all I know is there's going to be lots of state transactions per transaction, transaction volume will be extremely high, and I'll probably have a bare minimum of time to throw together a working solution ;-></div>

<div><br></div><div>In the past I've used mnesia to hold transaction state for similar projects, but I've read a few articles about problems with it scaling and have a bit of a concern on that count for this particular project.  I've been using CouchDB for a few unrelated projects recently, and have been impressed with it on every score - on the surface it seems to be a good fit for my specific problem.  However I haven't stumbled on anybody using CouchDB as a high throughput, transitional data store - everything I've read about it has involved CouchDB working more or less as a NoSQL version of a "traditional" write-once, read-often data store.</div>

<div><br></div><div>My application is far more "write-once, update-many-times-very-quickly, delete" from a data perspective.</div><div><br></div><div>Has anyone used CouchDB as a FSM data store in a similar project in the past?  Pros and cons?  Any tips or suggestions?</div>

<div><br></div><div>Thanks in advance</div><div><br></div><font color="#888888"><div>David Mitchell</div>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br>