NDO - why not innodb?

[Kevin Menard]

I haven't heard of OpenDBX, so I can't speak intelligently on it.  In
higher-level languages, you can find Object-Relational Mapping frameworks
that dual-function as DB wrappers.  They normally take care of any DDL
specifics (e.g., auto-increment types).  I'd imagine OpenDBX does the same.

With regards to vacuuming, it's traditionally been an admin task delegate to
a cronjob.  More recent versions of Postgres have simplified that by
integrating the vacuuming as part of the daemon [1].

[1] 
http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html#AUTOVA
CUUM

-- 
Kevin 

On 8/20/07 12:32 PM, "Ethan Galstad" <nagios at nagios.org> wrote:

> OpenDBX (http://www.linuxnetworks.de/doc/index.php/OpenDBX) looks like 
it
> might be a good abstraction layer.  Not sure how DB-specific table
> 
maintenance tasks would be handled (e.g. vacuuming Postgres tables after 
a
> large # of deletes).

I also wonder about performance hits.  The decision
> between using MyISAM 
or InnoDB tables might be more of a non-issue if an
> abstraction layer is 
used.

Comments/ideas?

Sébastien Barbereau wrote:
>
> Just adding my two cents here:
> The question of wether to use InnoDB or
> MyISAM, or MYSQL rather than 
> PGSQL comes down IMHO to the question of your
> DB admin. I had mixed 
> reports on performance with InnoDB and/or PGSQL, and
> I feel more 
> comfortable with MySQL as I never had problems with it. On the
> other 
> hand, InnoDB foreign key support is really nice considering the ndodb
> 
> table structure.
>  
> What would maybe be more interresting (for the
> community) is rather than 
> stick to a specific database kind, use an
> abstraction layer in the ndo 
> module. Therefore one could use whatever
> database you wish : mysql, 
> pgsql and why not oracle or sybase? I don't
> think it really mathers to 
> Nagios what kind of DB we are using (it should
> not).
> 
> This could have a course some "performance" drawbacks in terms of
> query 
> optimization ...
>  
> Seb.
>  
> On 8/20/07, *Hendrik Bäcker*
> <andurin at process-zero.de 
> <mailto:andurin at process-zero.de>> wrote:
> 
>
> Hi Kevin,
> 
>     Kevin Menard wrote:
>      >
>      > I'd highly recommend
> using InnoDB.  Actually, I'd recommend using
>      > PostgreSQL, but it's not
> my intention to start a flame
>     war.  Given the
>      > critical nature
> of the data being logged, I'd ensure data
>     consistency with
>      >
> InnoDB tables.
>      >
> 
>     Looking at my MySQL based NDO DB with 7000+
> Service Checks I can see
>     tons of inserts every second.
> 
>     I've
> only heard that PostgreSQL might be better in performance and for
>     this
> huge amount of data.
> 
>     I also do not want a flame war too, but I would
> just like to know what
>     other people are thinking in the manner MySQL vs.
> PostgresQL.
> 
>     Up to now I can say that the MySQL Process on my nagios
> server is eating
>     up the cpu's and I am thinking about to test it with a
> postgresql.
> 
>     I am not a DB engenieer so please don't ask about my
> config params like
>     different kind of tunings ;)
> 
>     Regards
>
> Hendrik
> 



Ethan Galstad,
Nagios Developer
---
Email:
> nagios at nagios.org
Website:
> http://www.nagios.org

-------------------------------------------------------
> ------------------
This SF.net email is sponsored by: Splunk Inc.
Still
> grepping through log files to find problems?  Stop.
Now Search log events and
> configuration files using AJAX and a browser.
Download your FREE copy of
> Splunk now >>  
> http://get.splunk.com/
_______________________________________________
Nagios-
> devel mailing 
> list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/li
> stinfo/nagios-devel


-- 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/