NDOUtils Developers Wanted
Michael Friedrich
michael.friedrich at univie.ac.at
Mon Jun 29 11:08:59 CEST 2009
Hi,
just as a remark to your TODO list.
Ethan Galstad wrote the following on 23.06.2009 03:33:
> - Optimize table structures
Supporting Oracle, you will have to remove the table_prefix (saves 7
characters) and rename at least one table (31 chars). And, of course,
the primary key needs to be only 'id' instead of '[table_name]_id'. All
other stuff will remain in the *.sql definitions like optimizing stuff
and adding indexes.
For what it's worth, the main db scheme has to be reworked, too... but
this will take more time in C.
> - Optimize table record cleaning
...and to check which data is really necessary. E.g. the timed_events
queue will be written to the database and heavily cleaned up. In larger
environments, this will fail at startup of ndoutils and during running
the process, too.
Imho, there's the need of either "outsourcing" the housekeeping or
changing the data_processing_options to another default than -1 - get
less but more performance in the first place. Meanwhile some unused data
could be completely dropped off, but this has to be evaluated with the
main Nagios plugins and which data they normally are using.
> - Add libdbi support for multiple databases (Postgres, Oracle, etc)
Be aware of the fact that the current libdbi driver implementation is
heavily broken and unfinished work. It won't work right now as you may
have read on the users mailinglist.
Even though not all queries are the same for all RDBMS, there is need of
customized queries per RDBM too. Normalized INSERT statements (no SET,
but VALUES) and adapted UPDATE(INSERT ON DUPLICATE KEY vs. MERGE
queries. Also the time functions are RDBM specific and different.
Right now, there will be 3 applications using the libdbi and wanting
Oracle RDBM support:
* NDOUtils
* IDOUtils
* Merlin
All of them will focus on the libdbi. So the biggest problem is to
rewrite the libdbi driver for Oracle. I have started to discuss on the
libdbi-devel mailinglist, the libdbi as is needs to be adapted e.g. for
using parameter bindings.
Taking a deeper look on heavily used queries in the NDOUtils parameter
bindings are a big advantage causing lesser performance problems (cached
queries). Actual code of NDOUtils Oracle has finished that for the most
often called queries but in this direction there is need of doing that
more often.
Summed up, libdbi and Oracle are not really an option right now. Maybe
re-implementing the driver and adapting the libdbi api (which will take
some time to code, debug and finally get the packages into repositories
too) or seeking other solutions independently of the libdbi. The ocilib
is such a project but the code in NDOUtils would be like:
switch(db_type) {
case mysql:
libdbi_init(mysql);
case pgsql:
libidbi_init(pgsql);
case oracle:
ocilib_init(oracle);
Or similar - need to get more deep into that but my ressources a quite
low this time.
Besides I hope that the actual ideas of the IDOUtils from Icinga will be
merged into actual NDOUtils code and the development can be done on
quite the same code base (and if it's GIT on both sides, merging won't
be that big problem).
Kind regards,
Michael
>
>
>
> - Ethan Galstad
>
--
DI (FH) Michael Friedrich
michael.friedrich at univie.ac.at
Tel: +43 1 4277 14359
Vienna University Computer Center
Universitaetsstrasse 7
A-1010 Vienna, Austria
------------------------------------------------------------------------------
More information about the Developers
mailing list