MongoDB as a main backend for storing Zabbix configuration

[DRVTiny]

MongoDB is the best backend for storing Zabbix configuration, because of its object-oriented srtructure.
I believe that the Zabbix static configuration and Zabbix operative data must be stored separately.
As of now, its stored in the same RDBMS in the same database, i.e. both mostly read-only data and intensively inserted data. I think it is awful by design. Zabbix configuration must be stored in the separate database or, better, in the object-oriented storage such as MongoDB.

[kloczek]

MongoDB is the best backend for storing Zabbix configuration, because of its object-oriented srtructure.
I believe that the Zabbix static configuration and Zabbix operative data must be stored separately.
As of now, its stored in the same RDBMS in the same database, i.e. both mostly read-only data and intensively inserted data. I think it is awful by design. Zabbix configuration must be stored in the separate database or, better, in the object-oriented storage such as MongoDB.

Problem only is that MongoDB is not object but more like document oriented database.
Rows or records in RDB are kind of objects as well.
You need to be a little more precise when you are mentioning something like "object oriented <something>". In context of different <something> "object" may carry completely different meanings.

Zabbix uses RDB in context of his own configuration only as kind of secondary storage. All zabbix components (server, proxy and agent) keeps monitoring configuration in memory.
If server or proxy would be constantly querying MongoDB for all needed configuration chunks probably tey will be waaay sloooower that it is now.

[DRVTiny]

When i say "use MongoDB instead of RDB" i mention only that i said. I know that Zabbix server/proxy stores its configuration in memory and operate it in memory, but frontend and Zabbix API uses RDBM.

Problem mainly in the Zabbix API limitations which may be fully resolved with MongoDB: instead of converting object requests to SQL SELECTS and UPDATE's we may send this requests directly to MongoDB through the native Mongo-adapter which exists for a lot of prgramming languages. This will be very helpful, essentialy if we keep in mind that the Zabbix API in current state is very slow and limited and, unfortunately, development of the API is obviously freezed: there are no new features and no fixes to the Zabbix API in the latest versions of Zabbix.

[kloczek]

[..]
Problem mainly in the Zabbix API limitations which may be fully resolved with MongoDB: instead of converting object requests to SQL SELECTS and UPDATE's we may send this requests directly to MongoDB through the native Mongo-adapter which exists for a lot of prgramming languages. This will be very helpful, essentialy if we keep in mind that the Zabbix API in current state is very slow and limited and, unfortunately, development of the API is obviously freezed: there are no new features and no fixes to the Zabbix API in the latest versions of Zabbix.

Maybe my knowledge about MongoDB is not enough but I really don't understand what it may solve.
Many technologies provides bindings for different languages. It doesn't mean that we should try to use something only because such interface exist

Zabbix APIs requests may be slow because they are not handled by zabbix server process but are handled by web fronternd php code. To improve speed of such request you should try to use "standard" web server optimizations techniques.
From https://www.zabbix.com/wiki/doku.php?id=doc/api

"The API is implemented in JSON-RPC. That means, to call any function, you need to send a POST request to http://<zabbix_server>/zabbix/api_jsonrpc.php with input data in JSON (i.e. JavaScript structure textual representation) format in the request body and interpret the answer formatted the same way."

My understanding is that moving this part straight into zabbix srv is on road map.
You may try to solve your problems with API request by taking closer look on what is going on with such request in your httpd srv.

You must be sure that in your case all what happens on httpd layer does not create kind of bottleneck

Tomasz

[BrandStorm]

When i say "use MongoDB instead of RDB" i mention only that i said. I know that Zabbix server/proxy stores its configuration in memory and operate it in memory, but frontend and Zabbix API uses RDBM.

Problem mainly in the Zabbix API limitations which may be fully resolved with MongoDB: instead of converting object requests to SQL SELECTS and UPDATE's we may send this requests directly to MongoDB through the native Mongo-adapter which exists for a lot of prgramming languages. This will be very helpful, essentialy if we keep in mind that the Zabbix API in current state is very slow and limited and, unfortunately, development of the API is obviously freezed: there are no new features and no fixes to the Zabbix API in the latest versions of Zabbix.

This make no sense, just extra abstraction layer over standard features and no flexibility and performance gain. What we really need is to have additional in-core service to act as console/agent service to remove PHP based API and switch to in-core requests. In this case we can utilize internal cache, decrease the amount of SQL requests and send commands directly without socket connection.

[kloczek]

This make no sense, just extra abstraction layer over standard features and no flexibility and performance gain. What we really need is to have additional in-core service to act as console/agent service to remove PHP based API and switch to in-core requests. In this case we can utilize internal cache, decrease the amount of SQL requests and send commands directly without socket connection.

You are 100% right. However you must understand that as same as many other software projects zabbix is evolving being

Something which was probably only internally kind of abstraction layer necessary to develop and extend web interface in civilized way was probably spotted at some point as good interface to build customers extensions. I'm not sure is it was intentional development and or only coincidence ..
Now zabbix API interface is part of official zabbix customers interface and all changes done by zabbix developers must be done keeping in mind that someone is using it as entry point of own tools. Zabbix API interface is under official paid support contract as well.
IMO zabbix API still is on kind of early stage and possibility that after moving it outside webfrontend interface it may be rewrited to something completely new is quite high. Probably after this web frontend API may be in kind of frozen state for one or two major releases.

Importance of zabbix API is slowly growing. I'm sure that at some point growing pressure here will cause that it will be moved away from web frontend to embedded it in point where will be possible to gain better parameters from point of view of performance

You may probably even help in this process if you have enough skills and spare time. However to be involved in such process you must posses as well enough level of understanding of current state. Dropping proposition like "lets try to use MongoDB because it looks fabulous" isn't TheProperWay(tm) ..

[BrandStorm]

You are 100% right. However you must understand that as same as many other software projects zabbix is evolving being

Well, I have nothing against current version of ZABBIX API, i was just talking about wrong idea of mongoDB as backend service for UI. It's not a question of good or bad sides of current version, but just a direction for right move of ideas for DRVTiny.
So, my message was about real thing zabbix needs, but not about what "what we have now is awful".

I'm sure that at some point growing pressure here will cause that it will be moved away from web frontend to embedded it in point where will be possible to gain better parameters from point of view of performance

Well it will take too much work of developers to rewrite or even re-create the logic of current core code.