Hi Vladimir, I think that's correct, since ESME uses Mapper it will run on any database that Mapper supports. I believe that this is dependent on access to the database using a driver that provides a JDBC interface, but I'm not sure. I think that all databases that Mapper supports are relational, though I suppose you could try using a JDBC driver for a non-relational database (like HBQL for hBase - http://www.hbql.com/examples/jdbc.html).
Cheers, Ethan On Thu, Aug 4, 2011 at 1:05 AM, Vladimir Ivanov <[email protected]> wrote: > Ethan, > > Correct me if I'm wrong, but at the moment ESME should be able to run on any > *relational* database due to all entities are stored/retreived via Lift > Mapper persistence layer which implies traditional relational store. It's > absolutly possible to use Lift Record persistence layer though which is > intended for NoSQL databases, such as MongoDB. > > Vladimir > > 2011/8/3 Jack Park <[email protected]> > >> Thanks, Ethan. >> I'd like to know more about using MySQL. >> Indeed, I'd like to know more about other classes of databases, e.g. graph >> databases. >> >> Still, while hit rate is one aspect of scalability, when you talk about >> "safely cached", I wonder about the combinatoric aspect of scalability, say, >> a million users each with timelines in the hundreds to thousands long, and >> all the entailed message objects. Are you thinking in terms of, say, >> external memcached solutions, or just large memory models and load >> balancers? >> >> Curious minds... >> Thanks >> Jack >> >> >> On 8/3/2011 4:56 AM, Ethan Jewett wrote: >> >>> Hi Jack, >>> >>> It should be able to run on any Java application server with any >>> database via JNDI or with any JDBC database by providing JDBC >>> connection information in a .props file. I believe that on Stax (now >>> CloudBees) we are using a MySQL database. >>> >>> Regarding scalability, the design of ESME is such that it doesn't rely >>> much on the database for scalability. Operations should generally >>> happen on data in memory, and there shouldn't be access of the >>> database on most operations. We can do this because the data model has >>> messages as immutable objects (you can't change or delete them), so >>> they can be safely cached and we can rest assured that they will never >>> be out of sync with the database. >>> >>> I'm fairly sure we did some performance tests a while ago that showed >>> ESME was able to support thousands of concurrent users on a fairly >>> small server without trouble, but I can't currently find that >>> documentation. Maybe someone else knows where it ran off to? Seems >>> like something we should have on a our website (and a test that we >>> should redo at some point). >>> >>> Cheers, >>> Ethan >>> >>> > > > -- > Best Regards, > Vladimir Ivanov >
