Non-relational databases arise as a solution to solve the scalability problems of relational databases when dealing with big data applications. However, they are highly configurable prone to user decisions that can heavily affect their performance. In order to maximize the performance, different data models and queries should be analyzed to choose the best fit. This may involve a wide range of tests and may result in productivity issues. We present Aeneas, a tool to support the design of data management code for applications using non-relational databases. Aeneas provides an easy and fast methodology to support the decision about how to organize and retrieve data in order to improve the performance.Peer ReviewedPostprint (author’s final draft

Ayguadé Parra, Eduard

Becerra Fontal, Yolanda

Cugnasco, Cesare

Hernández, Roger

Torres Viñals, Jordi

English

AbstractNon-relational databases arise as a solution to solve the scalability problems of relational databases when dealing with big data applications. However, they are highly configurable prone to user decisions that can heavily affect their performance. In order to maximize the performance, different data models and queries should be analyzed to choose the best fit. This may involve a wide range of tests and may result in productivity issues. We present Aeneas, a tool to support the design of data management code for applications using non-relational databases. Aeneas provides an easy and fast methodology to support the decision about how to organize and retrieve data in order to improve the performance

Hernandez, Roger

Becerra, Yolanda

Torres, Jordi

Ayguadé, Eduard

Elsevier - Publisher Connector 

 Procedia Computer Science  18 ( 2013 )  2561 – 2564 
1877-0509 © 2013 The Authors. Published by Elsevier B.V.
Selection and peer review under responsibility of the organizers of the 2013 International Conference on Computational Science
doi: 10.1016/j.procs.2013.05.441 
International Conference on Computational Science, ICCS 2013
Aeneas: a tool to enable applications to eﬀectively use
non-relational databases
Cesare Cugnascoa,∗, Roger Hernandeza, Yolanda Becerraa,b, Jordi Torresa,b, Eduard
Ayguade´a,b
aBarcelona Supercomputing Center, C/ Jordi Girona 29, Barcelona 08034, Spain
bUniversitat Polite`cnica de Catalunya-Barcelona Tech, C/Jordi Girona 1, Barcelona 08034, Spain
Abstract
Non-relational databases arise as a solution to solve the scalability problems of relational databases when dealing with big
data applications. However, they are highly conﬁgurable prone to user decisions that can heavily aﬀect their performance. In
order to maximize the performance, diﬀerent data models and queries should be analyzed to choose the best ﬁt. This may
involve a wide range of tests and may result in productivity issues. We present Aeneas, a tool to support the design of data
management code for applications using non-relational databases. Aeneas provides an easy and fast methodology to support
the decision about how to organize and retrieve data in order to improve the performance.
Keywords: Non-relational database; distributed data-store; data model design; benchmarking; Apache Cassandra
1. Introduction
The overwhelming amount of data that is currently invading all social ﬁelds has made big data applications
become a hot topic in the research area [1]. One of the main challenges to face is how to store and organize all
information in order to oﬀer eﬃcient and reliable access to users, and to make it easy to share all information
among various users with diﬀerent interests and requirements, and many times, those requirements come together.
Non-relational databases arise as an alternative to traditional databases to deal with the challenges big data ap-
plications pose[2, 3, 4, 5]. Advances in this area, together with the improvements in cloud computing technologies
are opening new options in varied application ﬁelds to exploit the new power to store huge amounts of data.
However, the performance of non-relational databases is very sensitive to user decisions[6] as, for example,
data organization, type of query, and conﬁguration parameters such as data partitioning, number of replicas,
amount of memory allocated, etc. This means that, in order to get the best possible performance, the user should
test a lot of diﬀerent organizations and parameters. This requires the implementation of various versions of data
generator applications and data consumer ones, as this code depends on the data model, and a framework for
measuring their performances. Moreover, the behavior of each conﬁguration depends not only on the particular
cluster but also on the particular workload that is being tested. Thus, the experimentation has to be repeated each
time that the amount of involved data stored or the target data for a query changes.
∗Corresponding author. Tel.: +34 934011650 ; fax: +34 934137721.
E-mail address: cesare.cugnasco@bsc.es.
Available online at www.sciencedirect.com
Open access under CC BY-NC-ND license.
2562   Cesare Cugnasco et al. /  Procedia Computer Science  18 ( 2013 )  2561 – 2564 
In this paper we present Aeneas1, a highly conﬁgurable tool to support the design of data management code
for applications using non-relational databases. The user can conﬁgure this tool by providing the data model, the
query parameters, and the performance metrics that he wants to evaluate. Then, Aeneas automatically generates
the code to deﬁne the speciﬁed data model, to insert and to retrieve the data, and to evaluate the performance
of accessing these data. Thus, Aeneas provides an easy and fast methodology to support the decision on how
to organize and retrieve data with good performance, whilst solving the productivity limitations that could arise
when using non-relational databases.
The rest of the paper is organized as follows: section 2 describes the database used by the current implementa-
tion of Aeneas and section 3 presents the design of the tool and the main aspects of its implementation; section 4
describes a case study based on an application from the life sciences domain and section 5 shows the conclusions.
2. Background
Apache Cassandra[3] is a distributed database management initially developed by Facebook for internal usage,
and later released as an open source project. It inherits the data model structure from Google BigTable[2] and the
data replication and distribution management from Amazon’s Dynamo[4]. We have chosen this database because
it is highly conﬁgurable, making it possible to adapt it to the requirements of existing applications.
Data is organized in column family objects, which are similar to tables in the relational database model, and
each column family contains a set of columns, which are comparable to attributes. A set of related columns
compose a row, which is identiﬁed by a key. The row key is the main resource used to locate the data, and it is
also used to distribute the data across the cluster nodes.
Cassandra does not support relationships between column families, such as foreign keys and join operations.
Knowing this, the best practice when designing a data model is to keep related data in the same column family,
duplicating the data if required.
The architecture of Cassandra is completely decentralized. All the nodes in a Cassandra cluster are equivalent:
they all can receive read/write requests and are able to forward in parallel those requests to the hosting nodes.
3. Aeneas
The main goal of Aeneas is to oﬀer a methodology to increase the productivity of the evaluation process,
which will lead the user to get the best conﬁguration parameters to access data. In this section, ﬁrstly we describe
the main steps involved in the evaluation of each of these conﬁgurations and how to develop them without using
Aeneas. Secondly, we describe the main aspects of the Aeneas design and implementation.
3.1. Evaluation Methodology without using Aeneas
Let us consider that we have diﬀerent data models and diﬀerent parameters to test. Then the main steps
involved in the evaluation are the following.
Conﬁgure the cluster according to the parameters: In terms of database conﬁguration, in a regular environment
the user would be required to conﬁgure all of the cluster and database parameters such as replication factors and
strategies, cache conﬁgurations, partitioning strategies, etc. Moreover, it is necessary to specify how the data is
going to be organized in the database. To this end, the user should use the proper interface function and should
specify all the organization characteristics.
Load all the data according to the data model to test: In order to populate the database the user should write
the speciﬁc code to insert the data according to each model.
Generate queries workload: Once again, the code to query the database depends on the data model conﬁg-
uration. This means that for each conﬁguration to test, the user should implement a version of the query code
to access the database. In addition, in order to evaluate the concurrent access of several clients, the user should
provide an extra code to control the execution of all the applications instances.
1Aeneas was one of the Cassandra relative’s that, after Cassandra prophecy was intended to be Rome founder
2563 Cesare Cugnasco et al. /  Procedia Computer Science  18 ( 2013 )  2561 – 2564 
Collect statistics about the database system behavior: Up to this point everything has been prepared, but it is
necessary to deﬁne the metrics and to implement the tools to collect statistics about the performance of the system.
Summarizing, all the actions mentioned above would have to be brought into consideration, executed and
repeated for every experiment that has to be tested, and it should be made within the environment of the original
application. Aeneas implements an evaluation environment that provides the user with an easy way to describe
diﬀerent data models, to specify diﬀerent performance metrics and to perform and evaluate diﬀerent data queries.
3.2. Aeneas design and implementation
Aeneas is composed by three main modules: Loader, Workloader and Analysis reporter. Thus, each user
can use just the module that he needs to support his requirements. Moreover, as it is based on interfaces, any
speciﬁc case study could be implemented by just extending those patterns and implementing the required services.
Even when adding those new capabilities, the user interface and the module integration will not change. In
addition to this, the abstraction layer can greatly improve the performance of data loading stage by managing and
optimizing the insertion operations.The current implementation of Aeneas only supports the Apache Cassandra
database. However, notice that the modularity of Aeneas makes it easy to add diﬀerent modules to support diﬀerent
databases. Figure 1 represents the main steps in the evaluation process and the main components of Aeneas.
Fig. 1. Steps in the evaluation of a data model using Aeneas
The Loader is in charge of the conﬁguration of the system and the loading of the input data. The main
complexity involved in this task is to obtain a code independent of any data sources and of any possible data
models. To achieve this, we have decoupled the deﬁnition of the data structure from the implementation of the
access code. On one side, the user describes the structure of the data to be read, deﬁning a grammar through a meta
language. On the other side, we have deﬁned a generic interface that allows to implement a speciﬁc reader for
diﬀerent data sources. Each loader uses the grammar to read information and to store it using the proper structure.
Then, Aeneas reorganizes and transforms the read data in order to ﬁt them into a speciﬁc model.
The Workloader performs a set of queries following diﬀerent statistical distributions. The input for this module
is the following: which of the implementations is to be tested, the number of tests to perform on it and the type of
distribution used to generate the query input arguments.
The Analysis reporter retrieves metrics from both the client and the database sides, considering all the nodes
in the cluster, and stores them in a consistent data store. By default, Aeneas gathers the most typical metrics such
as the time required to populate the cluster, the statistical behavior of a query response time, memory usage, I/O
and network frequency, and additional internal metrics from Cassandra as, for example, the amount of pending
tasks per node but it is easily possible to add new metrics.
4. Case study
Life science applications constitute one of the ﬁelds that can beneﬁt from using non-relational databases. A
usual scenario in this domain is to have a long process generating a huge amount of information that can feed
other applications. Some of these analysis may be required long after the data generation, with diﬀerent purposes
and using diﬀerent subsets of the generated data. Thus, it is convenient to keep this data stored as long as possible,
to avoid wasting time to generate it again. In fact, life science researchers aim to have shared pools with such
information (RSCB protein data bank[7] and the molecular dynamic extended library[8] are two examples of this
kind of eﬀort). In this domain, our case study is focused on applications working on molecular dynamics, which
is a technique based on computer simulation that represents the evolution in time of complex systems, modeled at
2564   Cesare Cugnasco et al. /  Procedia Computer Science  18 ( 2013 )  2561 – 2564 
atom level [9]. The output of the simulation is the trajectory of a molecule, that is, the coordinates of each atom
in time. An application analyzing these trajectories may need information about all the atoms during a particular
range of time; or it may need information about a subset of atoms throughout the whole simulation.
Given these types of queries, we can consider two diﬀerent data models: in the ﬁrst one, each row represents
the coordinates that a given atom has in each snapshot of the trajectory, and the row key is an atom identiﬁer; in
the second one, each row represents the coordinates of all the atoms in a given snapshot of the trajectory, and the
row key is the snapshot identiﬁer. In a generic dataset, the number of atoms is several order of magnitude smaller
than the number of samples. This produces data models which mainly grow on one dimension. Since Cassandra
distributes the data along the cluster nodes basing on the key value, and persist the data ordering by rows, there is
a general trade-oﬀ between parallelism and eﬃcient I/O devices usage.
We have used Aeneas to perform hundreds of experiments in order to get the best conﬁguration to request
the data for one trajectory. To do this, we only needed to adapt the conﬁguration ﬁles according to each test.
For example, one set of experiments has been devoted to deciding how to split a query, which is necessary to ﬁt
each sub-query results to the amount of memory available. We have analyzed how changing the amount of rows
requested per each sub-query, and consequentially the number of sub-queries performed, may aﬀect the response
time of the accesses. We have observed that the performance of the accesses increases as the number of sub-
queries decreases until reaching an inﬂection point. This inﬂection point depends on several factors: the amount
of rows involved per sub-query, the amount of data requested per sub-query, the resources available in the cluster
and the amount of nodes in the cluster. Thus, given a cluster conﬁguration, in order to get the best performance it is
necessary to use a query organization and a data model that allows to get a parallelism degree and a memory usage
close to the values that characterize the inﬂection point. We have found that depending on the query organization
it is possible to improve the performance of one of the queries by 13 times.
5. Conclusions and Future work
We have presented Aeneas, a tool which implements an analysis environment that provides the user with
an easy way to describe diﬀerent data models, to identify diﬀerent metrics and to execute and evaluate various
queries. Its usage dramatically increases the productivity when designing and tuning a non-relational database.
As part of our future work, we plan to add new features to Aeneas, such as support for automatic generation
for a wider range of query types. Additionally, we plan to provide Aeneas with a model that is able to suggest
query plans to maximize the memory usage while reducing node congestion.
Acknowledgements
This work is partially supported by the BSC-CNS Severo Ochoa program and the TIN2012-34557 project, with
funding from the Spanish Ministry of Economy and Competitivity and the European Union’s FEDER founds.
References
[1] R. Kouzes, G. Anderson, S. Elbert, I. Gorton, D. Gracio, The changing paradigm of data-intensive computing, Computer 42 (1) (2009) 26
–34.
[2] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, R. E. Gruber, Bigtable: A distributed
storage system for structured data, ACM Trans. Comput. Syst. 26 (2) (2008) 4:1–4:26.
[3] A. Lakshman, P. Malik, Cassandra: a decentralized structured storage system, SIGOPS Oper. Syst. Rev. 44 (2) (2010) 35–40.
[4] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall, W. Vogels, Dynamo:
amazon’s highly available key-value store, SIGOPS Oper. Syst. Rev. 41 (6) (2007) 205–220.
[5] L. George, HBase: The Deﬁnitive Guide, Deﬁnitive Guide Series, O’Reilly Media, 2011.
[6] E. Hewitt, Cassandra: the deﬁnitive guide, Deﬁnitive Guide Series, O’Reilly Media, 2011.
[7] Rcsb protein data bank.
URL http://www.rcsb.org/pdb/home/home.do
[8] Model: molecular dynamics extended library.
URL http://mmb.pcb.ub.es/MoDEL/
[9] R. Petrenko, J. Meller, Molecular Dynamics, John Wiley Sons, Ltd, 2010.


Aeneas: A Tool to Enable Applications to Effectively Use Non-relational Databases 

Non-relational databases arise as a solution to solve the scalability problems of relational databases when dealing with big data applications. However, they are highly configurable prone to user decisions that can heavily affect their performance. In order to maximize the performance, different data models and queries should be analyzed to choose the best fit. This may involve a wide range of tests and may result in productivity issues. We present Aeneas, a tool to support the design of data management code for applications using non-relational databases. Aeneas provides an easy and fast methodology to support the decision about how to organize and retrieve data in order to improve the performance.Peer Reviewe

UPCommons

Aeneas: A tool to enable applications to effectively use non-relational databases

UPCommons. Portal del coneixement obert de la UPC

Aeneas: a tool to enable applications to effectivelyuse non-relational databasesCesare Cugnasco, Roger HernandezBarcelona Supercomputing CenterBarcelona, SpainEmail:{cesare.cugnasco, roger.hernandez}@bsc.esYolanda Becerra, Jordi Torres, Eduard Ayguade´Universitat Polite`cnica de Catalunya - Barcelona Tech.Barcelona supercomputing CenterBarcelona, Spain{yolandab, torres, eduard}@ac.upc.eduAbstract—Non-relational databases arise as a solution to solvethe scalability problems of relational databases when dealingwith big data applications. However, they are highly configurableprone to user decisions that can heavily affect their performance.In order to maximize the performance, different data modelsand queries should be analyzed to choose the best fit. This mayinvolve a wide range of tests and may result in productivityissues. We present Aeneas, a tool to support the design of datamanagement code for applications using non-relational databases.Aeneas provides an easy and fast methodology to support thedecision about how to organize and retrieve data in order toimprove the performance.Keywords—Non-relational database; distributed data-store; datamodel design; benchmarking; Apache CassandraI. INTRODUCTIONThe overwhelming amount of data that is currently invadingall social fields has made big data applications become a hottopic in the research area [1]. One of the main challenges toface is how to store and organize all information in order tooffer efficient and reliable access to users, and to make it easyto share all information among various users with differentinterests and requirements, and many times, those requirementscome together.Non-relational databases arise as an alternative to tradi-tional databases to deal with the challenges big data appli-cations pose[2], [3], [4], [5]. Advances in this area, togetherwith the improvements in cloud computing technologies areopening new options in varied application fields to exploit thenew power to store huge amounts of data.However, the performance of non-relational databases isvery sensitive to user decisions[6] as, for example, data organi-zation, type of query, and configuration parameters such as datapartitioning, number of replicas, amount of memory allocated,etc. This means that, in order to get the best possible per-formance, the user should test a lot of different organizationsand parameters. This requires the implementation of variousversions of data generator applications and data consumerones, as this code depends on the data model, and a frameworkfor measuring their performances. Moreover, the behavior ofeach configuration depends not only on the particular clusterbut also on the particular workload that is being tested. Thus,the experimentation has to be repeated each time that theamount of involved data stored or the target data for a querychanges.In this paper we present Aeneas1, a highly configurable toolto support the design of data management code for applicationsusing non-relational databases. The user can configure this toolby providing the data model, the query parameters, and theperformance metrics that he wants to evaluate. Then, Aeneasautomatically generates the code to define the specified datamodel, to insert and to retrieve the data, and to evaluate theperformance of accessing these data. Thus, Aeneas providesan easy and fast methodology to support the decision on howto organize and retrieve data with good performance, whilstsolving the productivity limitations that could arise when usingnon-relational databases.The rest of the paper is organized as follows: section IIdescribes the database used by the current implementation ofAeneas and section III presents the design of the tool and themain aspects of its implementation; section IV describes a casestudy based on an application from the life sciences domainand section V shows the conclusions.II. BACKGROUNDApache Cassandra[3] is a distributed database managementinitially developed by Facebook for internal usage, and laterreleased as an open source project. It inherits the data modelstructure from Google BigTable[2] and the data replicationand distribution management from Amazon’s Dynamo[4]. Wehave chosen this database because it is highly configurable,making it possible to adapt it to the requirements of existingapplications.Data is organized in column family objects, which aresimilar to tables in the relational database model, and eachcolumn family contains a set of columns, which are comparableto attributes. A set of related columns compose a row, whichis identified by a key. The row key is the main resource usedto locate the data, and it is also used to distribute the dataacross the cluster nodes.Cassandra does not support relationships between columnfamilies, such as foreign keys and join operations. Knowingthis, the best practice when designing a data model is to keeprelated data in the same column family, duplicating the data ifrequired.The architecture of Cassandra is completely decentralized.All the nodes in a Cassandra cluster are equivalent: they all can1Aeneas was one of the Cassandra relative’s that, after Cassandra prophecywas intended to be Rome founderreceive read/write requests and are able to forward in parallelthose requests to the hosting nodes.III. AENEASThe main goal of Aeneas is to offer a methodology toincrease the productivity of the evaluation process, which willlead the user to get the best configuration parameters to accessdata. In this section, firstly we describe the main steps involvedin the evaluation of each of these configurations and how todevelop them without using Aeneas. Secondly, we describe themain aspects of the Aeneas design and implementation.A. Evaluation Methodology without using AeneasLet us consider that we have different data models anddifferent parameters to test. Then the main steps involved inthe evaluation are the following.Configure the cluster according to the parameters: In termsof database configuration, in a regular environment the userwould be required to configure all of the cluster and databaseparameters such as replication factors and strategies, cacheconfigurations, partitioning strategies, etc. Moreover, it is nec-essary to specify how the data is going to be organized in thedatabase. To this end, the user should use the proper interfacefunction and should specify all the organization characteristics.Load all the data according to the data model to test: Inorder to populate the database the user should write the specificcode to insert the data according to each model.Generate queries workload: Once again, the code to querythe database depends on the data model configuration. Thismeans that for each configuration to test, the user shouldimplement a version of the query code to access the database.In addition, in order to evaluate the concurrent access of severalclients, the user should provide an extra code to control theexecution of all the applications instances.Collect statistics about the database system behavior: Upto this point everything has been prepared, but it is necessaryto define the metrics and to implement the tools to collectstatistics about the performance of the system.Summarizing, all the actions mentioned above would haveto be brought into consideration, executed and repeated forevery experiment that has to be tested, and it should be madewithin the environment of the original application. Aeneasimplements an evaluation environment that provides the userwith an easy way to describe different data models, to specifydifferent performance metrics and to perform and evaluatedifferent data queries.B. Aeneas design and implementationAeneas is composed by three main modules: Loader,Workloader and Analysis reporter. Thus, each user can usejust the module that he needs to support his requirements.Moreover, as it is based on interfaces, any specific case studycould be implemented by just extending those patterns andimplementing the required services. Even when adding thosenew capabilities, the user interface and the module integrationwill not change. In addition to this, the abstraction layer cangreatly improve the performance of data loading stage bymanaging and optimizing the insertion operations.The currentimplementation of Aeneas only supports the Apache Cassandradatabase. However, notice that the modularity of Aeneas makesit easy to add different modules to support different databases.Figure 1 represents the main steps in the evaluation processand the main components of Aeneas.Fig. 1. Steps in the evaluation of a data model using AeneasThe Loader is in charge of the configuration of the systemand the loading of the input data. The main complexityinvolved in this task is to obtain a code independent of anydata sources and of any possible data models. To achievethis, we have decoupled the definition of the data structurefrom the implementation of the access code. On one side, theuser describes the structure of the data to be read, defininga grammar through a meta language. On the other side, wehave defined a generic interface that allows to implement aspecific reader for different data sources. Each loader uses thegrammar to read information and to store it using the properstructure. Then, Aeneas reorganizes and transforms the readdata in order to fit them into a specific model.The Workloader performs a set of queries following dif-ferent statistical distributions. The input for this module is thefollowing: which of the implementations is to be tested, thenumber of tests to perform on it and the type of distributionused to generate the query input arguments.The Analysis reporter retrieves metrics from both the clientand the database sides, considering all the nodes in the cluster,and stores them in a consistent data store. By default, Aeneasgathers the most typical metrics such as the time requiredto populate the cluster, the statistical behavior of a queryresponse time, memory usage, I/O and network frequency, andadditional internal metrics from Cassandra as, for example, theamount of pending tasks per node but it is easily possible toadd new metrics.IV. CASE STUDYLife science applications constitute one of the fields thatcan benefit from using non-relational databases. A usual sce-nario in this domain is to have a long process generating ahuge amount of information that can feed other applications.Some of these analysis may be required long after the datageneration, with different purposes and using different subsetsof the generated data. Thus, it is convenient to keep this datastored as long as possible, to avoid wasting time to generateit again. In fact, life science researchers aim to have sharedpools with such information (RSCB protein data bank[7] andthe molecular dynamic extended library[8] are two examples ofthis kind of effort). In this domain, our case study is focusedon applications working on molecular dynamics, which is atechnique based on computer simulation that represents theevolution in time of complex systems, modeled at atom level[9]. The output of the simulation is the trajectory of a molecule,that is, the coordinates of each atom in time. An applicationanalyzing these trajectories may need information about allthe atoms during a particular range of time; or it may needinformation about a subset of atoms throughout the wholesimulation.Given these types of queries, we can consider two differentdata models: in the first one, each row represents the coordi-nates that a given atom has in each snapshot of the trajectory,and the row key is an atom identifier; in the second one, eachrow represents the coordinates of all the atoms in a givensnapshot of the trajectory, and the row key is the snapshotidentifier. In a generic dataset, the number of atoms is severalorder of magnitude smaller than the number of samples. Thisproduces data models which mainly grow on one dimension.Since Cassandra distributes the data along the cluster nodesbasing on the key value, and persist the data ordering by rows,there is a general trade-off between parallelism and efficientI/O devices usage.We have used Aeneas to perform hundreds of experimentsin order to get the best configuration to request the datafor one trajectory. To do this, we only needed to adapt theconfiguration files according to each test. For example, oneset of experiments has been devoted to deciding how to splita query, which is necessary to fit each sub-query results tothe amount of memory available. We have analyzed howchanging the amount of rows requested per each sub-query,and consequentially the number of sub-queries performed, mayaffect the response time of the accesses. We have observed thatthe performance of the accesses increases as the number ofsub-queries decreases until reaching an inflection point. Thisinflection point depends on several factors: the amount of rowsinvolved per sub-query, the amount of data requested per sub-query, the resources available in the cluster and the amountof nodes in the cluster. Thus, given a cluster configuration,in order to get the best performance it is necessary to usea query organization and a data model that allows to get aparallelism degree and a memory usage close to the valuesthat characterize the inflection point. We have found thatdepending on the query organization it is possible to improvethe performance of one of the queries by 13 times.V. CONCLUSIONS AND FUTURE WORKWe have presented Aeneas, a tool which implements ananalysis environment that provides the user with an easy way todescribe different data models, to identify different metrics andto execute and evaluate various queries. Its usage dramaticallyincreases the productivity when designing and tuning a non-relational database.As part of our future work, we plan to add new features toAeneas, such as support for automatic generation for a widerrange of query types. Additionally, we plan to provide Aeneaswith a model that is able to suggest query plans to maximizethe memory usage while reducing node congestion.ACKNOWLEDGEMENTSThis work is partially supported by the BSC-CNS Severo Ochoaprogram and the TIN2012-34557 project, with funding from theSpanish Ministry of Economy and Competitivity and the EuropeanUnion’s FEDER founds.REFERENCES[1] R. Kouzes, G. Anderson, S. Elbert, I. Gorton, and D. Gracio, “Thechanging paradigm of data-intensive computing,” Computer, vol. 42,no. 1, pp. 26 –34, jan. 2009.[2] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Bur-rows, T. Chandra, A. Fikes, and R. E. Gruber, “Bigtable: A distributedstorage system for structured data,” ACM Trans. Comput. Syst., vol. 26,no. 2, pp. 4:1–4:26, Jun. 2008.[3] A. Lakshman and P. Malik, “Cassandra: a decentralized structuredstorage system,” SIGOPS Oper. Syst. Rev., vol. 44, no. 2, pp. 35–40,Apr. 2010.[4] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman,A. Pilchin, S. Sivasubramanian, P. Vosshall, and W. Vogels, “Dynamo:amazon’s highly available key-value store,” SIGOPS Oper. Syst. Rev.,vol. 41, no. 6, pp. 205–220, Oct. 2007.[5] L. George, HBase: The Definitive Guide, ser. Definitive Guide Series.O’Reilly Media, 2011.[6] E. Hewitt, Cassandra: the definitive guide, ser. Definitive Guide Series.O’Reilly Media, 2011.[7] “Rcsb protein data bank.” [Online]. Available:http://www.rcsb.org/pdb/home/home.do[8] “Model: molecular dynamics extended library.” [Online]. Available:http://mmb.pcb.ub.es/MoDEL/[9] R. Petrenko and J. Meller, Molecular Dynamics. John Wiley Sons,Ltd, 2010.

file:///data/remote/core/dit/data/elsevier/pdf/56d/aHR0cDovL2FwaS5lbHNldmllci5jb20vY29udGVudC9hcnRpY2xlL3BpaS9zMTg3NzA1MDkxMzAwNTg0eA==.pdf

Aeneas: A tool to enable applications to effectively use non-relational databases

Abstract

Similar works

Full text

Available Versions

Elsevier - Publisher Connector

UPCommons

Elsevier - Publisher Connector

UPCommons. Portal del coneixement obert de la UPC