Any experience with NuoDB?

[BDiE8VNy]

Hi!

Has anyone ever played with NuoDB as database backend for ZABBIX?
We've NuoDB on the radar for some time and have a positive view about it.

I'm a big fan of PostgreSQL but this seems to be very promising (If not swallowed by Big Red)
I know it's still beta but maybe anyone already made some tests in connection with ZABBIX

[rsvancara]

Drivers

I think the challenge would be driver support. Currently Zabbix supports SQLite, MySQL, Oracle and Postgres. Someone would have to go through the database API for zabbix and add support for Nuodb, that means all those #IFDEF statements for the database abstraction would have to include entries for NUODB. Even though database vendors claim ACID compliant there are always subtle enough differences that require different implementations such as datatypes? Oracle uses number, postgresql has int, double, and float. MySQL has smallint, bigint, float......

[BDiE8VNy]

I haven't taken a look into the source code of Zabbix for this particular case. But I think You're right, Zabbix doesn't use ODBC for its database yet and as far as I know NuoDB, that's the prefered way of accessing the database (Except for some exceptions).

Accessing the data in NuoDB should be "Standard SQL". Sure, the table of compliance has some gaps, but they should be filled in the future.

Why might data type name conventions be an issue for insert/update/delete statements of an existing table?

[rsvancara]

Data Types

They will not for insert and update operations, however how the underlying database stores them ma affect the performance (although this should be minor) but it will impact the sizing requirements as a NUODB varchar/text equivalent may be represented differently. Especially given the distributed nature of the database, there will have to be additional metadata to track where everything is stored. Additionally the types of indices supported will also affect performance. But I have to assume that NuoDB will have an equivalent of a rtree and btree index type.

Additionally, for something like Zabbix, I would not want to use ODBC as it just adds another layer complexity and possible performance issues. I would prefer to see a native driver implementation.

[BDiE8VNy]

If I understand the way NuoDB manages data right, there is no connection in terms of data types and (storage) performance. Yes, there are data types, but the data is not stored in a traditional way that tries to map for instance a table structure on a block device. The storage is key-value based and stores just "Atoms". Regardless of that, storage is used to ensure persistence and not performant access. Performance is achieved by in memory available data and parallelization.
There is no meta-data to keep track where everything is stored. There is a very smart messaging system (what I think the Patent is about) combined with MVCC.

I don't know much about ODBC performance issues but the way Zabbix accesses the database should scale in the same way that NuoDB does.

NuoDB needs rethinking in several aspects. Yes, it's standard SQL. But teasing out the strength/promises of NuoDB needs some conditions in development.

[wchaudry]

NuoDB Storage

Hi there. My name is Wiqar and I am the Technology Evangelist here at NuoDB.

Thanks for your interest in our product and we are very excited and encouraged by the healthy dialog taking place on this forum and many others.

I just wanted to reach out and add some additional color to the three main questions I see being discussed:

1. Access to our database - We offer ODBC and JDBC access to our database from a client tools perspective. We also have drivers for php_pdo and zend, active record for ruby on rails, and hibernate with more on the way. To check out what other types of drivers are in the works check us out @ https://github.com/nuodb.

2. SQL compliance - We support all of the standard data types supported by SQL. Int, decimal, string, blob, datatime, etc... we actually got a good feedback on our datetime support and we made it better.

3. Performance - Performance is top of mind for us. The benefits of our in-memory transaction engines are obvious. The more memory you have the better your queries will perform. However, as you expand the number hosts you can add additional transaction engines for achieving even more scale.

Let me address Storage Managers. Yes they are responsible for making your data durable, however, that doesn't mean that the choices you make at the storage manager level don't address or add to performance. Storage managers also have an in-memory component to them. The more memory you allocate to a storage manager the faster it can serve up data to transaction engines. The type of disk you are using to persist your data also adds to performance capabilities. For example, you may chose to persist data on SSDs and be able to retrieve it quickly, if you are able to use HDFS you get the added benefits of parallel reads and writes.

If you haven't downloaded our current beta you can do so by visiting www.nuodb.com.

-Wiqar