3 ms·
Arguably, with a data set of any serious magnitude, there's no such thing as ad-hoc. As soon as an RDBMS is sharded, it loses most of it's ad-hoc powers. That
by rbranson 15y ago
Arguably, with a data set of any serious magnitude, there's no such thing as ad-hoc. As soon as an RDBMS is sharded, it loses most of it's ad-hoc powers.
That being said, Riak Search allows Riak to perform ad-hoc queries and Cassandra now supports secondary indices along with a SQL-like query language called CQL. Of course, you'll have to pre-plan your indexes with either of those options.
- schmichael 15y ago"As soon as an RDBMS is sharded, it loses most of it's ad-hoc powers." That's an overly broad statement I would avoid. We only need to query across our various PostgreSQL partitions for offline batch operations. Our application code has yet to feel restricted by the manual sharding. Secondary indexes - or rather: not restricting a query to a single partition (using your primary key) - is going to be expensive in any distributed system.
- rbranson 15y agoYou lose aggregates and joins, arguably the most powerful parts of an ad-hoc query system (business intelligence kind of stuff). Without those features, you must move a great deal of these concerns into the application layer (or whatever manage your shards), even if it's just rolling up aggregates across shards. This works, but again, at the loss of the real advantages of the database here as you've got to do it yourself. I agree with your second assertion. Secondary indexes should be avoided, but are a useful tool if absolutely needed. I've found that Cassandra's richer data model really allows them to be avoided in most scenarios.
- jbellis 15y agoCassandra's CREATE INDEX will happily run in the background against existing data. Without blocking other reads or writes, of course.