Hacker News Reader

Comment by threeseed | Hacker News Reader

Cassandra's transaction support has been improving pretty rapidly.

http://www.datastax.com/dev/blog/lightweight-transactions-in...

For what I can only guess are strategic reasons, Datastax is moving away from the schema-less design that made Cassandra popular with early adopters. There are workarounds to this deprecation such as using the old Thrift API, but it doesn't really inspire confidence in the product unless the new schema oriented way of doing things appeals to you. PS those aren't transactions.

"Schema-less" is a hack that appeals to people that don't realize that there is always schema. It's just a question of whether you want your data model to be ambiguous and poorly defined, or explicit.

Schema-less also means that you can afford to have deviations in your schemas not hinder your development needs. I agree with you, but I'd venture to say that a schema-less database means what it does, but that a collection of data always has schemas.

No, the schema is always a property of the system as a whole, data alone doesn't have an implicit schema. The schema is the set of type constraints that data has to conform to so that it can be processed by the system. Thus, a DB being "schema-less" simply means that it won't check/enforce those constraints - the schema still is there, of course, simply because a given piece of software that does anything meaningful will not sensibly process any random piece of garbage you feed it.

So no schema means no validation of data for conformance? I thought these "NoSQL", or rather the ones that explicitly state to be schema-less don't do such. People who take the lack of schema as the licence to throw data into a black hole are somehow misleading themselves. The purpose of a database is to store data for later retrieval and modification. Schema-less, as we both understand it, means there is little or no validation by the database. In light of what you corrected me on data, am I correct in saying that useful data at the very least has to conform to some uniformity, from which a DBA would derive a schema, even if not enforced by the database?

Yeah, that's what I meant by "the schema is still there" - "useful data" is data that has meaning according to how the system (software processing the data) interprets it. But my point is that the uniformity can not be derived from the data, but only from the interpretation rules of the software.

I mean, you can, of course, derive some "rules of uniformity" from the data, but that most likely would be completely useless, as you might just find patterns in the data that emerged by chance rather than because they distinguish meaningful data from nonsense, and you might easily miss important constraints that are required to keep nonsense out of the database. Of course, sometimes you can infer from data heuristically what sensible constraints might look like (because field names have some meaning to you, for example), but that really is just a heuristic shortcut for finding out how the system interprets the data.

We aren't all building cat photo sharing apps.

Sparse columns dbs (AKA schema-less in Cassandra lingo) have all sorts of important use cases in the sciences, unless you feel like paging through 100,000+ empty columns to find or discard the information you need or don't need.

The alternative approach is to alter your table's schema every time you find a new sub characteristic of how a given system is expressing itself.

Cassandra didn't actually get rid of the schemaless structure, and you can still use it. All the introduction of CQL did was make some assumptions on the storage format, based on common use cases, and essentially hid the underlying format for you.

If you read up on CQL3, you will see the schema-less trait is still there, and just as performant, but only slightly confusing if you come from the SQL world.

In a way, CQL3 is a "hack" to make a schema-less database look like it enforces a schema. The Primary Key became the Row Key, the secondary key became the cell name, and the value became all the other fields. The column names are still dynamic, and the schema doesn't really exist on disc except in metadata.

> The alternative approach is to alter your table's schema every time you find a new sub characteristic of how a given system is expressing itself.

Which is what you're doing regardless.

Untyped is just a sum type.

This is not true. See this for example: http://www.datastax.com/dev/blog/thrift-to-cql3

You can do CREATE TABLE schemaless (id blob, name blob, value blob, PRIMARY KEY (id, name)) WITH COMPACT STORAGE; and have a 'schemaless' table, essenitally, just as with Thrift.

This is not a workaround either - this is first-class supported, just as you can read/write from/to 'schemaless' thrift columnfamilies using CQL.

Sure, would you mind showing me how to use CQL to insert data into an old-school style Column Family that was created with the Thrift interface? Linus Torvalds would be up in arms if he saw this kind of client facing API breakage.

CQL is compatible with Thrift-created column families (the inverse is not true, though). Just do a DESCRIBE SCHEMA from cqlsh and see how CQL interprets a particular Thrift-created column family, then use regular INSERTs.

Reply on news.ycombinator.com