Category: arangodb

ArangoDB – Quick Guide ”; Previous Next ArangoDB – A Multi-Model First Database ArangoDB is hailed as a native multi-model database by its developers. This is unlike other NoSQL databases. In this database, the data can be stored as documents, key/value pairs or graphs. And with a single declarative query language, any or all of your data can be accessed. Moreover, different models can be combined in a single query. And, owing to its multi-model style, one can make lean applications, which will be scalable horizontally with any or all of the three data models. Layered vs. Native Multi-Model Databases In this section, we will highlight a crucial difference between native and layered multimodel databases. Many database vendors call their product “multi-model,” but adding a graph layer to a key/value or document store does not qualify as native multi-model. With ArangoDB, the same core with the same query language, one can club together different data models and features in a single query, as we have already stated in previous section. In ArangoDB, there is no “switching” between data models, and there is no shifting of data from A to B to execute queries. It leads to performance advantages to ArangoDB in comparison to the “layered” approaches. The Need for Multimodal Database Interpreting the [Fowler’s] basic idea leads us to realize the benefits of using a variety of appropriate data models for different parts of the persistence layer, the layer being part of the larger software architecture. According to this, one might, for example, use a relational database to persist structured, tabular data; a document store for unstructured, object-like data; a key/value store for a hash table; and a graph database for highly linked referential data. However, traditional implementation of this approach will lead one to use multiple databases in the same project. It can lead to some operational friction (more complicated deployment, more frequent upgrades) as well as data consistency and duplication issues. The next challenge after unifying the data for the three data models, is to devise and implement a common query language that can allow data administrators to express a variety of queries, such as document queries, key/value lookups, graphy queries, and arbitrary combinations of these. By graphy queries, we mean queries involving graph-theoretic considerations. In particular, these may involve the particular connectivity features coming from the edges. For example, ShortestPath, GraphTraversal, and Neighbors. Graphs are a perfect fit as data model for relations. In many real-world cases such as social network, recommendor system, etc., a very natural data model is a graph. It captures relations and can hold label information with each edge and with each vertex. Further, JSON documents are a natural fit to store this type of vertex and edge data. ArangoDB ─ Features There are various notable features of ArangoDB. We will highlight the prominent features below − Multi-model Paradigm ACID Properties HTTP API ArangoDB supports all popular database models. Following are a few models supported by ArangoDB − Document model Key/Value model Graph model A single query language is enough to retrieve data out of the database The four properties Atomicity, Consistency, Isolation, and Durability (ACID) describe the guarantees of database transactions. ArangoDB supports ACID-compliant transactions. ArangoDB allows clients, such as browsers, to interact with the database with HTTP API, the API being resource-oriented and extendable with JavaScript. ArangoDB – Advantages Following are the advantages of using ArangoDB − Consolidation As a native multi-model database, ArangoDB eliminates the need to deploy multiple databases, and thus decreases the number of components and their maintenance. Consequently, it reduces the technology-stack complexity for the application. In addition to consolidating your overall technical needs, this simplification leads to lower total cost of ownership and increasing flexibility. Simplified Performance Scaling With applications growing over time, ArangoDB can tackle growing performance and storage needs, by independently scaling with different data models. As ArangoDB can scale both vertically and horizontally, so in case when your performance demands a decrease (a deliberate, desired slow-down), your back-end system can be easily scaled down to save on hardware as well as operational costs. Reduced Operational Complexity The decree of Polyglot Persistence is to employ the best tools for every job you undertake. Certain tasks need a document database, while others may need a graph database. As a result of working with single-model databases, it can lead to multiple operational challenges. Integrating single-model databases is a difficult job in itself. But the biggest challenge is building a large cohesive structure with data consistency and fault tolerance between separate, unrelated database systems. It may prove nearly impossible. Polyglot Persistence can be handled with a native multi-model database, as it allows to have polyglot data easily, but at the same time with data consistency on a fault tolerant system. With ArangoDB, we can use the correct data model for the complex job. Strong Data Consistency If one uses multiple single-model databases, data consistency can become an issue. These databases aren’t designed to communicate with each other, therefore some form of transaction functionality needs to be implemented to keep your data consistent between different models. Supporting ACID transactions, ArangoDB manages your different data models with a single back-end, providing strong consistency on a single instance, and atomic operations when operating in cluster mode. Fault Tolerance It is a challenge to build fault tolerant systems with many unrelated components. This challenge becomes more complex when working with clusters. Expertise is required to deploy and maintain such systems, using different technologies and/or technology stacks. Moreover, integrating multiple subsystems, designed to run independently, inflict large engineering and operational costs. As a consolidated technology stack, multi-model database presents an elegant solution. Designed to enable modern, modular architectures with different data models, ArangoDB works for cluster usage as well. Lower Total Cost of Ownership Each database technology requires ongoing maintenance, bug fixing patches, and other code changes which are provided by the vendor. Embracing a multi-model database significantly reduces the related maintenance costs simply by eliminating the number

ArangoDB – Data Models and Modeling ”; Previous Next In this chapter, we will focus on the following topics − Database Interaction Data Model Data Retrieval ArangoDB supports document based data model as well as graph based data model. Let us first describe the document based data model. ArangoDB”s documents closely resemble the JSON format. Zero or more attributes are contained in a document, and a value attached with each attribute. A value is either of an atomic type, such as a number, Boolean or null, literal string, or of a compound data type, such as embedded document/object or an array. Arrays or sub-objects may consist of these data types, which implies that a single document can represent non-trivial data structures. Further in hierarchy, documents are arranged into collections, which may contain no documents (in theory) or more than one document. One can compare documents to rows and collections to tables (Here tables and rows refer to those of relational database management systems – RDBMS). But, in RDBMS, defining columns is a prerequisite to store records into a table, calling these definitions schemas. However, as a novel feature, ArangoDB is schema-less – there is no a priori reason to specify what attributes the document will have. And unlike RDBMS, each document can be structured in a completely different way from another document. These documents can be saved together in one single collection. Practically, common characteristics may exist among documents in the collection, however the database system, i.e., ArangoDB itself, does not bind you to a particular data structure. Now we will try to understand ArangoDB”s [graph data model], which requires two kinds of collections — the first is the document collections (known as vertices collections in group-theoretic language), the second is the edge collections. There is a subtle difference between these two types. Edge collections also store documents, but they are characterized by including two unique attributes, _from and _to for creating relations between documents. In practice, a document (read edge) links two documents (read vertices), both stored in their respective collections. This architecture is derived from the graph-theoretic concept of a labeled, directed graph, excluding edges that can have not only labels, but can be a complete JSON like document in itself. To compute fresh data, delete documents or to manipulate them, queries are used, which select or filter documents as per the given criteria. Either being simple as an “example query” or being as complex as “joins”, queries are coded in AQL – ArangoDB Query Language. Print Page Previous Next Advertisements ”;

ArangoDB – Crud Operations ”; Previous Next In this chapter, we will learn the different operations with Arangosh. The following are the possible operations with Arangosh − Creating a Document Collection Creating Documents Reading Documents Updating Documents Let us start by creating a new database. We will use the following line of code to create a new database − 127.0.0.1:8529@_system> db._createDatabase(“song_collection”) true The following line of code will help you shift to the new database − 127.0.0.1:8529@_system> db._useDatabase(“song_collection”) true Prompt will shift to “@@song_collection” 127.0.0.1:8529@song_collection> From here we will study CRUD Operations. Let us create a collection into the new database − 127.0.0.1:8529@song_collection> db._createDocumentCollection(”songs”) Output [ArangoCollection 4890, “songs” (type document, status loaded)] 127.0.0.1:8529@song_collection> Let us add a few documents (JSON objects) to our ”songs” collection. We add the first document in the following way − 127.0.0.1:8529@song_collection> db.songs.save({title: “A Man”s Best Friend”, lyricist: “Johnny Mercer”, composer: “Johnny Mercer”, Year: 1950, _key: “A_Man”}) Output { “_id” : “songs/A_Man”, “_key” : “A_Man”, “_rev” : “_VjVClbW—” } Let us add other documents to the database. This will help us learn the process of querying the data. You can copy these codes and paste the same in Arangosh to emulate the process − 127.0.0.1:8529@song_collection> db.songs.save( { title: “Accentchuate The Politics”, lyricist: “Johnny Mercer”, composer: “Harold Arlen”, Year: 1944, _key: “Accentchuate_The” } ) { “_id” : “songs/Accentchuate_The”, “_key” : “Accentchuate_The”, “_rev” : “_VjVDnzO—” } 127.0.0.1:8529@song_collection> db.songs.save( { title: “Affable Balding Me”, lyricist: “Johnny Mercer”, composer: “Robert Emmett Dolan”, Year: 1950, _key: “Affable_Balding” } ) { “_id” : “songs/Affable_Balding”, “_key” : “Affable_Balding”, “_rev” : “_VjVEFMm—” } How to Read Documents The _key or the document handle can be used to retrieve a document. Use document handle if there is no need to traverse the collection itself. If you have a collection, the document function is easy to use − 127.0.0.1:8529@song_collection> db.songs.document(“A_Man”); { “_key” : “A_Man”, “_id” : “songs/A_Man”, “_rev” : “_VjVClbW—“, “title” : “A Man”s Best Friend”, “lyricist” : “Johnny Mercer”, “composer” : “Johnny Mercer”, “Year” : 1950 } How to Update Documents Two options are available to update the saved data − replace and update. The update function patches a document, merging it with the given attributes. On the other hand, the replace function will replace the previous document with a new one. The replacement will still occur even if completely different attributes are provided. We will first observe a non-destructive update, updating the attribute Production` in a song − 127.0.0.1:8529@song_collection> db.songs.update(“songs/A_Man”,{production: “Top Banana”}); Output { “_id” : “songs/A_Man”, “_key” : “A_Man”, “_rev” : “_VjVOcqe—“, “_oldRev” : “_VjVClbW—” } Let us now read the updated song”s attributes − 127.0.0.1:8529@song_collection> db.songs.document(”A_Man”); Output { “_key” : “A_Man”, “_id” : “songs/A_Man”, “_rev” : “_VjVOcqe—“, “title” : “A Man”s Best Friend”, “lyricist” : “Johnny Mercer”, “composer” : “Johnny Mercer”, “Year” : 1950, “production” : “Top Banana” } A large document can be easily updated with the update function, especially when the attributes are very few. In contrast, the replace function will abolish your data on using it with the same document. 127.0.0.1:8529@song_collection> db.songs.replace(“songs/A_Man”,{production: “Top Banana”}); Let us now check the song we have just updated with the following line of code − 127.0.0.1:8529@song_collection> db.songs.document(”A_Man”); Output { “_key” : “A_Man”, “_id” : “songs/A_Man”, “_rev” : “_VjVRhOq—“, “production” : “Top Banana” } Now, you can observe that the document no longer has the original data. How to Remove Documents The remove function is used in combination with the document handle to remove a document from a collection − 127.0.0.1:8529@song_collection> db.songs.remove(”A_Man”); Let us now check the song”s attributes we just removed by using the following line of code − 127.0.0.1:8529@song_collection> db.songs.document(”A_Man”); We will get an exception error like the following as an output − JavaScript exception in file ”/usr/share/arangodb3/js/client/modules/@arangodb/arangosh.js” at 97,7: ArangoError 1202: document not found ! throw error; ! ^ stacktrace: ArangoError: document not found at Object.exports.checkRequestResult (/usr/share/arangodb3/js/client/modules/@arangodb/arangosh.js:95:21) at ArangoCollection.document (/usr/share/arangodb3/js/client/modules/@arangodb/arango-collection.js:667:12) at <shell command>:1:10 Print Page Previous Next Advertisements ”;

ArangoDB – Example Case Scenarios ”; Previous Next In this chapter, we will consider two example scenarios. These examples are easier to comprehend and will help us understand the way the ArangoDB functionality works. To demonstrate the APIs, ArangoDB comes preloaded with a set of easily understandable graphs. There are two methods to create instances of these graphs in your ArangoDB − Add Example tab in the create graph window in the web interface, or load the module @arangodb/graph-examples/example-graph in Arangosh. To start with, let us load a graph with the help of web interface. For that, launch the web interface and click on the graphs tab. The Create Graph dialog box appears. The Wizard contains two tabs – Examples and Graph. The Graph tab is open by default; supposing we want to create a new graph, it will ask for the name and other definitions for the graph. Now, we will upload the already created graph. For this, we will select the Examples tab. We can see the three example graphs. Select the Knows_Graph and click on the green button Create. Once you have created them, you can inspect them in the web interface – which was used to create the pictures below. The Knows_Graph Let us now see how the Knows_Graph works. Select the Knows_Graph, and it will fetch the graph data. The Knows_Graph consists of one vertex collection persons connected via one edge collection knows. It will contain five persons Alice, Bob, Charlie, Dave and Eve as vertices. We will have the following directed relations Alice knows Bob Bob knows Charlie Bob knows Dave Eve knows Alice Eve knows Bob If you click a node (vertex), say ‘bob’, it will show the ID (persons/bob) attribute name. And on clicking any of the edge, it will show the ID (knows/4590) attributes. This is how we create it, inspect its vertices and edges. Let us add another graph, this time using Arangosh. For that, we need to include another endpoint in the ArangoDB configuration file. How to Add Multiple Endpoints Open the configuration file − # vim /etc/arangodb3/arangod.conf Add another endpoint as shown in the terminal screenshot below. Restart the ArangoDB − # service arangodb3 restart Launch the Arangosh − # arangosh Please specify a password: _ __ _ _ __ __ _ _ __ __ _ ___ ___| |__ / _` | ”__/ _` | ”_ / _` |/ _ / __| ”_ | (_| | | | (_| | | | | (_| | (_) __ | | | __,_|_| __,_|_| |_|__, |___/|___/_| |_| |___/ arangosh (ArangoDB 3.1.27 [linux] 64bit, using VPack 0.1.30, ICU 54.1, V8 5.0.71.39, OpenSSL 1.0.2g 1 Mar 2016) Copyright (c) ArangoDB GmbH Pretty printing values. Connected to ArangoDB ”http+tcp://127.0.0.1:8529” version: 3.1.27 [server], database: ”_system”, username: ”root” Please note that a new minor version ”3.2.2” is available Type ”tutorial” for a tutorial or ”help” to see common examples 127.0.0.1:8529@_system> The Social_Graph Let us now understand what a Social_Graph is and how it works. The graph shows a set of persons and their relations − This example has female and male persons as vertices in two vertex collections – female and male. The edges are their connections in the relation edge collection. We have described how to create this graph using Arangosh. The reader can work around it and explore its attributes, as we did with the Knows_Graph. Print Page Previous Next Advertisements ”;

ArangoDB – A Multi-Model First Database ”; Previous Next ArangoDB is hailed as a native multi-model database by its developers. This is unlike other NoSQL databases. In this database, the data can be stored as documents, key/value pairs or graphs. And with a single declarative query language, any or all of your data can be accessed. Moreover, different models can be combined in a single query. And, owing to its multi-model style, one can make lean applications, which will be scalable horizontally with any or all of the three data models. Layered vs. Native Multi-Model Databases In this section, we will highlight a crucial difference between native and layered multimodel databases. Many database vendors call their product “multi-model,” but adding a graph layer to a key/value or document store does not qualify as native multi-model. With ArangoDB, the same core with the same query language, one can club together different data models and features in a single query, as we have already stated in previous section. In ArangoDB, there is no “switching” between data models, and there is no shifting of data from A to B to execute queries. It leads to performance advantages to ArangoDB in comparison to the “layered” approaches. The Need for Multimodal Database Interpreting the [Fowler’s] basic idea leads us to realize the benefits of using a variety of appropriate data models for different parts of the persistence layer, the layer being part of the larger software architecture. According to this, one might, for example, use a relational database to persist structured, tabular data; a document store for unstructured, object-like data; a key/value store for a hash table; and a graph database for highly linked referential data. However, traditional implementation of this approach will lead one to use multiple databases in the same project. It can lead to some operational friction (more complicated deployment, more frequent upgrades) as well as data consistency and duplication issues. The next challenge after unifying the data for the three data models, is to devise and implement a common query language that can allow data administrators to express a variety of queries, such as document queries, key/value lookups, graphy queries, and arbitrary combinations of these. By graphy queries, we mean queries involving graph-theoretic considerations. In particular, these may involve the particular connectivity features coming from the edges. For example, ShortestPath, GraphTraversal, and Neighbors. Graphs are a perfect fit as data model for relations. In many real-world cases such as social network, recommendor system, etc., a very natural data model is a graph. It captures relations and can hold label information with each edge and with each vertex. Further, JSON documents are a natural fit to store this type of vertex and edge data. ArangoDB ─ Features There are various notable features of ArangoDB. We will highlight the prominent features below − Multi-model Paradigm ACID Properties HTTP API ArangoDB supports all popular database models. Following are a few models supported by ArangoDB − Document model Key/Value model Graph model A single query language is enough to retrieve data out of the database The four properties Atomicity, Consistency, Isolation, and Durability (ACID) describe the guarantees of database transactions. ArangoDB supports ACID-compliant transactions. ArangoDB allows clients, such as browsers, to interact with the database with HTTP API, the API being resource-oriented and extendable with JavaScript. Print Page Previous Next Advertisements ”;

Basic Concepts and Terminologies ”; Previous Next In this chapter, we will discuss the basic concepts and terminologies for ArangoDB. It is very important to have a knowhow of the underlying basic terminologies related to the technical topic we are dealing with. The terminologies for ArangoDB are listed below − Document Collection Collection Identifier Collection Name Database Database Name Database Organization From the perspective of data model, ArangoDB may be considered a document-oriented database, as the notion of a document is the mathematical idea of the latter. Document-oriented databases are one of the main categories of NoSQL databases. The hierarchy goes like this: Documents are grouped into collections, and Collections exist inside databases It should be obvious that Identifier and Name are two attributes for the collection and database. Usually, two documents (vertices) stored in document collections are linked by a document (edge) stored in an edge collection. This is ArangoDB”s graph data model. It follows the mathematical concept of a directed, labeled graph, except that edges don”t just have labels, but are full-blown documents. Having become familiar with the core terms for this database, we begin to understand ArangoDB”s graph data model. In this model, there exist two types of collections: document collections and edge collections. Edge collections store documents and also include two special attributes: first is the _from attribute, and the second is the _to attribute. These attributes are used to create edges (relations) between documents essential for graph database. Document collections are also called vertex collections in the context of graphs (see any graph theory book). Let us now see how important databases are. They are important because collections exist inside databases. In one instance of ArangoDB, there can be one or many databases. Different databases are usually used for multi-tenant setups, as the different sets of data inside them (collections, documents, etc.) are isolated from one another. The default database _system is special, because it cannot be removed. Users are managed in this database, and their credentials are valid for all the databases of a server instance. Print Page Previous Next Advertisements ”;

ArangoDB – Command Line ”; Previous Next In this chapter, we will discuss how Arangosh works as the Command Line for ArangoDB. We will start by learning how to add a Database user. Note − Remember numeric keypad might not work on Arangosh. Let us assume that the user is “harry” and password is “hpwdb”. 127.0.0.1:8529@_system> require(“org/arangodb/users”).save(“harry”, “hpwdb”); Output { “user” : “harry”, “active” : true, “extra” : {}, “changePassword” : false, “code” : 201 } Print Page Previous Next Advertisements ”;