Tor is a distributed network providing privacy and anonymity on the Internet. Information about Tor is publicly available in a form of consensus documents. Existing tools that are able to display this information do not provide both historical and detailed view of it. A tool named Consensus Parser that provides a detailed, historical view of this information and extends it with geolocation and DNS information, was created as a part of TARZAN research project at Brno University of Technology. It stores the information in regular files on disk and makes it accessible via REST API. This thesis extends Consensus Parser with MariaDB ColumnStore database with a schema designed to conform to OLAP needs. The searching capabilities of Consensus Parser were enhanced by adding 109 new endpoints to 12 existing ones and adding the ability to limit the retrieved information to certain fields only. Disk space needed for storing the information was reduced by a factor of five.

This is a bachelor thesis concerning the response time and CPU effects of indexing in relational databases. Analyzing two popular databases, PostgreSQL and MariaDB with a real-world database structure using randomized entries. The experiment was conducted over Docker and its command-line interface without cached values to ensure fair outcomes. The procedure was done throughout seven different CRUD queries with multiple volumes of database entries to discover their strengths and weaknesses when utilizing indexes. The result chapter shows indicators that indexing has an overall enhancing effect on almost all of the queries. It is found that join, update and delete operations benefits the most from non-clustered indexing. PostgreSQL gains the most from indexes while MariaDB has a minuscule improvement in the response time reduction. A greater usage of CPU resources does not seem to correlate with quicker response times.

Den här studien jämför bildhanteringsprestanda mellan tre olika relationsdatabashanterare.MySQL, MariaDB och PostgreSQL jämförs för att se vilken databashanterare som kan hämtabilder med kortast svarstid. I den här studien utförs experiment för att svara på frågan:“Vilken databas av MySQL, MariaDB och PostgreSQL kommer ha den kortaste svarstidenfrån att en request att visa en bild till att den är hämtad och utritad på skärmen.”. Fråganbesvaras genom att mäta svarstider för respektive databashanterare. Resultatet indikerar attMariaDB hämtar bilder med kortast svarstid i de fall en bild hämtas per sökning, medanPostgreSQL hämtar bilder med kortast svarstid när flera bilder hämtas per sökning. Iframtiden är det intressant att utöka studien med fler databashanterare, samt testa flerbildformat och bildstorlekar.

Efficient performance is pivotal for digital service and product retention, necessitating consideration and design throughout system development. Central to this is the API, orchestrating communication between client and server within a system. GraphQL, created in 2012, revolutionized this interaction by enabling precise data requests. However, less sophisticated implementations of GraphQL often encounter the N+1 problem, where a query requiring N additional database queries is executed, leading to performance inefficiencies. With increasing data interconnectedness, query complexity and the choice of database management system (DBMS) become critical factors. This study investigates whether a GraphQL API performs better with Neo4j, a graph database, or MariaDB, a relational database, and evaluates how various N+1 problem solving tools influence API performance. The study conducted experiments with six API configurations, each subjected to five queries of varying complexity. One configuration utilized Neo4j, while the remaining five used MariaDB. Among the latter, three configurations integrated N+1 problem solving tools. The study shows that, when query complexity and data interconnectedness is low, response times from a GraphQL API using MariaDB, without solving the N+1-problem, are shorter than the response times of an API using Neo4j. It also demonstrates the efficacy of Neo4j when data becomes more interconnected. Furthermore, the study concludes that addressing the N+1 problem is crucial, and that different tools offer varying levels of performance in solving it. Tools that do manage to solve this issue commonly show a significant improvement in response times when interconnected data is requested. / Effektiv prestanda är avgörande för att behålla användare av digitala tjänster och produkter, och måste tas i beaktande när ett system utvecklas. Centralt i sammanhanget är API:et, som koordinerar kommunikationen mellan klient och server inomett system. GraphQL, som skapades 2012, revolutionerade denna interaktion genomatt möjliggöra exakta dataförfrågningar. Mindre genomtänkta implementationer avGraphQL stöter ofta på N+1-problemet, där en förfrågan som kräver N ytterligare databasförfrågningar utförs, vilket leder till sämre prestanda. Med starkare kopplingar mellan data blir komplexiteten i förfrågningar och valet av databas avgörande faktorer. Denna studie syftar till att utforska om ett GraphQL-API presterar bättre medNeo4j, en grafdatabas, eller MariaDB, en relationsdatabas, och utvärderar hur olika verktyg, som löser N+1-problemet, påverkar API-prestandan. Studien genomförde experiment med sex API-konfigurationer, var och en testad med fem förfrågningar av varierande komplexitet. En konfiguration använde Neo4j, medan övriga fem använde MariaDB. Tre av dessa fem konfigurationer implementerade verktyg för att lösa N+1-problemet. Studien visar att, vid enklare frågor utan kopplad data, kan ett GraphQL-API, som använder MariaDB utan att lösa N+1-problemet, ge mycket kortare svarstider än ett API med Neo4j. Neo4j visar däremot sin effektivitet när data med kopplingar efterfrågas. Vidare visade experimenten på vikten av att lösa N+1-problemet. Verktygen lyckades lösa problemet olika väl, men gemensamt för de verktyg som klarar av att lösa det är att de förbättrar svarstiderna avsevärt så fort kopplad data efterfrågas.

This thesis investigates the possibilities of further developing an SQL library in the interactive compiler Storm. Currently, the library only supports the database handler SQLite, and the ambition is  to add support for more database systems. To achieve this addition, a common SQL syntax that is compatible with different database systems is required. The main challenge of developing a common SQL syntax is that each database system has its own variations and deviations from the standard SQL. The study focuses on a comparison between database handlers with the aim of identifying common SQL statements and data types. The goal is to establish a common subset that can be used as the foundation for the general SQL syntax in Storm. The results of the study confirm that it is possible to develop a general SQL syntax in Storm. In addition to the comparative study, the work also involves implementing support for the database handler MariaDB in Storm. / Detta examensarbete undersöker möjligheterna att vidareutveckla ett SQL-bibliotek i den interaktiva kompilatorn Storm. Vidareutvecklingen innebär tillägg av stöd för fler databashanterare, då SQL-biblioteket för närvarande endast stödjer SQLite. För att möjliggöra tillägget krävs en generell SQL-syntax som är kompatibel med olika databashanterare. Utmaningen som uppstår vid framtagandet av en generell syntax är databasernas variationer och avvikelser från varandra och SQL-standarden. Denna studie fokuserar på en jämförelse mellan databashanterarna med syfte att identifiera gemensamma SQL-satser och datatyper. Målet är att ta fram ett gemensamt subset som kan stå till grund för den generella syntaxen i SQL-biblioteket i Storm. Utifrån studiens resultat kan det fastställas att framtagning av en generell SQL-syntax i Storm är genomförbar. Utöver den jämförande studien innebär dessutom arbetet en implementering av stöd för databasen MariaDB i Storm.

The master thesis deals with the issue of evaluation of efficiency and data collection of lines in production, using the APROL program from B\&R automation. The aim of this work is to create a program completed requirement, which is going to be compared with already implemented projects of the company and will serve to create a company standard. The first part is devoted to the description of the theory of this issue and used software. The second part describes the solution of the line simulator and the whole concept of collection and evaluation.

Syftet med denna uppsats var att jämföra två olika databashanteringssystem, MongoDB samt MariaDB, utifrån specifika krav från en uppdragsgivare gällande prestanda samt komplexitet. Då MariaDB är ett SQL-databashanteringssystem och MongoDB ett NoSQLdatabashanteringssystem som bygger på olika databasmodeller behandlas data på olika sätt, vilket ligger som grund till jämförelsen mellan de olika databashanteringssystemen. Uppsatsen fokuserar på att utifrån fyra olika tester, två prestandatestet och två tester som jämför komplexiteten, kunna jämföra databashanteringssystemen MariaDB och MongoDB. Dessa databashanteringssystem ställdes emot de angivna kraven från uppdragsgivaren för att se vilket av dem som är bäst lämpat. Två olika applikationer utvecklades med hjälp av C# och användes under testerna för att utföra testerna. Efter att testerna utförts rekommenderades MongoDB till uppdragsgivaren på grund av den prestandafördel som testerna visade på i långsiktig användning av systemet. Även komplexiteten för MongoDB visade sig vara mindre vilket stärker rekommendationen ytterligare.

This master thesis concern relational databases and their query optimizer’s sensitivity to cardinality estimates and the e!ect the quality of the estimate has on the number of different access methods used for the same relation. Two databases are evaluated — PostgreSQL and MariaDB — on a real-world dataset to provide realistic results. The evaluation was done via a tool implemented in Clojure and tests were conducted on a query and subsets of it with varying sample sizes used when estimating cardinality. The results indicate that MariaDB’s query optimizer is less sensitive to cardinality estimates and for all tests select the same access methods, regardless of the quality of the cardinality estimate. This stands in contrast to PostgreSQL’s query optimizer which will vary between using an index or doing a full table scan depending on the estimated cardinality. Finally, it is also found that the predicate value used in the query a!ects the access method used. Both PostgreSQL and MariaDB are found sensitive to this property, with MariaDB having the largest number of di!erent access methods used depending on predicate value. / Detta examensarbete behandlar relationella databaseer och hur stor påverkan kvaliteten på den uppskattade kardinaliteten har på antalet olika metoder som används för att hämta data från samma relation. Två databaser testades — PostgreSQL och MariaDB — på ett verkligt dataset för att ge realistiska resultat. Utvärderingen gjordes med hjälp av ett verktyg implementerat i Clojure och testerna gjordes på en query, och delvarianter av den, med varierande stora sample sizes för kardinalitetsuppskattningen. Resultaten indikerar att MariaDBs query optimizer inte påverkas av kardinalitetsuppskattningen, för alla testerna valde den samma metod för att hämta datan. Detta skiljer sig mot PostgreSQLs query optimizer som varierade mellan att använda sig av index eller göra en full table scan beroende på den uppskattade kardinaliteten. Slutligen pekade även resultaten på att båda databasernas query optimizers varierade metod för att hämta data beroende på värdet i predikatet som användes i queryn.

Scania is undergoing a transformation from being a supplier of trucks, buses and engines to a supplier of complete and sustainable transport solutions. Scania Test Rig Development (NLR) group is responsible for developing technical solutions for component testing at Scania R&D and its subdivision Testing Systems (NLRI) is responsible for the development of the software. NLRI maintains the physical server storage including a test result database where results from all over R&D are stored. This database is based on a combination of a file server and a SQL server. The database structure is outdated and restricting to users. The technology for storing data has excelled in many areas since this system was developed. This thesis proposed a new database solution consisting of a new relational model and storage improvements. The varying attributes created by the testing rigs was to be handled with dynamic columns. Dynamic columns allow one to store different sets of columns for each row in a database table. This was tried out in a prototype database using the MariaDB database management system utilizing the JSON syntax for dynamic columns with sample data converted from the database currently in use. The prototype was successfully set up and could utilize the functionalities of dynamic columns. Performance tests, or benchmarks, comparing the current database, the dynamic column prototype and a reference regular SQL column prototype were done. The tests showed that temporarily parsing a dynamic column into regular columns when querying, something referred to as creating virtual columns, was very slow in comparison to a equivalent query on the current database. When fetching the whole or parts of the dynamic columns JSON content the query speeds were only insignificantly slower than a query fetching the same data from regular SQL columns: Both were much faster than the current database. The conclusion was that the new database model with dynamic columns, along with other improvements to the structure presented in this thesis, could be a more future-compatible replacement to the current solution, although it doesn't contribute on its own to new functionalities that for example a cloud platform or advanced analysis tools could give. The proposed database system could be a good complement to further innovations. / Scania genomgår just nu en transformation från att vara en leverantör av lastbilar, bussar och motorer till att vara en leverantör av helhetslösningar av hållbara transportsystem. Scania Test Rig Development (NLR) gruppen är ansvarig för att utveckla tekniska lösningar för komponenttester hos Scania R&D och underavdelningen Testing Systems (NLRI) är ansvarig för utvecklingen av mjukvaran. NLRI underhåller den fysiska lagringen av data, vilket inkluderar en testresultat-databas som lagrar resultat från hela R&D. Databasen består av en kombination av en filserver och en SQL-server. Databasstrukturen är föråldrad och begränsande för användare. Teknologin för att lagra data har fortskridit i många områden sedan denna databas utvecklades. Denna rapport föreslog en ny databaslösning bestående av en ny relationsmodell och förbättringar av datalagring. De varierande attributen som skapas av testbänkarna skulle hanteras med hjälp av dynamiska kolumner. Dynamiska kolumner tillåter att man lagrar olika uppsättningar av kolumner för varje rad i en databastabell. Detta prövades i en prototypdatabas som använde databashanteraren MariaDB och JSON-syntax för de dynamiska kolumnerna på en provdatamängd konverterad från den nuvarande databasen. Prototypen upprättades framgångsrikt och kunde utnyttja funktionerna hos de dynamiska kolumnerna. Prestandatester utfördes där den nuvarande databasen, prototypen med dynamiska kolumner och en referensprototyp med vanliga SQL-kolumner, jämfördes. Testerna visade att tillfälligt skapa vanliga kolumner ur den dynamiska kolumnen vid en sökning, något som kallas för virtuella kolumner, var väldigt långsamt jämförelse med en ekvivalent sökning i den nuvarande databasen. När man hämtade hela eller delar av den dynamiska kolumnens JSON-innehåll var sökningshastigheten obetydligt långsammare än att hämta samma datamängd från vanliga SQL-kolumner: Båda var betydligt mycket snabbare än den nuvarande databasen. Slutsatsen drogs att databasmodellen med dynamiska kolumner, tillsammans med andra förbättringar av databasstrukturen presenterade i denna rapport, kan vara en framtidskompatiblare ersättning till den nuvarande databasen, även om det föreslagna systemet inte på egen hand bidrar till nya funktionaliteter som en molnplatform eller avancerad analysverktyg kan ge. Det föreslagna databassystemet kunde därför vara ett gott komplement till vidare innovationer.

This project has been done on the lamp shop named Lampshopen in Falun. The goal of the project has been to create a web application that is designed towards the customer and the administrators. The web application is built with a SPA design which gives the customer the possibility to see the products and have the possibility to book and unbook products given the customer is registered and logged in. The administrators have the possibility to view, add, revise, and delete products and information correlated to the product table. Administrators can also handle categories, other users permission levels and also delete users. The result of the project is a webstore where the demand from the firm is upheld within the projects scope. / Detta arbete har utförts för Lampshopen i Falun. Målet med projektet var att skapa en webbutik som är till för både besökaren och för administratörer. Genom ett SPA ska besökaren kunna se utbudet och ha möjligheten att boka eller avboka produkten givet att hen är registrerad. För administratören ska hen kunna lägga till, revidera eller ta bort produkter samt kunna hantera kategorier och konton på ett lämpligt sätt. Resultatet av projektet är en fungerade webbutik där de efterfrågade kraven uppnåtts.