Live data from Hacker News

NoSQL Meets Bitcoin and Brings Down Two Exchanges

hackingdistributed.com

61–69 of 69 posts

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#61
post #22

It's the same story over and over again. The young wild guys arrive, full of energy and ambition to make the world a better place. They throw all the ancient stuff overboard because it seems ugly and useless. Then they painfully rediscover why the ugly stuff is there and not useless at all. And after a lot of pain they finally arrive at a slightly improved version of what they threw overboard long ago, at least if th…

> The young wild guys arrive

That's exactly the problem. The 20-something hipsters who start these companies don't yet have the life experience to realize how ignorant they are. So of course they don't pay any attention to the lessons of history. And so they, very painfully, re-learn them.

If the hipsters had some humility they would have also hired a few grizzled, experienced old fogies.

Fortunately not all startups assume that anyone over the age of 30 isn't worth hiring. For a non-technical example, look at how Google hired Eric Schmidt to provide adult supervision.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#62

Earlier quoted context omitted.

"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.

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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#63

Earlier quoted context omitted.

"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.

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…

> 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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#64
post #48

Earlier quoted context omitted.

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…

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?

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#65
post #64

Earlier quoted context omitted.

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…

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 n…

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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#66

As soon as I saw the term NoSQL and "Brings Down" in the title of the submission, I knew it was going to be MongoDB. Firstly, I don't understand the hatred towards MongoDB. Like most NoSQL datastores, it doesn't offer things like transactions and ACID compliance: this is well-known thing. There are some things that MongoDB does very well, currently I am using it to store clicks for an internal application which then…

> it doesn't offer things like transactions and ACID compliance: this is well-known thing

Evidently not. Which is why people are still using it for financial based systems.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#68

Earlier quoted context omitted.

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.

Re: NoSQL Meets Bitcoin and Brings Down Two Exchanges

#69

As soon as I saw the term NoSQL and "Brings Down" in the title of the submission, I knew it was going to be MongoDB. Firstly, I don't understand the hatred towards MongoDB. Like most NoSQL datastores, it doesn't offer things like transactions and ACID compliance: this is well-known thing. There are some things that MongoDB does very well, currently I am using it to store clicks for an internal application which then…

> the stupidity of the developers behind said exchanges are the sole reason

Exactly. The fact that they picked MongoDB for this application in the first place tells me that even if they used an ACID-compliant database, they still wouldn't have known to use transactions, and would be vulnerable to the same attack.

Post reply on HN