How to Distribute Evenly Across Multiple Storage Locations

How to Distribute Evenly Across Multiple Storage Locations

Submitted by nquinn on December 16, 2013 - 12:24pm Introduction When using InfiniteGraph, it is simple to add storage locations using the AddStorageLocation tool which would enable the location to be used for storage when the current main storage location is unavailable (it may no longer be available via the network or the maximum storage capacity may have been reached). At the same time, it can be harder to spread data out evenly during ingest across multiple storage locations because it is a multi-step process. In this blog, the steps to evenly distribute data across storage locations on the same or different hosts are outlined. Placement Configurations In InfiniteGraph, the placement system places data according to a placement model. Without specifying an advanced placement configuration, a default placement model is used. The default placement model places most of the user graph data in one of three groups: Vertex, Edge, and Connector. If a custom placement model is used, these groups can be overridden (see footnote [1]). When setting up the storage locations (local or remote), you can use use the AddStorageLocation tool. When you want to achieve an even distribution of the data, you must also pre-create containers in each of the storage locations for each of the placement groups using the CreateContainers tool. This allows the placement system to “prime” the storage locations and allow the data to spread out according to how many containers were pre-created in each storage location. Image 1: Multiple Storage Locations with Pre-Created Containers Adding storage locations can be done at any time, but pre-creating containers for placement groups need to be done...

Getting Started with InfiniteGraph

Applications and devices are generating a flood of data that is increasingly dense, highly interconnected and generally unstructured. Social Media is an obvious example where massive amounts of complex data, such as videos, photos and voice recordings are created daily, but there are many other domains where this applies. Markets such as Healthcare, Security, Telecom and Finance are also facing the pain of managing complex, interconnected and real-time information to stay competitive and maintain performance, security, business intelligence and ROI opportunities. . This type of data of highly-connected entities, some are referring to as the future “Internet of Things”, is not easily managed using a traditional relational databases; emerging technologies and especially graph databases are rising to address these natural graph problems. Using an enterprise-ready, distributed graph database that is complementary to existing architectures, such as InfiniteGraph™, enables organizations to easily store, manage and search the connections and relationships within data and perform rapid analysis in real-time. InfiniteGraph is a distributed, scalable, high-performance graph database that supports developers and companies seeking to identify and utilize the relationships and connections in massive data sets. InfiniteGraph reduces the time needed to discover these connections from days using standard SQL technologies to a matter of seconds. Given the explosion of data all around us and the increasing need for solutions that can discover and extract value from the relationships within that data, we have developed this comprehensive Software Reviewer’s Guide to help you get started with InfiniteGraph 3.1. InfiniteGraph 3.1 Software Reviewer’s Guide This guide takes you step by step from installing InfiniteGraph to navigating your very own graph. You can download...

Upgrading a Database from InfiniteGraph 3.0 to 3.1

Submitted by tnatar on September 9, 2013 - 9:38am InfiniteGraph provides an igupgrade tool that lets you upgrade a graph database instance to the current InfiniteGraph release. Before performing an upgrade, make a backup copy of your graph database. When running igupgrade, make sure that the graph database being upgraded is not being used (it should be offline). To upgrade your graph database using the command line: Make a backup of the graph database to be upgraded. Go to the directory where the boot file and the federated database file is located. Recover all transactions of the federated database, by using the command: oocleanup -local myGraph.boot Perform a basic backup, by using the command: oobackup -full -destination fullPathOfBackupDir myGraph.boot Make sure no one is currently using the graph database. Run the igupgrade tool, by using the command: ​igupgrade -bootfile myGraph.boot ​The command prompt will display a message whether the database was upgraded, or if upgrading is not required since it’s already the latest version. Product:  InfiniteGraph Version:  3.1...

Upgrading Your Federated Database to New Catalogs

Submitted by tnatar on September 6, 2013 - 8:54am Terms used and their meanings fd – federated database db - database old catalogs – pre-R9.0 internal database format new catalogs – R9.0 or later version’s internal database format Reason to upgrade Starting from Release 11.3, support for the old catalog format is no longer available. R11.2 is the last release of Objy that is backwards compatible with dbs using old catalogs. Identify if you are using old catalogs You will most likely have fds or dbs with old catalogs if you created them using a pre-R9.0 version of Objy/DB. You can be using an R9.0 or later version of Objy/DB but still use old catalog fds or dbs. How to check if you have old catalog fds or dbs If you are not sure whether the fds or dbs are using old catalogs or new catalogs, you can determine that by using one of these two methods below: Run oofile on the fd or any individual database files, to see the release with which they are compatible. If the output displays: Compatible with Objectivity release 5 through 11 The fd or db is using old catalogs. If the output displays: Compatible with Objectivity release 9 or later The fd or db is using new catalogs. Write a utility program that calls isR9catalog() on a handle to the fd or an individual database. If the API call returns 0, The fd or db is using old catalogs. If the API call returns 1, The fd or db is using new catalogs. How to upgrade from old catalogs to new catalogs...