Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First, I don't think is correct.</p> <blockquote> <p>I know with earlier versions of Cassandra wide rows were de rigueur, but CQL seems to encourage us to move away from that.</p> </blockquote> <p>Wide rows are supported and well. There's a post from Jonathan Ellis <a href="http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows" rel="nofollow">Does CQL support dynamic columns / wide rows?</a>:</p> <blockquote> <p>A common misunderstanding is that CQL does not support dynamic columns or wide rows. On the contrary, CQL was designed to support everything you can do with the Thrift model, but make it easier and more accessible.</p> </blockquote> <p>For the part about the "performance impact of storing potentially billions of rows" I think the important part to keep in mind is the size of these rows.</p> <p>According to Aaron Morton in this <a href="http://markmail.org/message/62f4zemc6l7kkxys?q=Exactly+one+wide+row+per+node+for+a+given+CF%3F" rel="nofollow">mail thread</a>:</p> <blockquote> <p>When rows get above a few 10’s of MB things can slow down, when they get above 50 MB they can be a pain, when they get above 100MB it’s a warning sign. And when they get above 1GB, well you you don’t want to know what happens then. </p> </blockquote> <p>and later:</p> <blockquote> <p>Larger rows take longer to go through compaction, tend to cause more JVM GC and have issue during repair. See the in_memory_compaction_limit_in_mb comments in the yaml file. During repair we detect differences in ranges of rows and stream them between the nodes. If you have wide rows and a single column is our of sync we will create a new copy of that row on the node, which must then be compacted. I’ve seen the load on nodes with very wide rows go down by 150GB just by reducing the compaction settings. </p> <p>IMHO all things been equal rows in the few 10’s of MB work better. </p> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. POCassandra 2.0.2 CQL Long Row Limitation / Performance Impact
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USAlex Popescu
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for your answer Alex, actually I think I might have worded my question badly. I'm mostly concerned about whether there are performance impacts of have potentially billions of rows in a CQL table, rather than the size of the row.
      singulars
      1. PO
      1. USDerek Troy-West
    2. COBillions of rows in a table or billions of columns in a table?
      singulars
      1. PO
      1. USAlex Popescu
    3. COBillions of rows in a table, I'll edit the question.
      singulars
      1. PO
      1. USDerek Troy-West
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload