Faster than we expected. Easier than we thought.
Executive Summary
For a single node cluster we found that the Eon mode performed significantly better for large single user queries and marginally better for updates, inserts & loads. Best times per suite of test runs is highlighted in bold below. Full 360 is a Vertica partner going back several years. We recently took the opportunity to test the new Eon mode of Vertica 9 during it’s beta. Here is what we found:
Technical Overview
Eon mode enables you to combine flexibility/elasticity of AWS and fast query processing of Vertica. Vertica has a new underlying architecture that separates the computational processes from the storage layer of your database. Storage layer supports use of AWS S3 for now, however Vertica may support other cloud storage types in the future. Data is stored persistently on S3 instead of a fixed capacity attached to each node. The separation of storage layer is very powerful, since it allows adding new nodes for added computational power and performance without compromising the resiliency. This is well suited for varying loads and makes it possible to save costs. New nodes can be added and downed nodes can be recovered easily since nodes can be quickly rebalanced without massive I/O operations due to Eon’s centralized storage. Vertica does not provide technical support for Eon Mode Beta, so it’s recommended for non-production loads only. We tested it as such.
Eon mode supports segmented, replicated, and aggregate projections. Projection definitions, using projections, and the process of creating and optimizing projections is similar to Enterprise mode. Every table must have at least one super projection. There are no buddy projections in Eon mode and that avoids the performance hit to the queries when a node goes down, since query plan remains unchanged. Segmented projections are split into shards. The number of shards is not directly linked to the number of nodes in the cluster and is configured while creating Eon mode database. For example if the database is configured with K-safety of 1, at the minimum there will be two nodes subscribed to a segment shard and all nodes will subscribe to the replica shard. A set of nodes and shard subscriptions are automatically assigned by Vertica to every connection and also managed automatically in the event of a assigned downed node. This assignment and management of subscriptions is transparent and doesn’t need any action taken by the user. Recovery of downed node is relatively simpler in Eon mode, since there is no replay of catalog events, recovery of historical data, or replay of deletes.
Test Details
We wanted to benchmark the performance of Vertica in Eon mode to the enterprise mode. For this we spun a single node Vertica clusters in Eon mode (9.x) and another one in enterprise mode (8.x). We used jmeter for the performance testing for single user and 5 users select/update queries simulations and data load performance. We provisioned enough storage to the node to accommodate all the data for this exercise in the depot (optional and may not be feasible always) to avoid queries hitting communal storage (AWS S3) and skewing the benchmarks.
We created two test suites: Star Schema Crosstabs (Eon = 19.58% faster) Updates & Inserts (Eon = 7.75% faster)
In the first suite of tests, we built a five dimensional star schema with no key optimizations. We felt that this would be a good test of the internals of Vertica basic functionality which is most likely to be what DBAs new to the technology would first encounter. We also did not design the queries other than to allow a third party BI tool to make its own queries. We simply identified joins between fact and dimension tables in a star. We used Tibco Jaspersoft to identify the joins and used its native visual interface to build crosstab queries. The standard JDBC driver provided with Vertica was used for all queries.
Our test suites were executed by Apache JMeter. In preliminary testing we found that query response that simulated 5 concurrent user threads provided consistently linear results. With that established we opted to use a wider variety of queries rather than to test the user scalability of a smaller set. Our experience tells us that multiple database nodes work excellently in this regard.
All tests were run against a single node EC2 instance with the following configuration: Instance Type: m4.xlarge EBS Type: 1000GB gp2 3000 iops
Summary
We were surprised and very pleased with the results we were able to get from this vanilla implementation. Our testing demonstrated Vertica’s characteristic linearity of performance in scaling user requests, and we expect the same from scaling of nodes. The reliability of Vertica has always been good, but with S3 centralization and shared data, its elasticity and high availability are significantly improved. We are impressed by the speed at which the Vertica team has added new features and functionality to Vertica. It is truly an impressive technology now made even more convenient for developers and administrators, and faster for end users.
For detailed results or further information about our Vertica practice, contact us at info@full360.com
