What do you like best about IBM Netezza Performance Server?
The raw speed of the system allows for a development process not typically undertaken. For example, it's possible to run full performance testing as you unit test. You can also create tables that are much larger than you would make in a typical database (eg storing current and archive rows in the same tables).
The simplicity of the system allows for minimal maintenance. DBA involvement can be next to zero. Review collected by and hosted on G2.com.
What do you dislike about IBM Netezza Performance Server?
The simplicity of the system can also cause issues in mixed use cases.
In other databases, you also have the ability to improve performance by multiple means, such as partitioning, indexing, allocating server hardware, etc. Netezza essentially has only two ways--as far as physical architecture goes--to handle performance: sorting data and distributing data.
Sorting data is done directly in the table, avoiding the need for clustered indexes. But that's only helpful if the query you run utilizes that sort. For instance, if you sort on date by making the Date field the ORGANIZE BY key, any query that doesn't utilize Date in the WHERE clause will have to tablescan. You can create materialized views that essentially act like indexes, but you can't use both MVs and ORGANIZE BY keys. In other words, if you use even one MV to sort, you can't force-sort the data in the table unless you actually reload the data with an ORDER BY clause in the INSERT statement. The problem with the MVs is that even though they act like an index, you have to refresh them like a typical MV in order to sort any new data. In a system that is loaded or updated intraday, that can cause problems.
Distribution has two components that can sometimes be at odds with each other: evenly hashing the data to share workload and colocating data for joins. But if the column that makes sense to distribute on for colocation purposes doesn't evenly distribute the data, you will be forced to make a compromise on one for the sake of the other.
Furthermore, in a star schema, you can colocate the fact table's foreign key with a dimension's primary key, but that is best used if you query with a parameter on that dimension in the WHERE clause. If you run a query that can't filter on that dimension, the distribution key might not help you. Also, you can only ever pick one dimension to colocate with the fact. Choosing a multi-column distribution of the fact based on multiple dimension keys does not colocate the fact with _each_ dimension. It instead distributes the fact with a hash key based on the concatenated combination of the values of the multi-column distribution key (ie the fact will not be colocated with _any_ dimension).
Also, the fact that Netezza has not come out with in-memory or columnar options makes me wonder if the architecture of the appliance even allows for such possibilities. In other words, the lack of flexibility might be cropping up again if the nature of the appliance doesn't allow for such varied functionality. Review collected by and hosted on G2.com.
