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

ProxStor is a cloud-based human proximity storage and query informational system taking advantage of both the near ubiquity of mobile devices and the growing digital infrastructure in our everyday physical world, commonly referred to as the Internet of Things (IoT). The combination provides the opportunity for mobile devices to identify when entering and leaving the proximity of a space based upon this unique identifying infrastructure information. ProxStor provides a low-overhead interface for storing these proximity events while additionally offering search and query capabilities to enable a richer class of location aware applications. ProxStor scales up to store and manage more than one billion objects, while enabling future horizontal scaling to expand to multiple systems working together supporting even more objects. A single seamless web interface is presented to clients system.. More than 18 popular graph database systems are supported behind ProxStor. Performance benchmarks while running on Neo4j and OrientDB graph database systems are compared to determine feasibility of the design. / text

In this research we study what is the theoretical complexity of Neo4J, OrientDB and GraphDB, (three known Graph Databases that can be accessed by a Java instance), and how this complexity is manifested in a real life performance, To study their practical performance, a software was implemented and named as a profiler, which is capable to profile, (to record the time that is needed), each operation, and display the results in an accurate and organized manner. The technical documentation of those 3 databases was reviewed as well, to identify how the databases work, and what are their strong and weak points. By the profiling process, the best performance was displayed by Neo4J, and while OrientDB failed to deliver, GraphDB takes the second place in terms of performance. We can identify a potential in OrientDB’s approach, but its structure is too complex and rigid. Neo4J has a robust structure and an architecture that gives to it a great performance, while the Cypher syntax, which Neo4J uses, minimizes the possibility of human error. GraphDB is optimized for large scale public-data operations but performs well as a stand-alone solution as well. / <p>An important part of this publication is its GitHub Repository</p><p>https://github.com/Exarchias/graph-databases-profiler</p>