Denna studie har undersökt vilken av CouchDB och MongoDB som har lägst svarstider vid hantering av filformaten epub, mobi, txt och html. De operationer som har undersökts är insert, update, select och delete för att se vilken av databaserna som presterar kortast svarstid. Resultatet av undersökningen är att databaserna är bra på olika saker där CouchDB presterade bättre vid inmatning av epub, txt och html-formaten samt vid uppdatering och borttagning av alla format. MongoDB presterade däremot bättre vid hämtning av alla filformaten vilket gör att databaserna är bra i olika situationer beroende på vad databasen ska användas till. Om databasen kommer att utföra många select-operationer passar MongoDB bäst medans vid borttagning och uppdatering passar CouchDB bäst. Vid inmatning beror det på vilket filformat som kommer hanteras mest då databaserna presterade liknande resultat för mobi-formatet medans CouchDB presterade bättre vid de andra formaten.

Dissertação (mestrado)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2016. / Submitted by Albânia Cézar de Melo (albania@bce.unb.br) on 2017-02-15T12:23:44Z No. of bitstreams: 1 2016_JaneAdrianaSouza.pdf: 1805634 bytes, checksum: be4f8c819c44b36ff04c685db1485101 (MD5) / Approved for entry into archive by Raquel Viana(raquelviana@bce.unb.br) on 2017-03-17T17:00:26Z (GMT) No. of bitstreams: 1 2016_JaneAdrianaSouza.pdf: 1805634 bytes, checksum: be4f8c819c44b36ff04c685db1485101 (MD5) / Made available in DSpace on 2017-03-17T17:00:26Z (GMT). No. of bitstreams: 1 2016_JaneAdrianaSouza.pdf: 1805634 bytes, checksum: be4f8c819c44b36ff04c685db1485101 (MD5) / Nos últimos anos, novos modelos de banco de dados, chamados NoSQL (Not Only SQL) estão sendo considerados alternativas para a gestão de grandes volumes de dados - Big Data, pois gerenciam e armazenam os dados de forma eficiente, possuem alta escalabilidade, disponibilidade e desempenho satisfatório. A administração de bancos de dados implica na execução de tarefas, tais como criação de bases e objetos, atribuição de privilégios, realização de backups, dentre outras atividades. A execução dessas tarefas de administração em bancos de dados NoSQL exige um maior nível de conhecimento por parte dos administradores de bancos de dados (DBA), e expõe questões relacionadas à falta de familiaridade desses profissionais nos ambientes NoSQL. De forma a contribuir nesse campo de estudo, a presente dissertação apresenta a solução NoSQL2 para execução de tarefas de administração, usando a linguagem SQL (Structured Query Language), que funciona em diferentes Sistemas Gerenciadores de Bancos de Dados (SGBD) NoSQL. O NoSQL2 permite aos DBAs se desvincularem das particularidades de formas de acesso de cada NoSQL, pois disponibiliza recursos para conversão de comandos da sintaxe SQL para a sintaxe proprietária do banco de dados NoSQL. / New database models, called NoSQL (Not Only SQL) are considered appropriate alternatives for managing and storing Big Data due to their efficiency, high scalability, availability and performance. Database administration effects tasks such as creating databases and objects, attributing priorities and performing backups. The execution of these tasks, in NoSQL databases, require that DBA (database administrators) have a high level of knowledge, and often exposes problems with the DBA unfamiliarity of the NoSQL environments. In order to contribute to the scholarship in this field, this paper presents the middleware NoSQL2 to perform management tasks using the SQL language, which runs on different NoSQL databases. The NoSQL2 allows DBA to disassociate themselves from the particularities of access forms of each NoSQL, since provides resources for converting SQL commands to the proprietary NoSQL database syntax.

Submitted by CLAUDINES TAVEIRA TORRES null (torres.analista@hotmail.com) on 2017-05-22T18:05:43Z No. of bitstreams: 1 Torres CT- Dissertação 22-05-2017.pdf: 4034477 bytes, checksum: a562e11dc260722bc79d609df65cc0c2 (MD5) / Approved for entry into archive by Luiz Galeffi (luizgaleffi@gmail.com) on 2017-05-23T17:39:02Z (GMT) No. of bitstreams: 1 torres_ct_me_bauru.pdf: 4034477 bytes, checksum: a562e11dc260722bc79d609df65cc0c2 (MD5) / Made available in DSpace on 2017-05-23T17:39:02Z (GMT). No. of bitstreams: 1 torres_ct_me_bauru.pdf: 4034477 bytes, checksum: a562e11dc260722bc79d609df65cc0c2 (MD5) Previous issue date: 2017-03-30 / As inovações tecnológicas, a popularização exponencial da Internet aliado ao aumento no uso dos Smartphones e acesso à Web, vêm alterando a forma como vivemos e nos comunicamos, destacando-se a interatividade, redes sociais, celulares inteligentes, aplicativos móveis, Internet das Coisas, comunicação M2M, computação sobre as nuvens entre outros, aliado a isso a empolgação do mercado quanto a utilização do IoT é mencionada em 2015 pelo Ciclo Gardner Hype como a tecnologia no ápice da crista da onda para os próximos 5 a 10 anos. O presente trabalho teve como objetivo criar um facilitador para os visitantes do museu através de desenvolvimento de um protótipo App de dispositivo móvel utilizando tecnologia Beacons e QRCode para acesso as informações dos objetos do museu dos ferroviários. A importância desta pesquisa está alicerçada na estimação que representa a estrada de ferro no mundo e principalmente em nossa região. A necessidade de preservar a cultura e difundir a memória da história é encontrada no museu ferroviário de Bauru e neste cenário foi desenvolvido uma pesquisa e de um protótipo de App utilizando as tecnologias Android, sensores Beacons (IoT), QRCode, Internet, Bluetooh e dispositivos móveis (Smartphones, Tablet) para tornar mais atraente e interessante aos seus visitantes. A realização do protótipo de App e as tecnologias mencionadas acima trouxeram aos visitantes um novo cenário, unindo-se o mundo real e o virtual, melhorando substancialmente a sua experiência no museu e fazendo com que os visitantes retornem futuramente ao museu e tragam outros visitantes. / Technological innovations, the Internet exponential popularization, the increase use of smartphones and the web access have changed the way we live and communicate, with special emphasis on interactivity, social networks, smart phones, mobile applications, Internet of things, M2M communication, cloud computing among others. The market expectation in relation to the use of IoT - Internet of Things is mentioned in 2015 by the Gardener Hype Cycle and the technology is on the crest of a wave for the next 5 to 10 years. The present work aimed to create a facilitator for museum visitors, developing a prototype of mobile device app using the beacons and the qrcode technology to access information about the railway museum objects. The importance of this research is based on the railway estimation around the world and mainly in our region. The need to preserve culture and spread the history memory is found in Bauru railway museum, and in this scenario a research and an app prototype were developed using android technologies, beacons sensors (IoT), qrcode, internet, bluetooh and Mobile devices (smartphones, tablet) to make the experience more attractive and interesting for the visitors. The app prototype and the technologies mentioned above have brought a new setting to visitors, joining the real and virtual worlds, substantially improving their museum experience and having visitors to go back to the museum in the future and bring other visitors.

En realtidsbaserad kollaborativ webbapplikation kategoriseras som en molntjänst och en molntjänst består utav en webbapplikation och en eller flera databaser. MongoDB som används i projektet är en icke-relationsdatabas. För att uppnå realtid används verktyget HTML5 WebSockets. Problemet är att hur ska den realtidsbaserade kollaborativa webbapplikationen byggas upp för att kunna uppdatera datan så snabbt som möjligt vid förändring. Databaserna som testas mot varandra är MySQL mot MongoDB och för att testa databaserna byggs en realtidsbaserad kollaborativ webbapplikation för modellering av UML-diagram. För att testa hypotesen utförs ett experiment och experimentet påvisade att hypotesen stämde delvis. MongoDB är snabbar på att uppdatera ett specifikt objekt jämfört med MySQL i tre av fyra testfall och för att hämta all data presterar databaserna nästan identiskt i alla testfallen. För fortsatt arbete är de intressant att testa en större datamängd och se hur det påverkar hämtningstiden när all data hämtas från databaserna.

Context. Cassandra is a NoSQL Database which handles large amount of data simultaneously and provides high availability for the data present. Compaction in Cassandra is a process of removing stale data and making data more available to the user. This thesis focusses on analyzing the impact of Cassandra compaction on Cassandra’s performance when running inside a Docker container. Objectives. In this thesis, we investigate the impact of Cassandra compaction on the database performance when it is used within a Docker based container platform. We further fine tune Cassandra’s compaction settings to arrive at a sub-optimal scenario which maximizes its performance while operating within a Docker. Methods. Literature review is performed to enlist different compaction related metrics and compaction related parameters which have an effect on Cassandra’s performance. Further, Experiments are conducted using different sets of mixed workload to estimate the impact of compaction over database performance when used within a Docker. Once these experiments are conducted, we modify compaction settings while operating under a write heavy workload and access database performance in each of these scenarios to identify a sub-optimal value of parameter for maximum database performance. Finally, we use these sub-optimal parameters to perform an experiment and access the database performance. Results. The Cassandra and Operating System related parameters and metrics which affect the Cassandra compaction are listed and their effect on Cassandra’s performance has been tested using some experiments. Based on these experiments, few sub-optimum values are proposed for the listed metrics. Conclusions. It can be concluded that, for better performance of Dockerized Cassandra, the proposed values for each of the parameters in the results (i.e. 5120 for Memtable_heap_size_in_mb, 24 for concurrent_compactors, 16 for compaction_throughput_mb_per_sec, 6 for Memtable_flush_writers and 0.14 for Memtable_cleaup _threshold) can be chosen separately but not the union of those proposed values (confirmed from the experiment performed). Also the metrics and parameters affecting Cassandra performance are listed in this thesis.

Trafiken till webbapplikationer ökar därför ställs det högre krav på att svarstiderna för användaren hålls nere även fast det blir högre trafik och mer data som behöver laddas till webbapplikationerna. Där det vanligaste språket för att hämta data ifrån databaser är PHP som är ett språk som varit med i många år. När det nu finns möjlighet till att skiva all kod i ett och samma språk som JavaScript med Node.js är frågan hur PHP står sig emot JavaScript i svarstider för användaren. Det blir också vanligare med NoSql databaser istället för RDBMS Detta arbete gör ett experiment där JavaScript och PHP ställs emot varandra och kollar hur dom påverkar svarstider. Där även programmeringspåken tar användning av en RDBMS och en NoSql databas. Där resultatet visar på att det inte går att skilja dom åt om man kollar på svarstider.

Informationshantering med dokumentdatabaser har ökat i omfattning de senaste åren och tekniken finns nu representerad bland de fyra mest använda databaserna i världen. Den här studien undersöker användningen av dokumentdatabaser samt vad som kan ligga bakom valet att börja använda dem. För att studera användandet av dokumentdatabaser har den mest populära dokumentdatabasen, MongoDB, valts ut som studiens undersökta fall. Studien har genomförts genom att studera litteratur och publicerat material om databastekniken samt genom att utföra intervjuer med användare av denna. MongoDB har beskrivits som lämplig för användning vid hantering av olika typer av applikationer eller system med ostrukturerad data och för användning i skalbara miljöer. Den har även beskrivits som lättillgänglig och enkel att lära sig då den har en gratisversion och mycket manualer på internet. Studien har visat att dokumentdatabaser kan användas för att hantera information i avgränsade miljöer så som mobil- eller webbapplikationer men även i skalbara system med stora mängder data. Dokumentdatabaser har visat sig motiveras för användning tack vare sin möjlighet att hantera flexibilitet i datastruktur och datavolym. För att kunna erbjuda flexibilitet kring struktur och volym har vissa avkall gjorts gällande transaktionssäkerhet och dataintegritet för dokumentdatabaser. Detta har kunnat påvisas som de främsta motiveringarna för användning av dokumentdatabaser men också som en av de främsta motiveringarna emot att använda dem.

An event store is a database for storing events in an event sourcing system. Instead of storing the current state, a very common way to persist data, an event sourcing system captures all changes to an application state as a sequence of events. Usually the event store is a relational database. Relational databases have several drawbacks and therefore NoSQL databases have been developed. The purpose of this thesis is to explore the possibility of using a NoSQL database in an event sourcing system. We will see how data is stored in an event store and then evaluate di↵erent solutions to find a suitable database. The graph database Neo4j was selected to be further investigated and a Neo4j event store has been implemented. At last the implemented solution is evaluated against the existing event store that uses a relational database. The conclusion of this thesis is that event store data could easily be modeled in Neo4j but some queries became complex to implement. The performance tests showed us that the implemented event store had poorer performance than the existing one using a relational database.

NoSQL is basically a family name for all Database Management Systems (DBMS) that is not Relational DBMS. The fast growth of all social networks has led to a huge amount of unstructured data that NoSQL DBMS is supposed to handle better than Relational DBMS. Most comparisons performed are between Relational DBMS and NoSQL DBMS. In this paper, the comparison is about non-functional properties for different types of NoSQL DBMS instead. Three of the most common NoSQL types are Document Stores, Key-Value Stores and Column Stores. The most used DBMS of those types are MongoDB, Redis and Apache Cassandra. After working with the databases and performing YCSB Benchmarking the conclusion is that if the database should handle an enormous amount of data, Cassandra is most probably best choice. If speed is the most important property and if all data fits within the memory; Redis is probably the most well suited database. If the database needs to be flexible and versatile, MongoDB is probably the best choice.

Cassandra is a NoSQL(Not only Structured Query Language) database which serves large amount of data with high availability .Cassandra data storage dimensioning also known as Cassandra capacity planning refers to predicting the amount of disk storage required when a particular product is deployed using Cassandra. This is an important phase in any product development lifecycle involving Cassandra data storage system. The capacity planning is based on many factors which are classified as Cassandra specific and Product specific.This study is to identify the different Cassandra specific and product specific factors affecting the disk space in Cassandra data storage system. Based on these factors a model is to be built which would predict the disk storage for Ericsson’s voucher system.A case-study is conducted on Ericsson’s voucher system and its Cassandra cluster. Interviews were conducted on different Cassandra users within Ericsson R&D to know their opinion on capacity planning approaches and factors affecting disk space for Cassandra. Responses from the interviews were transcribed and analyzed using grounded theory.A total of 9 Cassandra specific factors and 3 product specific factors are identified and documented. Using these 12 factors a model was built. This model was used in predicting the disk space required for voucher system’s Cassandra.The factors affecting disk space for deploying Cassandra are now exhaustively identified. This makes the capacity planning process more efficient. Using these factors the Voucher system’s disk space for deployment is predicted successfully.