Preferred client ?

[ddorian]

Seems like you guys will support redis + cassandra + postgresql. While this is nice, do you have in mind a library to handle all features of the db ?(not talking about a separate one).

Simplest case: While pg-client can support ~all features (since you throw everything in a query), it can't (automatically) remove the 1-hop that cql-client does by keeping a hash-token-map on the client and thus talking to the primary/secondary directly.

Makes sense ?

[rkarthik007]

Hi @ddorian,

Yes, completely makes sense - thanks for the insightful question! And yes this is exactly the direction we are heading towards. I have added what we are up to in the context of each of these language APIs:

1. Enhance CQL to get on par with SQL

This is going to be available the soonest. We have already done a number of enhancements in this direction, and are planning on adding many more:

• Added multi-row transactions support (https://docs.yugabyte.com/explore/transactions/)
• Currently work is in progress for supporting consistent secondary indexes on CQL
• Enhanced the INT data type to be able to perform increments and decrements (CQL does not allow this)
• Support flexible number of tablets/partitions per table (like HBase - with Cassandra I believe this cannot be controlled at a per-table level but more at a per-cluster level).
• Support efficient (HBase style) table level TTLs as opposed to writing the TTL with each key-value

We already support a huge array of features such as batch inserts, IN clauses in queries, prepare-bind, user defined types, TTL, Spark adapters, reads from followers and nearby datacenters, etc. Additionally, yugabyte cassandra driver is locality aware, can recognize node additions and removals.

We feel this is the fastest path to production, because the ecosystem and language enhancements are already built around scale-out and clustering.

2. Enhance Postgres to be scale out

For postgres to understand scale-out, we need two layers of enhancements:

• Enhance the language to support sharding and efficient placement of data (like partitioning and clustering columns in Cassandra). This not actively on our roadmap right now (cassandra maybe a better path for this), but this is something we will consider once we have good coverage of the Postgres language. Since we would have built a lot of the core features for supporting SQL as we extend Cassandra to support general SQL, wiring this functionality to the Postgres driver/language would not be too much work.
• Enhance the ecosystem around postgres to support multiple nodes, etc as you had mentioned. This is something that we would work on once we have a functional set of postgres commands supported.

Note that we are currently working on Postgres support. It should be out in a few weeks, and is going to start with supporting basic commands. We will then extend the query set to make it functional.

3. Enhance Redis as a DB

We already support one-hop location of the data using our version of the Redis client. We are planning to add reads from followers and the nearest datacenter (we call this "tunable reads"). Note that while we have not started working on tunable reads for Redis, this is very much in our roadmap for the near future.

Summary

Since our Cassandra client/ecosystem is pretty mature, would you consider using that as a path for some of the more advanced queries? Would love to hear if you had some queries/usecase in mind which could get you started - we always love to prioritize those higher.

[ddorian]

thanks, cql is best supported