embedded database to use with Photon server

Options
mindlube
edited June 2012 in Photon Server
Just thought I would share; If anyone is looking for an embedded .NET database to use with their Photon server project, this is an interesting one! It's an open-source fork of Perst db.

http://blog.kowalczyk.info/software/vol ... abase.html
https://github.com/kjk/volante

Comments

  • dreamora
    Options
    The tech itself seems very interesting, especially for .NET client usage :)

    But for the server it sounds like a very bad idea and actually the page points that out already in the introduction too through ausage scenario like Sqlite which is for standalone desktop apps, not massive multiuser services as its not concurrent and scaleable

    You shut down the whole purpose you got Photon initially by using an embedded database (the purpose I mean is scaleability) cause you force the DB onto the server too which is meant to react in 0s response times optimally without massive RAM overheads and lookup locks.
    You receive a much better performance and especially performance per cost by using 2 machines, one for Photon and one for the DB, so you can focus on RAM on the db node and cpu on the photon node. (in a trivial setup. You can go much more complex naturally but in that case you know what you are doing and expect to get and wouldn't touch such a type of DB anyway)
  • Yes volante is similar to SQLite. My use case is not massively multiplayer, nor real time. It's a turn based casual game (dominos). There is very little computation going on server side. Mostly photon will just be storing game states and answering subscriptions with events. For simplicity and cost savings, I am putting the photon server and database on the same machine. I'm using softlayer.com and may scale up my cloud instance up to 16 cores and 16 GB RAM. But cannot afford more than 2 cores to begin with. Pretty soon here I'm going to do some benchmarks and see how many clients this setup can handle.

    But thanks for your feedback; it's good to be aware of trade-offs when choosing tech.

    Alex
  • Also because I'm accessing volante from another PoolFiber, not the requestFiber, concurrency issues should be OK. Benchmarking could prove me wrong though :|
  • dreamora
    Options
    I see. In that case with only 2 cores, considering this is indeed a potential path to go especially if you don't need it for high frequency / high data amount.
    Just ensure to have enough RAM to allow it to operate to a fair degree in RAM.

    Mind if I ask what spoke against System.Data.Sqlite & System.Data.SqliteClient or somethinlig like Csharp-sqlite (though there the lack of support could be a good reason) or DBLinq?
    I've recently been evaluating db technologies and am unsure what would make most sense in some cases but considered giving MongoDB a shot.
  • I was going to use SQLite, but I mostly develop on a Mac with Monodevelop, so prefer to avoid windows native-code solutions :)
    DBLinq and Csharp-sqlite both look interesting- thanks was not aware of them.

    Alex
  • dreamora
    Options
    Sqlite has nothing to do with windows native actually :)
    System.Data.Sqlite works on windows, osx, iOS and if I recall right even android from Unity out of the box (and out of monos box) ;)
    Windows is the only platform where you will need to install sqlite first to the system but otherwise they are equal (on Apple operating systems its always there, CoreData relies on it)
    But that explains your motivation behind it :)
  • duke
    Options
    I'd go for RavenDB embedded.
  • @dreamora- I am trying System.Data.SQLite now, thanks for that info.

    @duke- ravendb looks interesting too, but is document-oriented and storing JSON text, and using Lucene indexes (full text search) it looks like it might be overkill for when the schema is not changing- like storing simple hiscores and game states.