TIBCO® Graph Database Configuration Guide

Version 3.1

November 2021

Table of Contents

TIBCO Graph Database Configuration

Database Configuration

Database section

Initialization Configuration

Database Segments

Segments

Page

Database Security

Catalog

Identifiers and Rules for Identifiers

Data Types

Attribute Descriptors

Nodetypes

Edgetypes

Indexes

Authorization

Permissions

Privileges

Roles

Users

Import

Runtime Configuration

Cache

Write Ahead Log

Processors

Stored Procedures

Server Configuration

Server

Memory

Input/Output

Processors

Database

Logger

Net Listener

Cluster Configuration

Cluster

Cluster Initialization

Databases

Logger

Net Listeners

Environment

Cluster Manager

Cluster Agent

REST Configuration

Main

Database

Net Listener section

Logger section

Client Connection Properties

Connection Properties

Configuration for Importing Large Files

TIBCO Documentation and Support Services

How to Access TIBCO Documentation

Product-Specific Documentation

How to Contact TIBCO Support

How to Join TIBCO Community

TIBCO Graph Database Configuration

TIBCO Graph Database (TGDB) consists of simple operating system level processes that store graph data, query graph data, and execute complex graph algorithms in a secured and efficient environment. These processes consume resources, and the administrator can determine and configure the parameters for these resources through simple configuration files.

Configurable resources are storage, CPU, threads, queues, network, security, user codes, initial schema, data, and so on.

A configuration file is a simple text file that typically ends with a ‘.conf’’ suffix. The configuration file is defined in sections (configuration class) and each section has a name specified in a square bracket [] and has a set of properties. Each property is of name-value pair. Single line comments start with a # symbol. A configuration class or section defines a named configuration instance with properties. This named configuration instance can be referred to in other sections as property values. The value type is inferred and converted according to the engine's need and its execution semantics.

A sample section is shown below.

The table below shows the list of TGDB binaries providing graph database services and the configuration files they use. The configuration file is specified through the ‘-c’ option

Note: The windows binaries end with ‘.exe’ suffix.

A typical usage of the above binaries with configuration file is shown below:

The subsequent section describes Database configuration, Server configuration, Cluster and REST configuration files and properties.

Database Configuration

The database configuration is specified in its own configuration file and contains sections describing the  initialization and runtime configuration parameters for database settings, the segments. The sections in the database configuration files are as follows:

Database section

A mandatory section with keyword ‘database’ as the section name and is common for both the Initialization and the Runtime configuration. This section specifies the key properties for the database such as the name, the path where the database resides, locale to be used and the default timezone for the database.

Initialization Configuration

The initialization configuration provides information for the server to initialize and configure a database with name as specified in the database section. The configuration is used when you run the graph database server with “-i” parameter.

$> tgdb -i -f -c tgdb.conf

The initialization configuration provides the server information about the following parameters to initialize the database.

• Database Segments
• Database Security
• Database Catalog
• Import  

Initialization process pre-allocates the database segments, sets up the system user and security certificates to be used at runtime. It can optionally set up the schema for the database and import the data if provided.

These parameters are read only during the initialization of the database and stored in the database. Any changes to the configuration later are not read nor affect the database setting.

The subsequent chapter discusses in detail the properties required to define the Segments, Security and Catalog.

Database Segments

The database segment configuration is part of initialization configuration that provides information for the server to initialize and configure a database with name as specified in the database section. The configuration is used when you run the graph database server with “-i” parameter.

$> tgdb -i -f -c tgdb.conf

The initialization configuration provides the server information about the Segments, Security, Catalog, and Import parameters to initialize the database. Initialization process pre-allocates the database segments, sets up the system user and security certificates to be used for runtime. These parameters are read only during the initialization of the database and stored in the database. Any changes to the configuration later are not read nor affect the database setting.

Segments

A database is a collection of segments. The database size is the sum of all the segments. A segment is a physical file allocated on disk. It is specified in Units (M or m for MegaByte, G or g for GigaByte, and T or t for TeraByte). The default Unit if unspecified is Gigabyte. For example, 10M or 10m means 10 Megabyte.

There are four types of segments:

• Data Segment: They manage data pertaining to Catalog, Edges, Nodes, Strings, Text, and so on. Users specify how many initial segments are needed to hold data.
• Index Segment: They contain index data pertaining to Catalog, Edges, and Nodes.
• Control Segment: Control Information about the other segments are written in this.
• Transaction Segment: Transaction Write-Ahead logs are maintained as part of the shared memory backed by file.

Page

A Page is a unit of commit in the database. The storage writer or agent reads/writes data in terms of pages. A segment consists of multiple pages. Each page is of fixed size and is a multiple of 512 bytes. The enumerated values of valid page size and their interpretation is as follows.

Pages are of different types and their purpose is to hold specific data efficiently.

The segment configuration section starts with the keyword ‘segments'. The table below defines and describes the section properties with an example.

Database Security

The security section provides:

1. A system or root user and password for the database to manage and administer.
2. Details on the parameters required for building a self signed database certificate that can be used for securing encrypted attributes. The parameters are typically a Cipher name obtained from the IANA Registry and the arguments for the Cipher.

The cipher name is a TLS 1.2 Cipher Name obtained from IANA Registry.

It can be also be obtained by running the OpenSSL command

$> openssl -V ciphers

The security configuration starts with the keyword ‘security’ and defines the properties as below:

Catalog

The catalog section is part of the initialization section and allows the database to have a schema defined and created during initialization. This is useful as it acts as a template for the lifecycle such as Dev->QA->Integ->Stress->Prod. This is easier to build and makes it very consistent. It is also used as a backup recovery mechanism as the export-import follows the same catalog scheme. The catalog section is completely optional. The alternative to the catalog configuration in the database config is to use administrator scripts and build the catalog.

Unlike most of the TIBCO Graph Database configuration sections, the following sections do not have predefined properties. Instead each entry under the configurations is a system type of the section name. Each one has separate parameters that are allowed. The parameters are what are described in the tables below.

Identifiers and Rules for Identifiers

Many section properties have identifiers and they can be the names of properties. An identifier name is unique in the catalog. It must start with a letter and can contain underscores and numbers. Names starting with “@”, “__”, “$” all belong to the reserved word categories and used are used by various TGDB components. There is no section for identifier name but rules for identifier name need to be declared before it can be used.

Data Types

TGDB supports most of SQL-92 data types with the exception of Arrays. The table below list the types supported by TGDB.

Attribute Descriptors

The attribute descriptors defines a list of attribute descriptors and the keyword used is ‘attrtypes’. The attribute descriptor has name, type, and meta properties for the type. TGDB requires database users to describe all the attributes that must be used with entities.

Nodetypes

The nodetypes defines a list of nodetypes and the keyword used is ‘nodetypes’. A nodetype is a container for nodes of similar type. For example, ‘Person’ nodetype contains data of all the person instances. This is similar to a sql table. A node type has a valid identifier name, the subset of attributes from the attribute descriptor list and a primary key specification.

Edgetypes

The edgetypes defines a type of relation between any two nodes. Each relation has a name and optionally a set of properties. The direction parameter must be specified and be one of DIRECTED, UNDIRECTED, BIDIRECTED, or BIDIRECTION. This section collects a list of edgetypes and is defined by the keyword ‘edgetypes’.

Indexes

The indexes define a list of indexes for node types and the keyword  used is ‘indices’. Indexes allow you to search entities quickly. TGDB supports b-tree indexes. An Index has a name and is for a node type only. It can have unique or non-unique constraints. Furthermore, the index can be composed of single or multiple keys. Multiple keys indexes are referred to as a composite index.  

Authorization

The authorization configuration section provides the set of credentials and the roles granted to these credentials. It consists of two sections:

• Roles
• Users

Roles: Roles are provided with permissions string and a privilege string on catalog objects.

Users: Users are given a name with password and the Roles it can have.

Permissions

Permissions is consent or authorization granted to an user or role on a particular resource. The table describes different kinds of permission, their mnemonic and meaning. 

Privileges

A privilege is a special type of right on the server operations. There are different kinds of privileges and the table lists these privileges with their mnemonic and meaning.

Roles

Define a list of roles identified by the keyword ‘roles’.  A role has privilege and permissions defined on catalog objects.

Permission is a comma separated identifier, each of which is a ''|'' delimited sequence with the first element of the sequence being a string of concatenated permission mnemonics or the keyword ''all'' and every element following the ''|'' delimiter is the catalog object type. For System Catalog use $SYSCATALOG.

Privilege is a string of concatenated privilege mnemonics or the keyword ‘all’ granted to this role

Users

Defines a list of users and is identified by the keyword ‘users’.

Import

As with the Catalog sections, import sections accept any valid node or edge type as a property which will be interpreted as how to import that type. Unlike with the Catalog sections, there are a few reserved properties that specify how the import process should be handled by the server. The keyword for this section is ‘import’.

For importing large files, see the Configuration for Imports. 

Runtime Configuration

The runtime configuration is used by the TGDB server on runtime, when it is servicing requests from  clients. The configuration specifies the cache settings specifications for the databases, settings for Transaction WriteAhead Log, settings for Processors and the information about the Stored Procedures.

Cache

This section is identified by the keyword ‘cache’ that determines the cache breakdown for this database at runtime. Database holds data (nodes, indexes) as pages. There will always be more data stored on disk than the available system memory. The server's  job is to predict the need for a data or index page and efficiently load it and keep it available in memory so queries or transactions can operate at the optimum performance and not wait to reload from the disk. To keep reloading the page, ensure that the memory is available, and it can do so by evicting or freeing pages that have not been used recently. As there are different types of pages, and each page type has a different size configured, there are different caches to manage these pages.

1. Data cache manages data (nodes) pages.
2. Index cache manages index pages.
3. Shared cache manages Text pages, String data, and edge properties pages.
4. Query cache manages entities (node, edges) in object forms for queries to operate.
5. Control cache manages control pages, and catalog pages.

The section allows you to specify cache sizes depending on your application needs. If the application is read centric or query heavy, it can specify a larger number for Query and Index cache setting, and if it is more write centric, then reduce the query cache and index cache settings.  The total cache for the database is a percentage of the total cache allocated by the server. Since the server supports multi-tenancy i.e multiple databases hosted on the same server, the sum of all the database caches should be equal to the total cache allocated for the server. For more information, see the server settings for memory.

The system memory model is shown below:

System Memory Model

x, y and z are referred to as the input cache percentage of the total server cache (cachepct)

The cache settings, their property names, the value type for a database is described below and followed with an example. The cache section is identified by the keyword ‘cache’.

Write Ahead Log

Write Ahead Log is a circular queue of transaction log entries. Each transaction log entry consists of transaction changeList, before commit pages (index, control, and data) and other vital information. The log entry is written to a shared memory as of the current release of the product. For more information, see Shared memory configuration of the server section.

Processors

This section is identified by the keyword ‘processors’. The number of Transaction and Query processors to use for this database from the pool of processors the server has allocated. A processor is a thread and a queue of pending tasks or instructions to execute. The processor follows the Actor model. For more information, see the Server Processor.

Stored Procedures

Stored procedures have their own configuration section ‘storedproc’ in the database configuration file. The stored procedures are scanned from the directory and compiled and loaded into the server's memory. See the table below for the properties, the default value and description associated with them. It also provides a sample:

Server Configuration

The server configuration is a configuration file provided as a command line option to the TGDB server. This file refers to the other configuration files such as the Database configuration files. The server configuration file is used in both the Initialization and Runtime of TGDB servers. During Initialization, it reads the necessary information from the configuration and initializes the database. At runtime, it loads databases and starts the network listener to service client requests. The subsequent sections discuss server configuration in detail. The server configuration file consists of the following section

• Main or Server [tgdb]
• Memory [memory]
• Input/Output [io]
• Processors [processors]
• Databases [databases]
• Logger [logger]
• Network Listener  [netlistener]

Server

The main server section for general properties. It is identified by the keyword ‘tgdb’. The main server section has the name of the server, the locale and timezone information for the log and database defaults, and expiration duration for the ACL tokens.

Memory

This section is identified by the keyword ‘memory’ and specifies settings for the server's memory manager. The server has two kinds of memory manager.

Heap Memory Manager properties are:

1. Supports the max allowed memory on the machine by the OS.
2. Minimum is 1GB and Maximum is 256TB (2^48).
3. Reserves all of the memory specified at startup. Doesn’t grow as other memory managers do, like Java.
4. Locks or Commits the memory manager, so the OS doesn't swap. This is only done if the user running the tgdb process has the permission to do so, otherwise a warning message is issued.
5. The memory is used for Initialization, database caches, message serialization, transient data structures, query processings.
6. Initialization with import can have high memory requirements.
7. Always ensure that the minimum required is sufficient to initialize the database with catalog information.

Shared Memory Manager properties are

1. Memory Backed by an Operating system file.
2. Data committed memory is persisted to the OS file.
3. Supports up to 32G.
4. The memory is used for Transaction Write Ahead Logs, and other administrative functions.
5. Once the Shared memory is created, the shared memory size can increase, but not decrease. But if you need to decrease it, then ensure the system is completely synced to disk, shutdown, and delete the shared memory  file, and restart the server.

Note : In either case, once the server starts, the memory cannot be decreased or increased dynamically.

The server needs to be restarted.

Input/Output

This section is identified by the keyword ‘io’ and controls how the server reads and writes data. The section provides settings for System Administrator to configure for an optimum performance. There are three settings and capture the core ‘io’ needs for an efficient storage access.

• useOsCache -  Enables/Disables the posix system call pread/pwrite and its Windows equivalent to use the operating system to use its file cache. Certain properties to understand while enabling this flag

• This is the O_DIRECT flag usage in unix or unix-like systems.
• This flag helps reclaim valuable memory as the TGDB has a comprehensive caching scheme.
• Operating systems require that the read/write buffers be page aligned or aligned at 512 bytes. Not all buffers can be 512-byte aligned which introduces additional in-memory copying for the operation to complete successfully. Though the copying is extremely fast, this does introduce additional latency.
• O_DIRECT writes the data to the physical medium’s cache, this flag is combined with the writethrough to survive Power failure scenarios. This is important for Transactional systems.
• Since the storage or physical medium’s cache is smaller than the operating system, the calls can be blocked.

• writethrough - Enable/Disables flushing disk cache to the physical storage media.

• Important for Transactional Systems.
• While importing large data into the system, setting this flag to false improves performance significantly.
• Not all OS supports it. For NFS, and certain Linux file systems (ext4), check with the Administrator on mount options.

• synctype - Specifies the amount of metadata to write for every commit call. There are quite a few metadata such as last access time, size, last user and so on, on a file basis. The sync flags are as follows:

• None: This is a special flag which overrides the useOScache and writethrough. This will enable us to use operating system defaults.
• Data: Write only the data that was changed. Pages are committed to disk when combined with write through flag. Fastest for a Transactional system.
• Range: Special flag for Linux operating systems. Similar to Data, but operates on a range.
• All: Write data and the metadata. Typically for a database system, this is never specified. Check with your SA as to the need for it. Provided for completeness.

Processors

This section is identified by the keyword ‘processors’ and specifies the number of processors available with their queue depth. A processor is a thread and a queue of pending tasks or instructions to execute. The processor follows the Actor model. Server creates a Processor Pool and uses this pool to configure the database processor requests.

Database

This section is identified by the keyword ‘databases’ and specifies a list of databases that will be hosted on the server. Each database is listed as the database name, followed by an equal character (=), followed by the path to the database configuration file.

Logger

This section is identified by the keyword ‘logger’ and specifies logging information for the server. The logger has the following key properties:

• The log file name is tgdb_<server-name>_<hostname>_<pid>.log[N].
• Log Level dictates how much logging gets written to the file. The log level is specified as a sequence of one more level:component pair. If a component is absent, then it defaults to “all” the components.
• Support levels are:

• error - System writes logs that are at the error level or below. TGDB code logs certain error conditions at this level.
• warning - Warning messages. Will include error level messages.
• info - Information messages. Helps provide feedback about the system’s progress.
• user - User level message. Can be from Stored Procedures.
• debug, debugfine, debugfiner - varying level of diagnostic message. Useful in understanding and troubleshooting system’s behavior in an error condition.

• Supported components are as below:

• core.all - The core components
• graph.all - The graph components
• pdu.all - The protocol data unit component
• sec.all - The security component
• txn.all - The transaction component
• storage.all - The storage component
• admin.all - The administrative component
• main.all - The container component

• The log entry format is: <timestamp> <level> <thread name> <src:line> - <msg>

Note: For troubleshooting, TIBCO support will request to enable the appropriate component and level. This can be done via the admin console dynamically without restarting the server.

Net Listener

This section is identified by the keyword ‘netlistener’. It provides the TGDB server a set of configuration parameters to start a network listener. The standard configuration properties are as below:

• A net listener has a unique name. There can be multiple net listener sections.
• The network listener is bound to a specific interface and port combination.
• On a multi homed machine, the interface can be identified by the interface name, the IP number or the hostname.
• IPv4 and IPv6 are both supported.
• The transport can be TCP or SSL.  For SSL, the server generates a self-signed certificate dynamically with the SSL parameters on every startup.
• The network listener can specify the maximum number of connections that can be active at any given time.

Cluster Configuration

TGDB provides built-in clustering for high availability and scalability. A Cluster is a system of interconnected homogenous machines within a data center. All machines have the same operating system and have access to the shared storage space.

A high level block diagram for TGDB clustering is shown below.

The components of the TGDB cluster are as follows.

• A TGDB Cluster is a set of interconnected nodes running on a homogeneous set of machines.
• Nodes can have one or more roles assigned.
• A Cluster manager is a node role that:

• Manages the group membership of cluster.
• Provides a consistent and coherent view of the  cluster.
• Acts like a proxy agent for clients.

• Agent is a node role and is of the following type

• Storage Agent - responsible for reading/writing pages to disk.
• Query Agent - Executing queries.
• Transaction Agent - Execution transactions.

• Clustering does not use Shared memory for Write-Ahead Logs.

TGDB configures and starts the cluster using the cluster configuration file. The cluster configuration file provides the cluster definition parameters, the parameters for the managers and agents. Since a cluster is a set of nodes running on a group of interconnected homogeneous machines, the ability to deploy a cluster on any environment using a simple and easy configuration is a key aspect of the deployment.

Cluster configuration file extends the traditional server configuration file by introducing named instances. Consider the following section in a config file:

• “netlistener” is a configuration class with a set of properties such as host, port, max connections etc.
• “queryagent” is a named instance of the netlistener config class, with property values for host, port and protocol.
• The named instance “queryagent” can be referred to in other sections.
• “default” is a keyword that can be used for a config instance. It will match when no config instance by the given name is found, and requires a default configuration.
• In the standalone server configuration, the config class and name instance were implicit.

Cluster processes such as tgdb-agent can configure themselves by specifying a name command line argument.

$bin> ./tgdb-agent -c tgdb-cluster.conf --name queryagent

Cluster

This section is identified by the config class “tgdb-cluster” and defines the cluster setting. It is used to initialize the cluster, and at runtime uses the path parameter to load the cluster definition.

Cluster Initialization

Before  TGDB built-in clustering can be used, a cluster needs to be created and initialized. The cluster is created and initialized by running the following command:

$bin> ./tgdb-clstrmgr -i -f -c tgdb-cluster.conf

The initialization command reads the cluster definition from the cluster config class “tgdb-cluster”. It creates a cluster control database in the path specified that is then used by the cluster manager and cluster agent for:

• Group Membership Protocol

• The Leader election protocol uses the cluster control database as the key token for election.
• The group membership is controlled by the maximum number of agents (maxagents) that can be active within the cluster.

• Quorum Protocol

• Quorum count (quorum) property defines the minimum number of agents to be live, and within that set of agents, it requires a minimum number of storage agents (storageagents) to be live and active. When these two conditions are met, the cluster is said to be in quorum, and is made active.

• List of Databases to be hosted

• The “databases” property points to the database section to identify the list database to be hosted on this cluster.
• A database can only be hosted on a single cluster.
• The database is locked, so no other cluster can access it.

• A Cluster administrator

• On initialization, a cluster administrator with password is created to manage the life cycle of the cluster.
• The purpose of the Cluster administrator is to monitor and manage the agents, assign tasks or roles to agents, restart agents.

• Intra communication Agent user and password

• Cluster creates a default agent user, and password for all inter-agent-cluster communication.
• The agents have a proxy role to each database i.e just connect ‘privilege’ to the database.
• The agents perform any operation on behalf of the user. The user acl token is provided with each operation.

The next section describes all properties for the cluster config class and an example “democluster”

Databases

This section is named instance of database config class. This section is identified as [database:<name>] where the name is the instance name, and can be referred to in any other section. The properties of this section are the same as the Server’s Database config.

Logger

This section is named instance of a logger config class. This section is identified as [logger:<name>] where the name is the instance name, and can be referred to in any other section. The properties of this section are the same as the Server’s Logger config. The name of the logger file is format as specified below: <clustername>-<agentname>-<hostname>-<pid>.log[n]

Net Listeners

This section is named instance of a netlistener config class. This section is identified as [netlistener:<name>] where the name is the instance name, and can be referred to in any other section. The properties of this section are the same as the Server’s Network Listener config.

The name property is used as the instance name in [<config class>:<instance name>] scheme. In the below example the config class is netlistener and the name is oltp

Tip : Use the interface name such as “en01” for the hostname. A system administrator is likely to provision the cluster nodes identically i.e using the same script. This helps the cluster configuration to be used by the cluster manager and agents thereby reducing the configuration management, and confusion caused by multiple configuration files

Environment

The Environment config class serves as a combination of the memory, input/output, and processors section of the server configuration into one section. The meaning and rules for the property are the same.

Note: TGDB Clustering does not use a shared memory setting.

Cluster Manager

The Cluster Manager config class is identified by “tgdb-clustermgr”. There can be multiple named config instances of this class, but at least one of them must be a  “default” instance.

TGDB cluster manager process “tgdb-clstrmgr” reads the configuration file, and tries to configure the process using the name argument passed as shown below:

$bin> ./tgdb-clstrmgr -s -c tgdb-cluster.conf --name inventory_clstrmgr

The rules to pickup the cluster manager configuration is show in the flowchart:

• If --name specified, search config instances of the class “tgdb-clustermgr” for a named instance “inventory_clstrmgr”.
• If found, use the config instance and configure the process accordingly.
• If the named instance is not found, create one from the default configuration and name it “inventory_clstrmgr”.
• If --name was not specified, create one from the default configuration and use a dynamic name.

Cluster Agent

The Cluster Agent config class is identified by “tgdb-agent”. There can be multiple named config instances of this class, but at least one of them must be a  “default” instance.

TGDB cluster agent process “tgdb-agent” reads the configuration file, and tries to configure the process using the name argument passed as shown below:

$bin> ./tgdb-agent -s -c tgdb-cluster.conf --name storageagent

The rules to pickup the cluster agent configuration is show in the flowchart:

• If --name specified, search config instances of the class “tgdb-agent” for a named instance “storageagent”.
• If found, use the config instance and configure the process accordingly.
• If named instance not found, create one from the default configuration and name it “storageagent”.
• If --name was not specified, create one from the default configuration and use a dynamic name.
• The key difference between the cluster manager and agent configuration is that agent configuration does not have the public listeners. It has the member listener aka can only communicate to other agents and cluster manager.
• Member listener must be non-SSL IPv4 net listener.

REST Configuration

The REST configuration contains sections describing the configuration parameters for tuning the TIBCO Graph Database REST server. The sections in the REST configuration files are as follows:

Main

An optional section with keyword ‘tgdb-rest’ as the section name. This section specifies a property to configure the name of the REST server instance.

Database

A mandatory section with keyword ‘database’ as the section name. This section specifies the key properties for the database such as the name, the path where the database resides, connection-pooling parameters, authentication information needed for the database.

Net Listener section

An optional section with keyword “netlistener’ as the section name. This section specifies the key properties for HTTP host and port on which the REST server instance listens to.

Logger section

An optional section with keyword ‘logger’ as the section name. This section specifies the key properties for logging purposes such as the logging level, path to store the log messages, enable console logging.

Client Connection Properties

TGDB provides client API in Java, GO, Python and REST. The client API connects to the TGDB server through a ConnectionFactory class. The ConnectionFactory creates, configures the connection based on the properties the client specifies as its arguments and connects to the server. The configuration properties are categorized as:

• Channel or Socket
• ConnectionPool
• Connection
• Transport Security Level

The following table shows the list properties that a Client can configure while creating a connection. A property can be specified as a fully qualified name which is <category name>,<property name> or just the property name which is also the alias for the property. In some cases the property name and alias name are different, and they are clearly specified in the table. For example, a client can specify the property in either way, and it means the same.

Connection Properties

Configuration for Importing Large Files

In certain cases, while importing large files, the Initialization process can have requirements that require different configuration files and be managed separately. To increase the performance of Import, tuning it differently than what it is for runtime, can achieve significant gains. Here’s a list that you can adjust:

1. Specify high memory settings in the server configuration for Initialization.
2. The query cache can be reduced to minimal.
3. The data and index cache can be increased and the threshold also increased.
4. Initialization might require data to be written to disc asynchronously and not flushed immediately.
5. For large import, the cache setting could be at maximum, and query cache set at minimum. Also set the Data Cache, Index, and its threshold to large values.
6. This could be contrary to the runtime requirements of where the query cache could be large.
7. An example for both server configuration and the database configuration is shown below. Only the relevant sections are shown for importance.

TIBCO Documentation and Support Services

How to Access TIBCO Documentation

Documentation for TIBCO products is available on the TIBCO Product Documentation website, mainly in HTML and PDF formats.

The TIBCO Product Documentation website is updated frequently and is more current than any other documentation included with the product. To access the latest documentation, visit https://docs.tibco.com.

Product-Specific Documentation

Documentation for TIBCO Graph Database is available on https://docs.tibco.com/products/tibco-graph- database-enterprise-edition-3-1-0 page.

This feature is available to both Enterprise edition and Community. The guidelines specified for Clustering are applicable only to Enterprise edition.

The following documents form the documentation set:

• TIBCO® Graph Database Getting Started: Read this manual before reading any other manual in the documentation set. This manual describes the terminology and concepts of the platform. The other manuals in the documentation set assume you are familiar with the information in this manual.
• TIBCO Graph Database Administration : Read this manual to learn how to manage the runtime and deploy and manage applications.
• TIBCO® Graph Database Security Guidelines: Read this manual to learn more about security guidelines and recommendations for TIBCO® Graph Database.
• TIBCO Graph Database Release Notes: Read this manual for a list of new and changed features, steps for migrating from a previous release, and lists of known issues and closed issues for the release.

How to Contact TIBCO Support

You can contact TIBCO Support in the following ways:

• For an overview of TIBCO Support, visit http://www.tibco.com/services/support.
• For accessing the Support Knowledge Base and getting personalized content about products you are interested in, visit the TIBCO Support portal at https://support.tibco.com.
• For creating a Support case, you must have a valid maintenance or support contract with TIBCO. You also need a username and password to log in to https://support.tibco.com. If you do not have a username, you can request one by clicking Register on the website.

How to Join TIBCO Community

TIBCO Community is the official channel for TIBCO customers, partners, and employee subject matter experts to share and access their collective experience. TIBCO Community offers access to Q&A forums, product wikis, and best practices. It also offers access to extensions, adapters, solution accelerators, and tools that extend and enable customers to gain full value from TIBCO products. In addition, users can submit and vote on feature requests from within the TIBCO Ideas Portal. For a free registration, go to https://community.tibco.com.