No description available.

I denna studie utförs ett experiment med en empirisk mätning på svarstiderna från Redis och Memcached som cachningstekniker med en MySQL-databas. En webbapplikation hämtar data från databasen, som lagras på en cacheserver. Experimentet utförs på en laptop som hanterar alla delar i systemet. Tiden det tar för webbapplikationen att få den begärda informationen från cache eller databasen, kallas för svarstid. Hypotesen antar att Redis skall producera ett bättre resultat än Memcached. En webbplats skapades som artefakt och används som testmiljö där experimentet utförs. Användningen av Memcached ändrades till Memcache på grund av kompatibilitetsproblem mellan Memcached och Windows. Memcache är en äldre version av Memcached, men som innehåller samma funktioner. De resultaten som framförs av mätserierna presenteras i linjediagram och stapeldiagram, där medelvärdet av svarstider samt standardavvikelse. I en analys visas Redis utföra en bättre cachning än Memcache. I alla tre mätserier visar Redis ett lägre medelvärde av svarstider än Memcache.

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.

In der vorliegenden Arbeit werden die Datenbankmanagementsysteme MongoDB, ScyllaDB, OrientDB, Aerospike und Redis mit dem Yahoo! Cloud Serving Benchmark unter der Verwendung von SSD-Speicher getestet. Dazu werden zuerst die verschiedenen NoSQL-Systemtypen beschrieben. Besonderheiten von SSD-Speicher werden zusammengefasst. Anschließend werden Besonderheiten der ausgewählten Datenbankmanagementsystemen und des Yahoo! Cloud Serving Benchmarks beschrieben, um die durchzuführenden Benchmarks zu planen. Weiterhin wird die verwendete Hardware beschrieben, um eine Replikation dieser Benchmarks zu ermöglichen und ein besseres Bild der zu messenden Performance zu bieten. Nach der Planung der Durchführung der Benchmarks, werden die verschiedenen Datenbankmanagementsysteme auf der oberen Grenze getestet, welche die gegebene Hardware bietet. Mit den Ergebnissen dieser werden weitere Benchmarks unter diversen Bedingungen geplant und durchgeführt. Die Ergebnisse werden jeweils ausgewertet und in dieser Arbeit eingebunden. Diese sind von den gegebenen Umständen stark beeinflusst, sodass allgemeingültige Aussagen nicht möglich sind. Zuletzt wird im Ausblick, welche inhaltliche Lücken und Fragen offen stehen oder weitere zusammenhängende Problemstellungen beschrieben.:1 Einleitung 1.1 Motivation 1.2 Vorgehensweise 2 Gegenstand des Benchmarks 2.1 Modell 2.1.1 Key-Value Store 2.1.2 Document Store 2.1.3 Wide-Column Store 2.1.4 Graph Store 2.1.5 Multi-Model 2.2 Medium 2.2.1 SSD 2.2.2 In-Memory 3 Technische Randbedingungen des Benchmarks 3.1 Ausgewählte Datenbankmanagementsysteme 3.2 Yahoo! Cloud Serving Benchmark 3.3 Genutzte Hardware 3.4 Testlauf des Benchmarks 3.5 Erzielter Vergleich 4 Erste Testreihe: 150GB 21 4.1 Aufgetretene Probleme 4.2 Verwendete Einstellungen 4.3 Ergebnisse: erster Versuch 4.4 Ergebnisse: 150GB 5 Testreihen: Übergreifende Szenarien 5.1 Testreihe 50GB 5.2 Testreihe 10GB 5.3 Testreihe Großes Feld 5.4 Testreihe Sekundärindex 5.5 Testreihe Latenz 5.6 Testreihe Discord 6 Ergebnisse DBMS-intern 6.1 MongoDB 6.2 ScyllaDB 6.3 OrientDB 6.4 Aerospike 6.5 Redis 7 Schlussteil 7.1 Auswertung 7.1.1 YCSB-Tool 7.1.2 MongoDB 7.1.3 ScyllaDB 7.1.4 Aerospike 7.1.5 OrientDB 7.1.6 Redis 7.1.7 SSD-Speicher 7.2 Zusammenfassung 7.3 Ausblick

To meet the demands of 5G and what comes after, telecommunications companies will need to replace their old embedded systems with new technology. One such solution could be to develop cloud-native applications that offer many benefits but are less reliable than embedded systems. Having the different units in the 5G system store their state, or their operational context, in cloud-based databases could reduce downtime in case of failing processes, but various database systems have their advantages and disadvantages. Thus, the choice of implementation must be carefully considered.   This study primarily aims to create a simulator that can measure latency, or the time it takes to write or read dummy data to or from one of two different kinds of databases. Its secondary aim is to produce use cases that mimic situations that a database for state data would need to handle and to collect measurements from them with the help of the simulator.   The simulator was implemented using C++17 and contains a simulator object and separate database clients. The actors representing the units interacting with a 5G network were created by the clients and their state data was stored in either Redis or PostgreSQL databases. Various use cases were designed with the instruction from Ericsson to simulate real-life scenarios and to measure latencies. Quantitative data analysis was performed on the collected data to compare the performances of Redis and PostgreSQL databases in the different use cases.   The study found that Redis on average worked the fastest and that its latency was largely the same regardless of data sizes, while PostgreSQL's latencies, and thus the differences between the databases, varied more depending on the scenario.   The results of the study show that Redis is the one of the two databases that operates more consistently and predictably, which may partly be explained by the fact it is mainly based in the RAM, while PostgreSQL is mainly disk-based.   Future work could involve testing the databases under higher workloads, exploring what would be the impact of running simulations in environments with reduced RAM and not letting Redis use it to its full advantage, and maybe analyzing more latency figures by creating new use cases and running them. Future work can also include an investigation of the effect of Redis database crashes. Moreover, the simulator implementation allows for changing to other types of databases.

[pt] Uma sequência temporal de vetores (vector stream) pode ser modeladacomo uma sequência de pares ((v1, t1). . .(vn, tn)), onde vk é um vetor e tk écarimbo de tempo tais que todos os vetores são da mesma dimensão e tkmenor que tk+1. O problema de busca por similaridade em sequências temporais devetores é definido como: Dado um vetor (de alta dimensão) v e um intervalode tempo T, encontre uma lista ranqueada de vetores, recuperados de umasequência temporal de vetores, que sejam similares a v e que foram recebidosdentro do intervalo de tempo T. Esta dissertação primeiro introduz umafamília de métodos de busca por similaridade em sequências temporais devetores que não dependem da sequência completa, mas se adaptam à medidaque os vetores são incluídos na sequência. Os métodos geram uma sequênciade índices, que são então usados para implementar uma busca aproximadado vizinho mais próximo na sequência temporal de vetores. Em seguida, adissertação descreve uma implementação de um método da família baseado em Hierarchical Navigable Small World graphs. Utilizando esta implementação,a dissertação apresenta uma ferramenta de busca de anúncios classificadosque oferece recuperação de anúncios à medida que usuários continuamentesubmetem novos anúncios. A ferramenta é estruturada em um módulo principale três módulos auxiliares, sendo que o módulo principal é responsável porcoordenar os módulos auxiliares e prover uma interface para o usuário, e osmódulos auxiliares são responsáveis pela codificação dos textos e imagens emvetores, a indexação dos vetores, e o armazenamento dos textos, imagens evetores. Por fim, para avaliar a ferramenta, a dissertação utiliza um conjuntode aproximadamente 1 milhão de registros com as descrições de anúnciosclassificados e suas imagens. Os resultados mostraram que a ferramenta atingiuuma precisão de 98 por cento e um recall de 97 por cento. / [en] A vector stream can be modeled as a sequence of pairs ((v1, t1). . .(vn, tn)), where vk is a vector and tk is a timestamp such that all vectors are of the same dimension and tk less than tk+1. The vector stream similarity search problem is defined as: Given a (high-dimensional) vector q and a time interval T, find a ranked list of vectors, retrieved from a vector stream, that are similar to q and that were received in the time interval T. This dissertation first introduces a family of vector stream similarity search methods that do not depend on having the full set of vectors available beforehand but adapt to the vector stream as the vectors are added. The methods generate a sequence of indices that are used to implement approximated nearest neighbor search over the vector stream. Then, the dissertation describes an implementation of a method in the family based on Hierarchical Navigable Small World graphs. Based on this implementation, the dissertation presents a Classified Ad Retrieval tool that supports classified ad retrieval as new ads are continuously submitted. The tool is structured into a main module and three auxiliary modules, where the main module is responsible for coordinating the auxiliary modules and for providing a user interface, and the auxiliary modules are responsible for text and image encoding, vector stream indexing, and data storage. To evaluate the tool, the dissertation uses a dataset with approximately 1 million records with descriptions of classified ads and their respective images. The results showed that the tool reached an average precision of 98 percent and an average recall of 97 percent.

This paper delivers a comparative analysis of the performance of three of the NoSQL technologies in Web applications. These technologies are graph stores, key-value stores, and document stores. The study aims to assist developers and organizationsin picking the suitable NoSQL solution for their application. For this purpose, three identical e-book applications were developed. Each of these is connected to adatabase from the selected technologies to examine how they perform compared toeach other against various performance measures.

Många verksamheter representeras idag på internet i omodern stil vilket kan påverka besökarens uppfattning om verksamheten negativt. I detta arbete har en webbsida rekonstruerats. Webbsidan tillhör en förening med verksamhet inom gaming och esport. Rekonstruktionen är till för att ge besökare en klar bild av vad föreningens huvudverksamhet är och för att integrera streamingtjänsten Twitch för att ge besökare ytterligare en anledning att återbesöka sidan. Dessutom har laddningstiden för startsidan optimerats för att ge bättre besökupplevelse. Med hjälp av Redis och metoden Eager loading visar arbetet hur man kan sänka laddningstiden på en webbsida.

Mobile applications and real-time data are excellent tools for rapidly sharing information. Such information may concern public transportation, such as time tables and traffic delays. This project has involved the development of a trip planner, which can subscribe to real-time data in order to inform the end user about the position of transit vehicles and trip updates. A trip planner is an application which, after having been given a start and a destination by the user, generates the possible trip between these two locations. The route is displayed upon a map, along with information of how the trip is travelled. The real-time data, which is pushed to the application, will inform the user if vehicles are delayed and if the trip needs to be updated due to a missed bus or train. The trip planner for Itract developed in this project is using the graphical interface and some necessary Java classes from the open source application Open Trip Planner. The new trip planner, developed in this project, is compatible with the API of Itract, has some additional functionality and can subscribe to real-time information. To subscribe to real-time information, a database called Redis has been set up in connection to Itract. Another database, known as MongoDB, is used for persistant storage. / Itract

This thesis describes methods for duplicate traffic detection in computer networks. At first, it analyzes the problem of redundant traffic including the description of its origin and causes. The thesis describes on what data and what methods we are able to detect an operation as duplicate. Finally, this thesis explains design of redudant traffic detection algorithm including testing plan and results evaluation.