April 2013 Summaries

Cassandra uses a log-structured storage engine, which employs tombstones to indicate deleted rows or columns. These tombstones are kept for at least the time specified by gc_grace_seconds before being discarded during compaction. While this system allows fast deletes and writes, it can lead to performance issues when reading data with many tombstones, especially in column-level deletes scenarios. To mitigate these issues, consider partitioning data with high churn rate into separate rows or tables and deleting entire rows or truncating tables when needed. Additionally, specifying a start column for queries can help skip collecting irrelevant tombstones and improve performance.

Counting keys (rows) in Apache Cassandra is not straightforward due to its design principles focused on write optimization and avoiding reads during writes. While it's possible to get an estimate using 'nodetool cfstats', the exact count requires scanning through all rows, which can be time-consuming and resource-intensive for large datasets. Maintaining a manual count is also challenging due to issues like row deletes and replication consistency. It's recommended to evaluate if the count is truly necessary for your application before implementing any workarounds.

Kerberos, a gold standard in security, provides users on a network access to services with single sign-on. Datastax has integrated DSE 3.0 into a Kerberos protected network. User principals represent the identity of a user on the system and are made up of three parts: primary/instance@realm. Cassandra also needs to know about the principals created. Each network service is given a service principal, which has its own principal for each instance running on different nodes/hosts. Kerberos provides authentication only (auth), authentication and data signing (auth-int), or authentication, data signing, and encryption (auth-conf).

This blog post provides tips for troubleshooting problems with DataStax Enterprise (DSE) and how to effectively communicate these issues to support teams. It emphasizes the importance of checking system logs, including system.log, output.log, and jobtracker's system.log, as well as using grep to search for errors. Additionally, it suggests providing context around error messages by attaching a portion of the log file before and after the error message. The post also highlights the importance of including basic information about your DSE setup when filing support tickets and offers suggestions on how to reproduce problems for troubleshooting purposes. Finally, it presents common issues such as UnavailableExceptions, TTransportExceptions, TimedOutExceptions, Hadoop Child Error messages, and freezes, along with steps to resolve them.