In case you haven’t heard, ScyllaDB recently launched a new community forum where our users can connect and learn from one another’s experiences. It’s a great place to:
- Get quick access to the most common getting started questions
- Troubleshoot any issues you come across
- Engage in in-depth discussions about new features, configuration tradeoffs, and deployment options
- Search the archives to see how your peers are setting up similar integrations (e.g., ScyllaDB + JanusGraph + Tinkerpop)
- Propose a new topic for us to cover in ScyllaDB University
- Share your perspective on a ScyllaDB blog, ask questions about on-demand videos, or tell us more about what types of resources your team is looking for
- Engage with the community, share how you’re using ScyllaDB, what you learned along the way, and get ideas from your peers
Say hello & share how you’re using ScyllaDB
When Should You Use The Forum And When Should You Use Slack?
The forum is better for deeper technical issues and long-form articles. Its discussions are searchable and last forever.
Slack is better for short, quick answers and real-time chat interactions. If the question would benefit other community members over time, it’s better to ask on the forum. If you prefer to chat directly with peers and experts, or have a real-time discussion, Slack is the best option. You’re encouraged to look for the answer on the forum before posting a new question.
Behavior Guidelines and Best Practices
We emphasize the importance of respectful communication and consideration for others. Harassment of any kind is strictly prohibited, and participants are encouraged to report any misconduct immediately. Some best practices include:
- Be respectful
- Communicate and collaborate
- Be kind
- Report any misconduct
The forum is a resource for community members to help each other. While ScyllaDB employees may participate and offer their insights, they are not obligated to do so.
Recent Trending Discussions on the Community Forum
Here’s a look at some of the forum’s recent trending discussions.
Is ScyllaDB Right for My Application? ScyllaDB’s Sweet Spot
Discussion recap: ScyllaDB is a NoSQL database that is designed to handle large amounts of data and high throughput. The sweet spot for using ScyllaDB is when an application requires low latency, high availability, and the ability to handle large amounts of data. ScyllaDB is particularly useful for applications that require real-time analytics, fast data ingestion, and low-latency queries.
The post provides examples of use cases where ScyllaDB is a good fit, such as online gaming, AdTech, and financial services. However, the post also notes that ScyllaDB might not be the best choice for applications that require strong consistency (ACID) or have low data volumes.
Replication Strategy Change from Simple to Network
Discussion recap: Discusses the process of changing the replication strategy of a ScyllaDB cluster from SimpleStrategy to NetworkTopologyStrategy. It explains the benefits of using NetworkTopologyStrategy for more complex deployments and provides step-by-step instructions for making the switch. The discussion also highlights potential issues that might arise during the migration process and provides recommendations for avoiding them.
Knowing ScyllaDB Data Modeling and Limitations: data per row, number of index columns per table, consistency.
Discussion recap: The article explores some of the data modeling recommendations for working with ScyllaDB. The recommendations discussed include the use of Materialized Views, Indexing, the need for careful tuning of compaction and repair processes, the impact of large partitions on performance, and the challenges of scaling write-heavy workloads. It suggests using denormalization and careful monitoring of the repair process to optimize performance, and considering data modeling changes to reduce the impact of large partitions. Additionally, it suggests using asynchronous writes and optimizing the write path for write-heavy workloads. Finally, it suggests evaluating the trade-offs between data consistency and availability when designing a ScyllaDB deployment.
What table options should be used for fast writes & reads and no deletes
Discussion recap: This thread covers ScyllaDB options that can be used to optimize performance for the above use case (fast writes…). Using the TimeWindowCompaction strategy instead of dropping and creating the table with a TTL of X days ensures that tombstones won’t be an issue. ScyllaDB will effectively throw them away (thanks to TTL and windows). If there are no updates and deletes, then this is a perfect TTL + TWCS situation, assuming you really want to drop all your data older than 2 days.
Is there an API for ScyllaDB Nodetool?
Discussion recap: The ScyllaDB server indeed has a REST API. You can find a Swagger UI when you start the ScyllaDB server as well: https://docs.scylladb.com/operating-scylla/rest/
But, please note that nodetool, for example, does not use the API directly. Instead, it talks to the ScyllaDB JMX proxy, which is a Java process that implements Cassandra-compatible JMX API. You can still use the REST API directly, but you have to figure out the mapping between the JMX operations and the REST API yourself.