-
Notifications
You must be signed in to change notification settings - Fork 6.4k
RocksJava Basics
RocksJava is a project to build high performance but easy-to-use Java driver for RocksDB.
(We try hard to keep RocksJava API in sync with RocksDB's C++ API, but it often falls behind. We highly encourage community contributions ... so please feel free to send us a Pull Request if you find yourself needing a certain API which is in C++ but not yet in Java.)
In this page you will learn the basics of RocksDB Java API.
To build RocksJava, you first need to set your JAVA_HOME environment variable to point to the location where Java SDK is installed. Once JAVA_HOME is properly set, simply running make rocksdbjava
will build the Java bindings for RocksDB:
$ make rocksdbjava
This will generate rocksdbjni.jar
and librocksdbjni.so
(or librocksdbjni.jnilib in Mac) in java/target
directory under the rocksdb's root directory. Specifically, rocksdbjni.jar
contains the Java classes that defines the Java API for RocksDB, while librocksdbjni.so
includes the C++ rocksdb library and the native implementation of the Java classes defined in rocksdbjni.jar
.
To run unit tests:
$ make jtest
To clean:
$ make jclean
We also publish the JNI jars to maven, in case you just want to depend on the jar instead of building it on your own.
We provided some samples here, if you want to jump directly into code.
A rocksdb
database has a name which corresponds to a file system directory. All of the contents of database are stored in this directory. The following example shows how to open a database, creating it if necessary:
import org.rocksdb.RocksDB;
import org.rocksdb.Options;
...
// a static method that loads the RocksDB C++ library.
RocksDB.loadLibrary();
// the Options class contains a set of configurable DB options
// that determines the behavior of a database.
Options options = new Options().setCreateIfMissing(true);
RocksDB db = null;
try {
// a factory method that returns a RocksDB instance
db = RocksDB.open(options, "path/to/db");
// do something
} catch (RocksDBException e) {
// do some error handling
...
}
...
TIP: You may notice the
RocksDBException
class above. This exception class extendsjava.lang.Exception
and encapsulates theStatus
class in the C++ rocksdb, which describes any internal errors of RocksDB.
When you are done with a database, it is suggested to call RocksDB.close()
(or its equivalent method dispose()
) and options.dispose()
to release their C++ resource manually, although these associated C++ resources will also be released in their finalizer:
if (db != null) db.close();
options.dispose();
TIP: When you see a class extends
RocksObject
, it means any instance of this class has a native handle which stores a C++ pointer pointing to some rocksdb related resource. It is suggested to invokeRocksObject.dispose()
manually once all its associated databases have been closed. Note that calling a non-static method of an already-disposed RocksObject instance is an undefined behavior.
The database provides put
, remove
, and get
methods to modify/query the database. For example, the following code moves the value stored under key1
to key2
.
byte[] key1;
byte[] key2;
// some initialization for key1 and key2
try {
byte[] value = db.get(key1);
if (value != null) { // value == null if key1 does not exist in db.
db.put(key2, value);
}
db.remove(key1);
} catch (RocksDBException e) {
// error handling
}
TIP: You can also control the
put
andget
behavior usingWriteOptions
andReadOptions
by calling their polymorphic methodsRocksDB.put(WriteOptions opt, byte[] key, byte[] value)
andRocksDB.get(ReadOptions opt, byte[] key)
.
TIP: To avoid creating a byte-array in
RocksDB.get()
, you can also use its parametric methodint RocksDB.get(byte[] key, byte[] value)
orint RocksDB.get(ReadOptions opt, byte[] key, byte[] value)
, where the output value will be filled into the pre-allocated output buffervalue
, and itsint
returned value will indicate the actual length of the value associated with the inputkey
. When the returned value is greater thanvalue.length
, this indicates the size of the output buffer is insufficient.
Contents
- RocksDB Wiki
- Overview
- RocksDB FAQ
- Terminology
- Requirements
- Contributors' Guide
- Release Methodology
- RocksDB Users and Use Cases
- RocksDB Public Communication and Information Channels
-
Basic Operations
- Iterator
- Prefix seek
- SeekForPrev
- Tailing Iterator
- Compaction Filter
- Multi Column Family Iterator
- Read-Modify-Write (Merge) Operator
- Column Families
- Creating and Ingesting SST files
- Single Delete
- Low Priority Write
- Time to Live (TTL) Support
- Transactions
- Snapshot
- DeleteRange
- Atomic flush
- Read-only and Secondary instances
- Approximate Size
- User-defined Timestamp
- Wide Columns
- BlobDB
- Online Verification
- Options
- MemTable
- Journal
- Cache
- Write Buffer Manager
- Compaction
- SST File Formats
- IO
- Compression
- Full File Checksum and Checksum Handoff
- Background Error Handling
- Huge Page TLB Support
- Tiered Storage (Experimental)
- Logging and Monitoring
- Known Issues
- Troubleshooting Guide
- Tests
- Tools / Utilities
-
Implementation Details
- Delete Stale Files
- Partitioned Index/Filters
- WritePrepared-Transactions
- WriteUnprepared-Transactions
- How we keep track of live SST files
- How we index SST
- Merge Operator Implementation
- RocksDB Repairer
- Write Batch With Index
- Two Phase Commit
- Iterator's Implementation
- Simulation Cache
- [To Be Deprecated] Persistent Read Cache
- DeleteRange Implementation
- unordered_write
- Extending RocksDB
- RocksJava
- Lua
- Performance
- Projects Being Developed
- Misc