Justifiable protest would include such simple things as writing and signing petitions, voting in elections, and contacting representatives. Each of those comes with a name and a reputation attached. On the more disruptive side of the scale, we have things like sit-ins and picketing, which usually involve breaking a particular establishment's rules, but no governmental laws.
Blowing up a brick-and-mortar store because they don't sell your favorite brand of toothpaste is not a justifiable protest. It's a crime. No matter how much publicity it generates, a large proportion of the discussion will revolve around the crime, not the vital toothpaste issue.
Likewise, anyone wanting to protest the persecution of Wikileaks has other avenues to pursue. At minimum, there are petitions to sign, representatives to contact, and public venues at which to speak. If someone really cares enough, they could donate funds to Julian Assange's defense directly, or simply follow the parade of companies that still support Wikileaks. There is no need to resort to brutal attacks against companies, and certainly no justification for calling such immaturity a legitimate protest.
Sorry to disrupt your tinfoil hat, but my objections have nothing to do with this being about Wikileaks. I guess I'm just so "demonic" that I enjoy having peaceful options for protest, and expect others to follow them.
Don't worry... we'll get just as upset if the police make false claims about the fallibility of their methods, arrest people who never had LOIC on their computers, arrest hundreds of people based on the same evidence, or start extorting settlements under the threat of an expensive court case with flimsy evidence.
Perhaps with enough publicity from this case, the "members" of Anonymous will realize that throwing a tantrum is not useful activism. Unfortunately, it's more likely that the various police involved will be targeted next, along with their supporters, families, and barbers.
How about the team of fully-qualified engineers designing the system? Or perhaps the analysts who examine the results of crash tests before it's ever released as a consumer vehicle? If they say it's safe, will you take their word for it, or rely on the advice of a dozen Slashdot residents?
In an accident, it will remain intact. If not, then the car won't pass standard safety tests, and the manufacturer knows it won't sell. In the event that some freak crushing blow strikes the tank (like, for example, getting caught between a freight train and a reinforced bunker, or perhaps dropped from an airplane) It'll most likely burst open at the one spot that the engineers intentionally design to be slightly weaker than the rest of the case, which conveniently releases the contained gas in a harmless direction.
5000 PSI is like having an average American car, including all passengers, with all its weight sitting on a single square inch. That's the maximum operating pressure, implying that the tank itself will actually hold significantly more pressure before having any problems. I feel pretty confident that the engineers involved know what they're doing, and can prevent catastrophic failure during a collision.
Given that I can't find any actual address involving anything remotely like that, I'll say yes. The thing I could find was a quote of "goddamned piece of paper", but I'm not the only one to miss that.
The simplistic refutation of this simplistic refutation is: Because my neighbors aren't cops.
More precisely, it's because my neighbors are not officers duly authorized by me (via my citizenship) to observe my behavior looking for violations of the laws I have also authorized.
It's not the observation that's the problem. Real problems are infringements on things like freedom of speech, freedom of religion, unreasonable search and seizure... you know, all those things that are granted in the Constitution.
It's not unreasonable for police to look for people breaking the law. It's their job. Why should they be prevented from looking at an area from any particular angle? If you really want to hide something, make sure it stays in a room without transparent windows. The police need to have clear evidence of wrongdoing before they can get a search warrant. If you're storing a pile of explosives in your backyard, expect a search warrant. You're stockpiling explosives, which is usually illegal. Does it really matter that the police saw the pile from the air, rather than through a knothole in the fence?
Unreasonable searches are ones that are without a good reason. That's what's worth fighting against. If a search warrant is issued based on "This guy is has a room we can't see into," fight it. Fight the search warrant, fight any evidence found in that room, and absolutely vote against any judge to approve such a thing. Likewise, fight against any legislation banning things you want to have, and encourage others (especially your representatives) to do the same.
To put things in simple terms: Make sure that whatever you're doing is not considered wrong.
Not only grow them, but get rid of 'em, too. The ludicrous 18-button mouse is always an 18-button mouse, whether it makes sense for the current application or not.
Apple's input devices have had "two buttons" for a long time. Click with one finger, and it's button 1 (left, usually). Use two fingers, and it's button 2 (right, usually). The Magic Mouse adds multi-touch gestures, but as I've never used it I don't know exactly what they are.
Apple's goal has (almost) always been to use the latest technology to have a simple design provide the most functionality possible. Take a look at the Magic Trackpad. It's a metal slab. No markings, no (visible) buttons, and yet it's a fully-functional multi-touch input device. The folks I know who've used it prefer its abilities over a mouse.
This latest patent is just an extension of the "more function" goal. Typically, assigning functions to buttons is either done by the user, tediously by hand, or by the application with a faint hope that the user figures out what to do. With a display on the mouse, automatically-changing functions can be shown visually. That means more dynamic functions, less user confusion, and a clean appearance. It sounds good to me.
I expect it'd work just like the Magic Mouse does already. If you're doing something recognized as a gesture, and not touching anywhere else, then it's assumed to be a gesture. Otherwise, if you're touching places that don't make sense, it's assumed that you're just holding the mouse.
My grandmother looks at her mouse all the time, because she still hasn't quite figured out where everything is.
That's how I see this: Sure, it'll take a bit of time to adjust to, but just like learning keyboard hotkeys, each application's function can be picked up fairly quickly. After that, you can return to ignoring your mouse.
This interests me greatly. Think of how many games have a "left to select, right do do whatever seems more or less appropriate at the time" dynamic, and consider what they'd be able to do if your mouse could reconfigure itself on the fly. Some other ideas off the top of my head:
Games: Pick up an item, and gain new abilities that weren't even alluded to before. Old abilities are still equally accessible with the same gestures.
Emulators: Emulate a handheld controller.
Word processing: Convert almost the whole mouse to a small representation of the document. Touch any point on the mouse, and appear right at that place in the document.
OS interface: Common applications can be launched with a touch (probably multifinger), supplanting or augmenting the OS X dock.
Multimedia: A bluetooth mouse is now a fully-functional remote control.
General: Add buttons for common actions at will.
This could turn into something very good indeed. Of course, it'll cost $69 at an Apple store, and come in a lovely shade of white or aluminum, but the potential is huge.
Re:Some weasel of a tech is now shitting his pants
on
DSL Installation Fail
·
· Score: 1
Sounds good to me, but instead of clubs let's use legislation.
The installation company is almost definitely going to be the one paying for repairs. Having poor standards doesn't make sense for them. It looks more that it's just a bad technician who, in the words of the original poster, should update his resume.
Re:Some weasel of a tech is now shitting his pants
on
DSL Installation Fail
·
· Score: 1
Personally, no. I did work in the same building as union members (who had a completely different job), and watched the madness from a safe distance.
One particular employee actually made his workstation explode. Ignoring all the logs showing the machine was maintained and the employee had screwed up before, the union still required further proof that it was his fault before he could be fired. It took almost a full month to show that the cause of damage was indeed operator error, during which time the company still had to pay him, but nobody with any sense would let him near a functioning machine.
Then there's the teachers' union at a high school near my hometown, who fought for raises for teachers, despite rising dropout rates, failing state-mandated tests, and the district already falling into insolvency. An agreement was only reached after the state took over managing the city's finances, and it involved canceling a significant portion of the school's programs.
Then there's the musicians' union on Broadway, which specifies the minimum number of musicians employed at each theatre, with little concern for whether they're actually needed. According to an actor I once met, a pianist played on Broadway and, per the terms of the union agreement, had his required musicians up on stage, in full formal dress, simply holding their instruments while he played. At one point between pieces he stood up, pointed to the seated and useless musicians, and introduced them: "Ladies and gentlemen, your union-mandated orchestra!"
I'm sure there are decent unions out there somewhere, with efficient management and fair practices. I have yet to encounter any, so you'll have to forgive my opinion based on experience.
Re:Some weasel of a tech is now shitting his pants
on
DSL Installation Fail
·
· Score: 3, Insightful
Without union protection, the installer responsible can be fired immediately, without the company having to provide fully-documented proof of how many different ways this is wrong.
Unions don't protect customers. Unions protect unions at all costs.
Except that despite budget cuts, cancelled programs, and a general lack of progress, NASA is still one of the most impressive things the US has. We put a man on the moon, damnit! Fifty years ago, sure, but we did it. There are billions of people paying attention to everything NASA does. One little defect in the right part at the right time, and the USA gets an internationally-visible slap in the face. That's an interesting prospect for hostile nations to consider. Plant an operative in the right company, and that right part can have its defect right on schedule.
It's a slight abuse, yes. My understanding is that the table is split first by by column family, then by partition as needed. That makes it more a column store than anything else I can think of offhand.
Regardless of the slaughter of language, I think the point's still clear: Cassandra is a different beast from a traditional database.
That's not to say I actually disagree. It's very likely that I'm misunderstanding how Cassandra in particular works. I worked through the BigTable paper and I've used HBase extensively. My personal experience with Cassandra is setting up a small system and running enough of a test to see that it wasn't suitable for my needs. Any further knowledge is appreciated.
Close. It's more of a hash table of a sorted hash table... Columns are unsorted, but rows are (I think... I've only used HBase personally).
If you know what you'll be looking for ahead of time, you can make your life easy with a write-heavy system. What's missing in standard Cassandra is a way to run ad-hoc queries. My understanding is that Cassandra can now run with Hadoop's MapReduce framework. Any query or computation can be run against the Cassandra table in a widely-distributed fashion as a MapReduce job. It's not as fast as an SQL query on an indexed column, but far better than a query on an unindexed one, because everything runs in parallel across the cluster.
A dynamic table name leads to all kinds of trouble for an RDBMS. A closer analogue would be to partition the giant table by date, but even then there are some applications that end up with huge amounts of data in one partition. Cassandra can split by column family, as well as by sections of rows. Since the row partitioning is done automatically (in a "don't worry about it" fashion), there's seldom a painful amount of data in one place.
That's the point of this story: The maximum column count (which would require manual partitioning) has just risen above any reasonable limits. Big Data can be even bigger.
Welcome to the first five minutes of using a column store. Screwey, ain't it?
My understanding is that rows' contents are indexed such that they may be retrieved quickly. Think of a row name as a primary key. It's easy to get the whole row when you know its name. Continuing the census application, it's be like asking for all the birth years of everyone in a geographical region. The requested column family (geographical region) is opened, and each column (person) is quickly checked for the particular row's contents (in case the birth year wasn't provided). Partitioning is done by both row and column family, so only some of the column family's data is actually scanned. That's where the cluster provides a very nice speedup, as well.
locating a value in a specific row can't tell how to retrieve that entire column
Now, I'm not sure if I understand your rage-induced rambling correctly, but if you're trying to make a SQL example, you're starting from the wrong premise, which explains why you're having trouble making sense of it all.
Quick review: The "R" in "RDBMS" stands for "relational", referring to a n-ary relation. SQL is intended to manipulate those relations, isolating the data you want to extract. Something that is not described as an RDBMS should not be expected to have relations.
Cassandra functions (from the application perspective) as a key-value store, with no relation structure. That means you don't work with sets, and you don't need to think about set operations. Pull out a row, and you get a list of columns with defined values, as well as those values. Iterate through each value looking for whatever value you're looking for. When you find it, you already have the column name. Just ask for the whole column next. Since the whole thing is running in a cluster, you can parallelize the iterations (I think... I've used HBase, but not Cassandra personally) to speed up the scan.
If that's not fast enough for you (which is likely), you can use Hadoop's MapReduce framework to scan each cell and create an index, possibly laid over the other table as just more rows & columns (though a different table would be better, from a sanity perspective). Since there's no mandatory structure, that's legit.
Of course, that's only valid for this particular census application, which assumes that the only reason for the database is either basic statistics or something complex enough for a MapReduce program.
It's entirely possible to run Cassandra arranged similar to a normal RDBMS. Use only a few column families with very specific columns (such as a single family for all the "Name, address, etc."). Throw in a bunch of index families, updated with MapReduce. Then, your processing can be a complex MapReduce job, iterating over each row with a particular set of rows meeting all your needed criteria. It'd be just like a normal RDBMS, except you have better scalability, and maintain indexes yourself.
If the trouble of indexing is too much for you, you can follow Google's route with Colossus, which runs MapReduce-like tasks when rows are changed. That's your dynamic indexing.
Why not, if you expect to have several billion posts?
The more important issue in this architecture decision would be scaling needs and abilities. How many billion rows can a typical RDBMS handle on a $20,000 budget? If that budget goes to $40,000, will that capacity double? With a column-oriented database, only the needed column families are loaded into memory. For this forum example, you could have a family for each month of operation. Old threads would then be entirely in old column families, so they would remain untouched on disk, never even read until they're needed. The lower memory use leads to less expensive servers (since storage is cheap now), and linear scaling.
If your application doesn't need ridiculously large storage, go ahead and use a plain old RDBMS, just so you can avoid learning a new skill set. You're probably not going to hit a meaningful limit. If you're looking at a huge amount of data, or a moderate amount of data with a lot of processing, newer technology may be a better choice.
Cassandra can also run with Hadoop's MapReduce framework. Taking the forum example further, a periodic job could process all the posts, updating another table (or set of columns) with a map of keywords to posts that contain them. Scanning one thread at a time, each node in the Hadoop cluster could compute the index in parallel, allowing the index creation to be separated from the load of making a post. Again, it's not a big deal for a small application, but when you're dealing with something scaling up to the size of Facebook, StumbleUpon, or Google, new tools with new designs just work better.
I don't know if that was sarcastic or not, but given that Cassandra is column-oriented, that's pretty much right (not so much with the header, but metadata is likely). Use a column family for each region, and you can process statistics in small chunks without a ridiculously-overpowered server. Only the requested column families need to be loaded into memory for processing.
Disclaimer: I haven't used Cassandra personally, but I have used HBase which operates similarly.
Cassandra uses column families, which are groups of columns, and are individually selectable. If all families contain the same columns, you have 3D (family, column, row) storage! Now, with HBase, excessive column family creation and maintenance isn't the ideal route, but if you actually need 3D storage, it would work pretty decently.
Cassandra, BigTable, and HBase are designed for applications that need lots of rarely-accessed details, for relatively few rows. As an example, let's consider a forum. One row per thread, one column per post. A single query (usually in a manner not related to SQL) pulls out a single row, and all the columns associated with it. Since columns are created by the application at runtime, 2 billion isn't that excessive, but it is worth bragging about.
Slashdot Mirror
Alright, "dood".
Justifiable protest would include such simple things as writing and signing petitions, voting in elections, and contacting representatives. Each of those comes with a name and a reputation attached. On the more disruptive side of the scale, we have things like sit-ins and picketing, which usually involve breaking a particular establishment's rules, but no governmental laws.
Blowing up a brick-and-mortar store because they don't sell your favorite brand of toothpaste is not a justifiable protest. It's a crime. No matter how much publicity it generates, a large proportion of the discussion will revolve around the crime, not the vital toothpaste issue.
Likewise, anyone wanting to protest the persecution of Wikileaks has other avenues to pursue. At minimum, there are petitions to sign, representatives to contact, and public venues at which to speak. If someone really cares enough, they could donate funds to Julian Assange's defense directly, or simply follow the parade of companies that still support Wikileaks. There is no need to resort to brutal attacks against companies, and certainly no justification for calling such immaturity a legitimate protest.
Sorry to disrupt your tinfoil hat, but my objections have nothing to do with this being about Wikileaks. I guess I'm just so "demonic" that I enjoy having peaceful options for protest, and expect others to follow them.
Don't worry... we'll get just as upset if the police make false claims about the fallibility of their methods, arrest people who never had LOIC on their computers, arrest hundreds of people based on the same evidence, or start extorting settlements under the threat of an expensive court case with flimsy evidence.
Perhaps with enough publicity from this case, the "members" of Anonymous will realize that throwing a tantrum is not useful activism. Unfortunately, it's more likely that the various police involved will be targeted next, along with their supporters, families, and barbers.
How about the team of fully-qualified engineers designing the system? Or perhaps the analysts who examine the results of crash tests before it's ever released as a consumer vehicle? If they say it's safe, will you take their word for it, or rely on the advice of a dozen Slashdot residents?
In an accident, it will remain intact. If not, then the car won't pass standard safety tests, and the manufacturer knows it won't sell. In the event that some freak crushing blow strikes the tank (like, for example, getting caught between a freight train and a reinforced bunker, or perhaps dropped from an airplane) It'll most likely burst open at the one spot that the engineers intentionally design to be slightly weaker than the rest of the case, which conveniently releases the contained gas in a harmless direction.
5000 PSI is like having an average American car, including all passengers, with all its weight sitting on a single square inch. That's the maximum operating pressure, implying that the tank itself will actually hold significantly more pressure before having any problems. I feel pretty confident that the engineers involved know what they're doing, and can prevent catastrophic failure during a collision.
Given that I can't find any actual address involving anything remotely like that, I'll say yes. The thing I could find was a quote of "goddamned piece of paper", but I'm not the only one to miss that.
The simplistic refutation of this simplistic refutation is: Because my neighbors aren't cops.
More precisely, it's because my neighbors are not officers duly authorized by me (via my citizenship) to observe my behavior looking for violations of the laws I have also authorized.
It's not the observation that's the problem. Real problems are infringements on things like freedom of speech, freedom of religion, unreasonable search and seizure... you know, all those things that are granted in the Constitution.
It's not unreasonable for police to look for people breaking the law. It's their job. Why should they be prevented from looking at an area from any particular angle? If you really want to hide something, make sure it stays in a room without transparent windows. The police need to have clear evidence of wrongdoing before they can get a search warrant. If you're storing a pile of explosives in your backyard, expect a search warrant. You're stockpiling explosives, which is usually illegal. Does it really matter that the police saw the pile from the air, rather than through a knothole in the fence?
Unreasonable searches are ones that are without a good reason. That's what's worth fighting against. If a search warrant is issued based on "This guy is has a room we can't see into," fight it. Fight the search warrant, fight any evidence found in that room, and absolutely vote against any judge to approve such a thing. Likewise, fight against any legislation banning things you want to have, and encourage others (especially your representatives) to do the same.
To put things in simple terms: Make sure that whatever you're doing is not considered wrong.
Not only grow them, but get rid of 'em, too. The ludicrous 18-button mouse is always an 18-button mouse, whether it makes sense for the current application or not.
Apple's input devices have had "two buttons" for a long time. Click with one finger, and it's button 1 (left, usually). Use two fingers, and it's button 2 (right, usually). The Magic Mouse adds multi-touch gestures, but as I've never used it I don't know exactly what they are.
Apple's goal has (almost) always been to use the latest technology to have a simple design provide the most functionality possible. Take a look at the Magic Trackpad. It's a metal slab. No markings, no (visible) buttons, and yet it's a fully-functional multi-touch input device. The folks I know who've used it prefer its abilities over a mouse.
This latest patent is just an extension of the "more function" goal. Typically, assigning functions to buttons is either done by the user, tediously by hand, or by the application with a faint hope that the user figures out what to do. With a display on the mouse, automatically-changing functions can be shown visually. That means more dynamic functions, less user confusion, and a clean appearance. It sounds good to me.
I expect it'd work just like the Magic Mouse does already. If you're doing something recognized as a gesture, and not touching anywhere else, then it's assumed to be a gesture. Otherwise, if you're touching places that don't make sense, it's assumed that you're just holding the mouse.
My grandmother looks at her mouse all the time, because she still hasn't quite figured out where everything is.
That's how I see this: Sure, it'll take a bit of time to adjust to, but just like learning keyboard hotkeys, each application's function can be picked up fairly quickly. After that, you can return to ignoring your mouse.
This interests me greatly. Think of how many games have a "left to select, right do do whatever seems more or less appropriate at the time" dynamic, and consider what they'd be able to do if your mouse could reconfigure itself on the fly. Some other ideas off the top of my head:
This could turn into something very good indeed. Of course, it'll cost $69 at an Apple store, and come in a lovely shade of white or aluminum, but the potential is huge.
Sounds good to me, but instead of clubs let's use legislation.
The installation company is almost definitely going to be the one paying for repairs. Having poor standards doesn't make sense for them. It looks more that it's just a bad technician who, in the words of the original poster, should update his resume.
Personally, no. I did work in the same building as union members (who had a completely different job), and watched the madness from a safe distance.
One particular employee actually made his workstation explode. Ignoring all the logs showing the machine was maintained and the employee had screwed up before, the union still required further proof that it was his fault before he could be fired. It took almost a full month to show that the cause of damage was indeed operator error, during which time the company still had to pay him, but nobody with any sense would let him near a functioning machine.
Then there's the teachers' union at a high school near my hometown, who fought for raises for teachers, despite rising dropout rates, failing state-mandated tests, and the district already falling into insolvency. An agreement was only reached after the state took over managing the city's finances, and it involved canceling a significant portion of the school's programs.
Then there's the musicians' union on Broadway, which specifies the minimum number of musicians employed at each theatre, with little concern for whether they're actually needed. According to an actor I once met, a pianist played on Broadway and, per the terms of the union agreement, had his required musicians up on stage, in full formal dress, simply holding their instruments while he played. At one point between pieces he stood up, pointed to the seated and useless musicians, and introduced them: "Ladies and gentlemen, your union-mandated orchestra!"
I'm sure there are decent unions out there somewhere, with efficient management and fair practices. I have yet to encounter any, so you'll have to forgive my opinion based on experience.
Without union protection, the installer responsible can be fired immediately, without the company having to provide fully-documented proof of how many different ways this is wrong.
Unions don't protect customers. Unions protect unions at all costs.
Except that despite budget cuts, cancelled programs, and a general lack of progress, NASA is still one of the most impressive things the US has. We put a man on the moon, damnit! Fifty years ago, sure, but we did it. There are billions of people paying attention to everything NASA does. One little defect in the right part at the right time, and the USA gets an internationally-visible slap in the face. That's an interesting prospect for hostile nations to consider. Plant an operative in the right company, and that right part can have its defect right on schedule.
Think at 125% speed, and you can understand the man.
It's a slight abuse, yes. My understanding is that the table is split first by by column family, then by partition as needed. That makes it more a column store than anything else I can think of offhand.
Regardless of the slaughter of language, I think the point's still clear: Cassandra is a different beast from a traditional database.
That's not to say I actually disagree. It's very likely that I'm misunderstanding how Cassandra in particular works. I worked through the BigTable paper and I've used HBase extensively. My personal experience with Cassandra is setting up a small system and running enough of a test to see that it wasn't suitable for my needs. Any further knowledge is appreciated.
Not quite.
Close. It's more of a hash table of a sorted hash table... Columns are unsorted, but rows are (I think... I've only used HBase personally).
If you know what you'll be looking for ahead of time, you can make your life easy with a write-heavy system. What's missing in standard Cassandra is a way to run ad-hoc queries. My understanding is that Cassandra can now run with Hadoop's MapReduce framework. Any query or computation can be run against the Cassandra table in a widely-distributed fashion as a MapReduce job. It's not as fast as an SQL query on an indexed column, but far better than a query on an unindexed one, because everything runs in parallel across the cluster.
A dynamic table name leads to all kinds of trouble for an RDBMS. A closer analogue would be to partition the giant table by date, but even then there are some applications that end up with huge amounts of data in one partition. Cassandra can split by column family, as well as by sections of rows. Since the row partitioning is done automatically (in a "don't worry about it" fashion), there's seldom a painful amount of data in one place.
That's the point of this story: The maximum column count (which would require manual partitioning) has just risen above any reasonable limits. Big Data can be even bigger.
Welcome to the first five minutes of using a column store. Screwey, ain't it?
My understanding is that rows' contents are indexed such that they may be retrieved quickly. Think of a row name as a primary key. It's easy to get the whole row when you know its name. Continuing the census application, it's be like asking for all the birth years of everyone in a geographical region. The requested column family (geographical region) is opened, and each column (person) is quickly checked for the particular row's contents (in case the birth year wasn't provided). Partitioning is done by both row and column family, so only some of the column family's data is actually scanned. That's where the cluster provides a very nice speedup, as well.
locating a value in a specific row can't tell how to retrieve that entire column
Now, I'm not sure if I understand your rage-induced rambling correctly, but if you're trying to make a SQL example, you're starting from the wrong premise, which explains why you're having trouble making sense of it all.
Quick review: The "R" in "RDBMS" stands for "relational", referring to a n-ary relation. SQL is intended to manipulate those relations, isolating the data you want to extract. Something that is not described as an RDBMS should not be expected to have relations.
Cassandra functions (from the application perspective) as a key-value store, with no relation structure. That means you don't work with sets, and you don't need to think about set operations. Pull out a row, and you get a list of columns with defined values, as well as those values. Iterate through each value looking for whatever value you're looking for. When you find it, you already have the column name. Just ask for the whole column next. Since the whole thing is running in a cluster, you can parallelize the iterations (I think... I've used HBase, but not Cassandra personally) to speed up the scan.
If that's not fast enough for you (which is likely), you can use Hadoop's MapReduce framework to scan each cell and create an index, possibly laid over the other table as just more rows & columns (though a different table would be better, from a sanity perspective). Since there's no mandatory structure, that's legit.
Of course, that's only valid for this particular census application, which assumes that the only reason for the database is either basic statistics or something complex enough for a MapReduce program.
It's entirely possible to run Cassandra arranged similar to a normal RDBMS. Use only a few column families with very specific columns (such as a single family for all the "Name, address, etc."). Throw in a bunch of index families, updated with MapReduce. Then, your processing can be a complex MapReduce job, iterating over each row with a particular set of rows meeting all your needed criteria. It'd be just like a normal RDBMS, except you have better scalability, and maintain indexes yourself.
If the trouble of indexing is too much for you, you can follow Google's route with Colossus, which runs MapReduce-like tasks when rows are changed. That's your dynamic indexing.
Here's some links to help your understanding:
Why not, if you expect to have several billion posts?
The more important issue in this architecture decision would be scaling needs and abilities. How many billion rows can a typical RDBMS handle on a $20,000 budget? If that budget goes to $40,000, will that capacity double? With a column-oriented database, only the needed column families are loaded into memory. For this forum example, you could have a family for each month of operation. Old threads would then be entirely in old column families, so they would remain untouched on disk, never even read until they're needed. The lower memory use leads to less expensive servers (since storage is cheap now), and linear scaling.
If your application doesn't need ridiculously large storage, go ahead and use a plain old RDBMS, just so you can avoid learning a new skill set. You're probably not going to hit a meaningful limit. If you're looking at a huge amount of data, or a moderate amount of data with a lot of processing, newer technology may be a better choice.
Cassandra can also run with Hadoop's MapReduce framework. Taking the forum example further, a periodic job could process all the posts, updating another table (or set of columns) with a map of keywords to posts that contain them. Scanning one thread at a time, each node in the Hadoop cluster could compute the index in parallel, allowing the index creation to be separated from the load of making a post. Again, it's not a big deal for a small application, but when you're dealing with something scaling up to the size of Facebook, StumbleUpon, or Google, new tools with new designs just work better.
I don't know if that was sarcastic or not, but given that Cassandra is column-oriented, that's pretty much right (not so much with the header, but metadata is likely). Use a column family for each region, and you can process statistics in small chunks without a ridiculously-overpowered server. Only the requested column families need to be loaded into memory for processing.
Cassandra doesn't use SQL, and isn't even like a RDBMS in any way other than "it stores a table of data", so the SQL statement would be nonexistent.
Disclaimer: I haven't used Cassandra personally, but I have used HBase which operates similarly.
Cassandra uses column families, which are groups of columns, and are individually selectable. If all families contain the same columns, you have 3D (family, column, row) storage! Now, with HBase, excessive column family creation and maintenance isn't the ideal route, but if you actually need 3D storage, it would work pretty decently.
Cassandra, BigTable, and HBase are designed for applications that need lots of rarely-accessed details, for relatively few rows. As an example, let's consider a forum. One row per thread, one column per post. A single query (usually in a manner not related to SQL) pulls out a single row, and all the columns associated with it. Since columns are created by the application at runtime, 2 billion isn't that excessive, but it is worth bragging about.