Please see https://cassandra.apache.org/doc/latest/ for the documentation of Apache Cassandra (TM). We will not duplicate this here. However, we want to point out the differences. All classese within Zuri-AI wide column store database begin with com.zuri.ai, not with org.apache.cassandra. We also prefixed environment variables according to the service they parameterize. Regarding folders and configuration files, please see the information below.

In the downloaded file, you find three folders, covering different aspects of the product.

Folder zuri-ai 

Its \bin subfolder contains the Zuri-AI wide column store database and corresponding tools, explained below. Subfolder \logs is for writing database logs, subfolder \data contains the data you persist with this product, and finally, subfolder \config contains several configuration files, explained below. 

The \bin subfolder contains the following four programs: 

1. zuri-ai-daemon (aka cassandra): This is the database itself. Just start it if your applications want to connect to it. It takes few seconds to start.
2. zuri-ai-node-tool (aka nodetool): This tool is for admin purposes. It gives you health-check information, table-usage and network statistics, or the contents of system tables. Please start it to get an overview of the different commands it offers. For example, an important command is describecluster. With it you can quickly check, if the database is already up and running, still in initialization, or if anything is wrong.
3. zuri-ai-jmx-tool (aka jmxtool): This tool is for admin purposes. The database provides an interface for configuration and metrics gathering via so called JMX (java management extensions). This tool allows you to read out and dump this information. 
4. zuri-ai-client: This tool provides a quick and dirty way to communicate with the database. Start it with address localhost and port 9042 to connect with your local database instance, execute the STARTUP command, and then fire common CQL commands at will. You exit the tool with EXIT.

The \config subfolder contains several configuration files.

1. File zuri-ai.yaml is the main one, which lets you change ports, configure ssl, configure the way commit-logging or compaction is done, and much more. In contrast to the configuration of Apache Cassandra (TM), i.e., cassandra.yaml, constants in this file are UPPERCASE, e.g., PERIODIC, not periodic, and the handling of folders is unified. The mechanism to determine a folder is mostly the following one: Zuri-AI takes the ..._directory_uri environment variable, expecting a URI, if present. If not present, it takes the ..._directory environment variable, expecting a full path name, if present. If not present, Zuri-AI takes the ..._directory_uri configuration-file parameter, expecting a URI, if present. If not present, it takes the ..._directory configuration-file parameter as relative URI path to the home-directory URI, if present. If not present, it takes a relative URI path to the home-directory URI as default parameter. This allows for flexible configuration. Most importantly, it ensures that the configuration file itself is platform independent, because platform-specific path names are kept outside.
2. Files zuri-ai-rack-dc.properties and zuri-ai-topology.properties give the database the information on how it is embedded into a larger cluster of databases.
3. File zuri-ai-commitlog-archiving.properties allows to provide single stdin-stdout commands when commit-log archiving takes place. When using this feature, beware that the commands are platform-dependent. 

Folder zuri-ai-driver

If your application wants to communicate with the database, it needs a driver for it. Such driver is provided here, in case you develop in a programming language for the JVM, like Java (TM). It contains two jar files, the driver itself (zuri-ai-driver-1.0.x-SNAPSHOT.jar), and a jar for the low-level transport protocol between your application and the database (zuri-ai-native-protocol-1.0.x-SNAPSHOT.jar). Copy both of them in the classpath of your application. In addition, the driver also needs libraries provided by third parties. For your convenience, we have provided a file (zuri-ai-driver-pom-dependencies.txt) with the Maven (TM) pom-file dependencies, so that you can include them easily in your project.  

Folder zuri-ai-examples

The best way to learn something new is to try it out practically. We have provided Java sources with example code in the standard folder structure that can give you a quick start into accessing the database with your application. It includes gathering version information, gathering topology and schema data, executing classical CRUD functionality for songs and playlists, and also includes experimental code on ANN (approximate nearest neighbor) vector search. The latter is a topic where Apache Cassandra (TM) still needs to improve (a lot), and we will drive this topic forward in the near future. The configuration files for the driver and the logger, respectively, are contained in the \1.0.x\src\main\resources subfolder.

Column-wise authorization

You can now grant and revoke permissions to roles on single columns of a table, not just on the whole table.

While this is not a "game changer", there is a real need for such functionality in certain business contexts. For this, we extended the CQL language. For example, you can now write:

GRANT CREATE ON ALL COLUMNS OF TABLE customer IN KEYSPACE marketing TO sales_manager

GRANT SELECT ON COLUMN last_update_timestamp OF TABLE marketing.customer TO auditor

GRANT MODIFY ON COLUMN audit_comment OF TABLE customer IN KEYSPACE marketing TO auditor

REVOKE SELECT ON COLUMN birth_date OF TABLE marketing.customer TO business_assistant

In plain English: This gives everyone with sales-manager-role the permission to create new customer columns. It gives every auditor the permissions to write comments in a certain column and to read timestamps of last row updates. Lastly, the business assistant is not allowed to see the birth dates of customers.

We also provide authorization support in our driver with a "fluent api". Our understanding is that current Cassandra (tm) Java (tm) driver lacks such support completely. For example, you can now write in your Java (tm) code:

final SimpleStatement revokeFromColumn = revoke(permission)
  .onColumn(columnName)
  .ofTable(tableName)
  .inKeyspace(keyspaceName)
  .from(roleName)
  .build();
session.execute(revokeFromColumn);

Analogously, to grant a column permission. Role management and granting/revoking permissions on levels (all columns, table, all tables, keyspace, all keyspaces) are also supported. The examples include such authorization code on column level that you can try out.