Frequently asked questions about DataStax Enterprise (DSE)

Yes. You can use DSE OpsCenter.

See Cassandra driver compatibility.

DSE’s architecture allows any authorized user to connect to any node in any datacenter and access data using the Cassandra Query Language (CQL). CQL uses a similar syntax to SQL.

You can issue CQL statements with the following tools:

See Test your DataStax Enterprise (DSE) cluster.

The NoSQL term originally referred to a new generation of databases that shunned SQL for other interfaces. The term NoSQL has recently become a catch-all term for post-relational "not-only SQL" databases that use a method of storage different from a relational, or SQL, database.

DSE is a distributed and highly available database that uses peer-to-peer communication.

Cassandra-based databases, like DSE, are different from relational databases. For example:

DataStax highly recommends reviewing the DSE architecture to learn about key concepts and functionality that are essential to proper configuration and optimal performance.

See How are consistent read and write operations handled?.

Yes. See the following:

See How do I discover consistency level performance?.

See How is the consistency level configured? and How is the serial consistency level configured?.

Most clusters consist of multiple nodes that store replicas of the data to ensure high availability and fault tolerance. In this configuration, one node acts as the coordinator for a given query. The coordinator node selects replicas to complete the request and returns the result to the client. For more information about the mechanics of read and write requests, including failure handling, see the following:

Apache Spark is an open source analytics project that provides a fast and general engine for large-scale data processing. DSE integrates Apache Spark real-time and batch analytics processing to more easily manage both database and analytics with a single operational system.

Apache Solr is an open source search project that produces a highly reliable, scalable, and distributed search system that provides search for databases. DSE Search integrates Solr to manage search indexes with a persistent store. DSE Search provide enterprises with the ability to perform text search and text analysis.

DSE Management Services automatically handle administration and maintenance tasks and assist with overall database cluster management:

This depends on your use case. If you need to collect data pertaining to a problem that occurs sporadically, and you chose configuration values that don’t substantially degrade performance, there is no significant downside to leaving the objects enabled permanently.

Typically, performance overhead (CPU and memory usage) is negligible when using the default configuration values provided by DataStax Enterprise (DSE). Performance overhead might increase if you use a non-default configuration. For example, setting longer TTLs and shorter refresh intervals leads to higher memory and disk consumption.

Only enable DSE Search performance objects on DSE Search nodes. Specifically, this means nodes where DSE Search indexes reside that can observe search operations.

Start by enabling these performance objects on one DSE Search node. Then, if needed, you can enable the objects across all DSE Search nodes in the cluster.

Don’t mix indexes on the same table. Using 2i and DSE Search indexes on the same table isn’t supported.

No. GRANT statements using an ON filter ROWS IN clause don’t produce errors, and LIST ALL PERMISSIONS returns the defined restriction. However, the permissions aren’t enforced.

All communication occurs over TCP sockets and can be secured by using the standard Java Security SSL/TLS implementation in the JVM. Additional application specific protocols, like gossip and the CQL Binary Protocol, rely on these sockets for transport.

See Secure DataStax Enterprise ports.

The default role is a superuser role that has full access to the database, and the default credentials are publicly known.

DataStax recommends using firewall rules to isolate the cluster until you create a non-default superuser role and disable the cassandra role.

DSE uses role-based access control (RBAC) to manage permissions and user access. Initially, the database has one default superuser role.

To properly secure your database, you must create a non-default superuser role, disable the default cassandra role, and create non-superuser roles for other users and service accounts that need to access your database.

With DSE Unified Authentication enabled, the DSE Role Manager determines which roles to assign to authenticated users.

For more information, see About Role Based Access Control.

DSE supports standard object permission management to assign roles specific permissions at the table and row level. Permissions to access all keyspaces, specific keyspaces, tables, functions, or MBeans can be granted to a role. For more information, see Setting up Logins and Users.

See About DSE Unified Authentication.

DSE supports Microsoft Active Directory, OpenLDAP, and Oracle Directory Server Enterprise Edition. For more information, see Defining an LDAP Scheme.

DSE supports role management based on LDAP group membership.

Configure an LDAP scheme with group lookup, set the Role Management mode to LDAP, create roles that match the group names, and then assign permissions to those roles. For more information, see Defining an LDAP Scheme.

DataStax recommends using the memberof search method for group lookup, but DSE also supports directory search.

In general, arbitrary client programs don’t directly access the database. Database access by the general user population is controlled at the application layer. Access between application nodes and database nodes should be controlled with conventional firewall mechanisms, such as Linux iptables. Database administrators are an exception to allow connections from DBA hosts.

You can grant or revoke permissions at the row level within a table. This is known as row-level access control (RLAC), which is an aspect of RBAC.

RLAC grants and revokes permissions on individual rows within a table by filtering on a text partition column.

For more information, see Setting up Row Level Access Control (RLAC).

Encryption keys can be managed off-server or locally:

Yes, although the client certificate DN is not used as a database user principal. For more information, see Configuring SSL for Client-to-Node Connections.

You can enable Transparent Data Encryption (TDE) on individual tables. Use the ALTER TABLE command to set encryption and compression on a table. When a table is encrypted, your applications can read and write to SSTables that use different encryption algorithms or use no encryption. For more information, see Transparent Data Encryption.

EBS encryption is another way to encrypt data files like audit logs, system logs, and SSTable index files (which store partition keys in plain text when using TDE). EBS encryption is considered less complex operationally, so you might prefer it over TDE. Typically, use TDE when full-disk encryption is cost prohibitive or not feasible.

No. TDE applies to the entire table.

Yes, DSE provides configurable audit logging:

For more information, see Setting up Database Auditing and Configure logging.