Yugabyte University is releasing a new self-paced course, YugabyteDB YCQL Development. Watch informative course videos and complete hands-on lab exercises to learn the fundamentals of YCQL and dive deep into the internals of YugabyteDB.
YugabyteDB is built primarily to be a CP database per the CAP theorem. It supports two interfaces – YSQL for SQL workloads and YCQL for Cassandra-like workloads. In this blog, we will primarily talk about the YCQL interface. When an application interacts with the database using the YCQL interface, the writes are always consistent and reads are consistent by default. When this level of consistency is not required, YugabyteDB supports two other types of reads:
Developers and DBAs widely use SQL editors to design database schemas, write ad hoc queries, troubleshoot, and manage the security policies and database users. For these reasons, it is essential for us as builders of YugabyteDB to bring native integration with popular database tools like DBeaver.
If you are following the YugabyteDB project and our blog posts, you’ll know YugabyteDB currently supports two APIs – YSQL and YCQL (NoSQL) – for querying the database.
YugabyteDB has a great feature in strongly consistent secondary indexes. I have been asked a few times now about how to modify existing indexes. These can range from adding another column to the index or adding another column to the INCLUDE clause. The big question at the end of the day is: how to do this without having to take downtime on the indexes? In this blog post, using the Yugabyte CQL API we will look at how to switch a live running application from using one index to another without a performance hit during the transition,