<\/p>\n
In the first case, these additional features include:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Native access to Apache Cassandra, MongoDB and Elasticsearch (resolve queries without using Spark resources)<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Mixing data from different data sources<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Mixing data from batch and streaming with an SQL-like language<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Metadata discovery (importing all tables from a datastore using only one command)<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Logical views<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Persistent metadata catalog (no need to register all tables in every session)<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Creating tables in the datastores<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Data insertions.<\/p>\n
When using the P2P deployment, Crossdata offers:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 JDBC\/ODBC self-contained<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Flat view of subdocuments and arrays<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 High-availability<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Load balancing<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 User groups<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Apache Zeppelin interpreter<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Query builder<\/p>\n
In the near future, the Crossdata team will be implementing more features such as:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Global indexes (usage of inverted indexes).<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 API Rest.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Spark procedures from a SQL-like language<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Drop tables in datastores.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Usage of statistics for query planning optimization.<\/p>\n
Why compare?<\/h2>\n
One of the main goals of the comparison between Crossdata and Presto is to check their behaviour when launching derived TPC-DS queries, which allows us to check their performance in Big Data environments. Two persistence layers were used for the benchmark: Cassandra and HDFS+Parquet. Cassandra is a NoSQL database ideal for high-speed, online transactional data while the combination of HDFS+Parquet focuses on data warehousing and data lake use cases.\u00a0The benchmark covers these\u00a0different\u00a0scenarios, but both fall within the Big Data landscape.<\/p>\n
It is important to highlight that these tests work with a single-user scenario and that no secondary indexes of Cassandra were used. Currently, Crossdata takes advantage of Stratio\u2019s Cassandra Lucene Index in order to resolve the queries natively when possible.<\/p>\n
The queries used for this benchmark give some insight into how Crossdata and Presto work when large volumes of data are examined, queries of various operational requirements and complexities (e.g., ad-hoc, reporting, iterative OLAP, data mining) are executed, and high CPU and IO load are needed.<\/p>\n
Environment<\/h2>\n
As mentioned before, the benchmark was\u00a0executed in a controlled environment. The Crossdata team made use of 8 Huawei XH628 servers located in our European offices. The following hardware was used:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 2 Intel Xeon E5-2630V3 processors with 8 cores and 2\u00b44GHz.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 64 GB RAM DDR4.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 4 SATA disk with 1TB at 7\u00b45k.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 2 10GbE interfaces<\/p>\n
Before\u00a0the benchmark, some configurations were tested with Presto and Crossdata, adjusting their parameters for the best stability and throughput results.<\/p>\n
Both Presto and Spark had 32 GB available in the JVM per node, with one server acting as Master, and the other seven acting as workers.<\/p>\n
In the end,\u00a0this was the configuration used:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Presto<\/p>\n
\u25cb\u00a0\u00a0\u00a0\u00a0 112 cores in total (shared with Cassandra)<\/p>\n
\u25cb\u00a0\u00a0\u00a0\u00a0 134.4GB available for executing queries<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 Crossdata<\/p>\n
\u25cb\u00a0\u00a0\u00a0\u00a0 Spark Cluster (Standalone deployment)<\/p>\n
\u25a0\u00a0\u00a0\u00a0\u00a0 66 cores in Spark + 66 cores in Cassandra<\/p>\n
\u25a0\u00a0\u00a0\u00a0\u00a0 224GB available for executing queries<\/p>\n
The reason Presto has less available\u00a0memory than Spark, is because it automatically reserves 40% of the available JVM memory as heap for internal use in the cluster (7*32GB = 224 GB -> 224 GB * 0.6 = 134.4GB available for all queries executed in the cluster). The memory in Spark works differently\u00a0given that it doesn\u2019t reserve a part of the memory statically to manage the cluster resources or operations. It just reserves and frees the memory as it is requested by the cluster so that it is more elastic in the memory management.<\/p>\n
The TPC-DS dataset used had a size of 840GB and it was created with tools respecting the official metadata of the specifications and creating all the tables required by the standard.<\/p>\n
The subset consists of the following 21 queries: q7, q11, q13, q15, q19, q25, q26, q29, q31, q43, q48, q55, q59, q66, q74, q76, q78, q84, q85, q91 and q93. These 21 queries were chosen because they are supported grammatically by both frameworks and because they represent a heterogeneous subset of the TPC-DS queries. Thus, different aspects and capabilities of resolving different types of queries were tested.<\/p>\n
However, for the comparison with Cassandra, a different set of queries were used:<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 q84 from the derived TPC-DS set of queries mentioned above.<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 n1: select * from customer<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 n2: select * from customer where c_customer_sk = 9808094<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 n3: select * from store_sales limit 5000<\/p>\n
\u25cf\u00a0\u00a0\u00a0\u00a0 n4: select * from store_sales where ss_item_sk = 51097 and ss_ticket_number = 36448921<\/p>\n
Results<\/h2>\n
The first thing to be noticed is that Presto didn\u2019t resolve all queries because it threw\u00a0an OutOfMemoryException and, therefore, only some queries of the 21 initial queries were valid for the comparison. It\u2019s important to mention that different configuration parameters were tried in order to maximize the number of queries resolved by Presto and, finally, the configuration mentioned above was the most successful one.<\/p>\n
Only the following queries were used for the Benchmark with HDFS+Parquet: q15, q19, q31, q43, q55, q76, q78 and q84.<\/p>\n Only the\u00a0following queries were used for the Benchmark with Cassandra: n2 and n4.<\/p>\n Again, we have to keep in mind that this benchmark was performed in a single-user environment.<\/p>\n The following\u00a0graph represents the results with HDFS+Parquet with the aforementioned set of queries:<\/p>\n Due to the difference in resolution time of the different queries, the above graph has been created using\u00a0the Presto time for every query as the referent ratio (fixed to 1) versus the query resolution time in Crossdata. As shown, Crossdata resolves queries faster 5 out of 9 times\u00a0and on average, Crossdata obtains a global ratio that represents half of the one of Presto, approximately.<\/p>\n The above chart represents the total time of the 9 queries in both systems. Again, this figure shows that the accumulated time for resolving the queries in Presto is twice that of resolving the queries in Crossdata.<\/p>\n The\u00a0following graph represents the results with Cassandra with the aforementioned set of queries:<\/p>\n The above chart represents the resolution time of Presto and Crossdata with the 2 aforementioned queries on Cassandra. In this case, Crossdata executes these 2 queries natively, that is, Crossdata doesn\u2019t make use of the Spark cluster because the Crossdata planner identifies that both queries can be resolved using the direct access to Cassandra.<\/p>\n The first thing to highlight is that this benchmark doesn\u2019t take into account the queries that couldn\u2019t be resolved by Presto. In most cases, Presto threw an OutOfMemoryException, which is quite frustrating for the aggressive usage of the memory that Presto requires. On the other hand, Apache Spark behaves much more reliably given that, before having a problem with the memory space, it leverages the space in disk in a very efficient way. We admit that Presto might have been configured in a more effective way, but, even after spending days reading the documentation, we didn\u2019t find any better way to do it. This makes the tuning of Presto a very difficult task and, in many cases, requires very powerful environments with a large amount of resources, which contradicts the mantra in Big Data systems about using commodity hardware.<\/p>\n In addition, even when Presto is able to resolve the query, the resolution time is longer in comparison with Crossdata when data is stored in HDFS with Parquet format. If you look closely, Crossdata is a little slower than Presto when resolving low latency queries – by about a few milliseconds. However, when executing iterative OLAP queries, Presto takes much longer than Crossata in resolving the query, therefore, the penalty is about seconds with heavy load calculations.<\/p>\n By using Crossdata and Presto with Apache Cassandra, the results show that Crossdata, with the native access, and Apache Spark, with the push-downs of filters, make a better use of the datastore capabilities in order to have a better throughput.<\/p>\n Crossdata is therefore the more suitable option in most cases and is more reliable than Presto in all of the scenarios. Crossdata is faster for cases where native access is going to be used.<\/p>\n This post was written by Stratio’s Crossdata team: Miguel Angel Fernandez (@miguel_afd<\/a>),\u00a0Pablo Francisco Perez (@pfcoperez<\/a>),\u00a0Unai Sarasola,\u00a0David Arroyo, Juanjo Lopez (@Orcrsit<\/a>) and\u00a0Hugo Dominguez (@Huguito1906<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":" Nowadays, there are a lot of Big Data query engines available. Some companies struggle to choose which one to use. Benchmarks exist, but results can be contradictory and thus difficult to trust.<\/p>\n","protected":false},"author":1,"featured_media":997,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[686],"tags":[85],"ppma_author":[795],"yoast_head":"\n![\"Table\"](\"http:\/\/blog.stratio.com\/wp-content\/uploads\/2016\/11\/Table-1.png\")
<\/a><\/span><\/p>\n![\"Table2\"](\"http:\/\/blog.stratio.com\/wp-content\/uploads\/2016\/11\/Table2.png\")
<\/a><\/p>\n![\"1\"](\"http:\/\/blog.stratio.com\/wp-content\/uploads\/2016\/11\/1.png\")
<\/a><\/p>\n![\"2\"](\"http:\/\/blog.stratio.com\/wp-content\/uploads\/2016\/11\/2.png\")
<\/a><\/p>\n![\"Crossdata\"](\"http:\/\/blog.stratio.com\/wp-content\/uploads\/2016\/11\/Crossdata.jpg\")
<\/a><\/p>\nConclusions<\/h2>\n