[odb-users] Performance and another question

[Andrew Cunningham]

Hi Adnan,
Thanks for your reply. I have CAE simulation data with over 200 separate
C++ classes. So I have a complex object model and a LOT of data per model (
often 20 GB per 'model/file/database'). We are "single user" but will be
running multiple threads during computation . Each thread typically reads
from the database, with some limited writing from each thread.
Obviously  I will have to greatly simplify my 'object model' for the
persistent classes. The reason ODB is so attractive is the ease with which
we can make a class persistent and experiment.


Andrew


On Tue, Jun 2, 2015 at 1:56 AM, Adnan RIHAN <axel50397 at gmail.com> wrote:

> Hi Andrew,
>
> I’m not yet working with intensive tasks, so I can’t provide you my
> personal experience.
>
> However, I think the choice of a DB backend depends on what type of data
> you’re dealing with, their size, how often, concurrency and the usage of
> the project.
>
> For example, if you’re making a simple Cash register app (as I’m on,
> currently), you’re dealing with simple little values (short strings and
> integers), multiple time a day, no concurrency (except if you have multiple
> cashiers) and the DB expanding linearly with time. I think sqlite is the
> best for this kind of project, it’s light, portable, and can handle a huge
> quantity of data. So maybe, you will never have to care about the database.
>
> I can’t find another example for non in-process DB, but basically, if you
> need concurrency, caching, speed, huge complexity (constantly joining many
> many tables) and if you know the data will expand exponentially, then
> you’ll need a server. The server (apart from the ORM) is capable of
> expanding (Clustering/NAS/SAN/bigger disks), caching (if you’re joining a
> lot but accessing the same joins multiple times a day), and can be anywhere
> (accessed via network).
>
> These are few details I think about for the choice of a type of backend.
> Then, I look around for some benchmarks to see which would be the best for
> my architecture. Sqlite is in-process, MySQL is a server but can also be
> loaded as an embedded server (http://www.mysql.com/oem/), and so on.
>
> - SQLite, when to use: https://www.sqlite.org/whentouse.html
> - MySQL, known enough
> - MariaDB, comparison chart: https://mariadb.com/products/mariadb
> - And then you have the NoSQL databases (plus DB like Oracle, SQL Server,
> ...), but I’ve never worked with them.
>
> --
> Cordialement, Adnan RIHAN.
> Directeur-Gérant de Eolis-Software, société de services informatiques.
>
> GPG: 5675-62BA (https://keybase.io/max13/key.asc)
> -> Si vous n'utilisez pas GPG mais souhaitez quand même m’envoyer un
> e-mail chiffré: (https://encrypt.to/0x567562BA).
>
>
>
> On 2 juin 2015 at 10:23:32, Andrew Cunningham (andrew at a-cunningham.com)
> wrote:
> I am evaluating ODB as a replacement for an 'abandon-ware' commercial
> OODB.
>
> I have a question regarding performance that other ODB users might be able
> to help with
>
> If we were looking for the best performance when working with lots of data
> for a single user ( single process/multiple threads) on a Windows
> workstation what would you suggest as the best SQL DB option ( i.e. SQLIte
> vs MySQL vs. Postgres etc)
>
> Obviously I think that most people would suggest SQLite as you are writing
> ‘in process’ with no external communication to a server process. However,
> when working with our existing OODB vendor we got much suprisingly better
> performance from using a 'local' server vs. ‘in-process” as the server
> process could perform disk operations without blocking the client process.
> The server client communication was over shared memory not network sockets
> when both were on a local machine.
>
> One more question: What would people recommend for modeling a ‘graph’ as a
> persistent data type in odb. I use boost::graph currently. I am trying to
> think of a way to do it in ODB is not too awfully slow/clumsy/messy. Just
> wondering if it has been done before.
>
> Andrew
>
>
>