Optimizing an Amazon Neptune bulk load - Amazon Neptune
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Optimizing an Amazon Neptune bulk load

Use the following strategies to keep the load time to a minimum for a Neptune bulk load:

  • Clean your data:

    • Be sure to convert your data into a supported data format before loading.

    • Remove any duplicates or known errors.

    • Reduce the number of unique predicates (such as properties of edges and vertices) as much as you can.

  • Optimize your files:

    • If you load large files such as CSV files from an Amazon S3 bucket, the loader can break up the large files and manage concurrency for you.

    • If you load multiple files from an Amazon S3 folder, the loader automatically loads vertex files first, then edge files afterwards.

    • Breaking up very large files into a few smaller ones can let the loader process them in parallel.

    • Compressing the files reduces transfer times. The loader supports gzip compression of source files.

  • Check your loader settings:

    • If you don't need to perform any other operations during the load, use the OVERSUBSCRIBE  parallelism parameter. This parameter setting causes the bulk loader to use all available CPU resources when it runs. It generally takes 60%-70% of CPU capacity to keep the operation running as fast as I/O constraints permit.


      When parallelism is set to OVERSUBSCRIBE or HIGH (the default setting), there is the risk when loading openCypher data that threads may encounter a race condition and deadlock, resulting in a LOAD_DATA_DEADLOCK error. In this case, set parallelism to a lower setting and retry the load.

    • If your load job will include multiple load requests, use the queueRequest parameter. Setting queueRequest to TRUE lets Neptune queue up your requests so you don't have to wait for one to finish before issuing another.

    • If your load requests are being queued, you can set up levels of dependency using the dependencies parameter, so that the failure of one job causes dependent jobs to fail. This can prevent inconsistencies in the loaded data.

    • If a load job is going to involve updating previously loaded values, be sure to set the updateSingleCardinalityProperties parameter to TRUE. If you don't, the loader will treat an attempt to update an existing single-cardinality value as an error. For Gremlin data, cardinality is also specified in property column headers (see Property Column Headers).

    • You can use the failOnError parameter to determine whether bulk load operations should fail or continue when an error is encountered. Also, you can use the mode parameter to be sure that a load job resumes loading from the point where a previous job failed rather than reloading data that had already been loaded.

  • Scale up   –   Set the writer instance of your DB cluster to the maximum size before bulk loading. Note that if you do this, you must either scale up any read-replica instances in the DB cluster as well, or remove them until you have finished loading the data.

    When your bulk load is complete, be sure to scale the writer instance down again.

See Request Parameters for more details about setting loader request parameters.