zznate Software, Support, and Training for Apache Cassandra en-US Sat, 25 May 2013 06:12:30 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/nodes-were-unavailable/page/2#post-7242 Wed, 31 Oct 2012 00:09:58 +0000 rob4you 7242@http://www.datastax.com/support-forums/ <p>The problem doesn't seem to have been fixed.</p> <p>Look at this snippet:</p> <p>&gt; CREATE KEYSPACE a WITH strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' AND strategy_options:replication_factor='1';</p> <p>&gt; DESCRIBE KEYSPACE a;<br /> CREATE KEYSPACE a WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor='1';</p> <p>&gt; USE a;<br /> &gt; CREATE TABLE t (id int PRIMARY KEY, col1 text);</p> <p>&gt; SELECT * FROM t:<br /> Unable to complete request: one or more nodes were unavailable.</p> <p>&gt; SHOW VERSION;<br /> [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0]</p> <p>I'm using DSE, latest release. </p> http://www.datastax.com/support-forums/topic/nodes-were-unavailable/page/2#post-5799 Fri, 10 Aug 2012 19:11:28 +0000 thobbs 5799@http://www.datastax.com/support-forums/ <p>Thanks for the post! I sent a note to the docs team, so that should be fixed shortly. </p> http://www.datastax.com/support-forums/topic/nodes-were-unavailable/page/2#post-5688 Thu, 09 Aug 2012 17:48:53 +0000 tstarbow 5688@http://www.datastax.com/support-forums/ <p>It is pretty annoying that the "Getting Started Using the Cassandra CLI" for Cassandra 1.0 (<a href="http://www.datastax.com/docs/1.0/dml/using_cql" rel="nofollow">http://www.datastax.com/docs/1.0/dml/using_cql</a>) code doesn't work as written. It looks like it has been fixed on 1.1 docs:</p> <p>CREATE KEYSPACE twissandra<br /> WITH strategy_class = 'org.apache.cassandra.locator.SimpleStrategy'<br /> AND strategy_options:replication_factor='1'; </p> http://www.datastax.com/support-forums/topic/c-sharp-net-35-clients-for-cassandra-10x#post-3963 Fri, 27 Jul 2012 09:31:48 +0000 semoru 3963@http://www.datastax.com/support-forums/ <p>I've been recently involved within a project to connect Cassandra and VB.NET 3.5. We finally implemented it with cassandra-sharp.</p> <p>I made a tutorial in my blog</p> <p><a href="http://www.semoru.com/2012/07/27/how-to-connect-cassandra-and-net-framework-3-5/" rel="nofollow">http://www.semoru.com/2012/07/27/how-to-connect-cassandra-and-net-framework-3-5/</a></p> <p>hope it helps </p> http://www.datastax.com/support-forums/topic/hive-query-problems#post-1855 Mon, 07 May 2012 00:02:04 +0000 Anonymous 1855@http://www.datastax.com/support-forums/ <p>Hi..<br /> can anybody suggest me if I could aggregate all the values of a column in an array using Hive UDAF. </p> http://www.datastax.com/support-forums/topic/writing-loads-of-columns-using-cql-vs-hector#post-1161 Thu, 16 Feb 2012 13:15:46 +0000 Marius Waldal 1161@http://www.datastax.com/support-forums/ <p>Thank you so much for anwering, Nate. To be more specific about what I'm trying to do:</p> <p>The use case is a location CF with predefined columns for county, municipality etc, and an areaid. There are about 5.300 rows in this cf. </p> <p>In addition to using this as a cf for lookup, it is also used to verify if areaids from a log import job are valid when importing log lines. To do this, we have so far read all ids by getting all rows and returning the id column (done once, putting the IDs in a List). </p> <p>However, I thought it would be more efficient (and more cassandra-ish) to include 1 additional row in the location cf with all the IDS, so that when importing we would instead just read the valid IDs from columns in this row. And this is where the CQL dilemma shows up, writing 5300+ columns in that gnarly CQL statement :-)</p> <p>But we also thought about another option: concatenating all the IDs into a loong delimited String and then writing that string to a single column in the new lookup row, and then splitting it again when doing the import job.</p> <p>This approach has a hacky feel to it, but whatever is more efficient is good. It should also ensure less overhead than using thousands of columns, as the location cf is also rebuilt periodically, and this may involve areaids being removed. An update query against the row with thousands of columns will not remove the IDs that are obsolete, so we would have to first delete the row and then write it with the new columns. Having all IDs concatenated in one column means the update only needs to update this single column.<br /> However, this could perhaps also result in the query being too large for a single thrift msg?</p> <p>That was a lot of rambling. What do you think?<br /> 1 column?<br /> Or thousands of columns with row deletion and new insert, in batches of i.e. 500 columns?</p> <p>The columns will be String columns with a maximum of 5 digits each: 20012,20063 etc</p> <p>Marius </p> http://www.datastax.com/support-forums/topic/writing-loads-of-columns-using-cql-vs-hector#post-1150 Wed, 15 Feb 2012 20:47:05 +0000 zznate 1150@http://www.datastax.com/support-forums/ <p>Yeah, that insert would end up being some gnarly CQL. </p> <p>Using Hector's Mutator class would be simple and most likely more efficient. If this is an insert your workload will be doing frequently, take some time to play with the batch size. The bigger this is, the more efficient, but making this too big will cause transport errors and burn memory. To avoid continuous array resizing overhead, Thrift will keep expanding buffer sizes of the underlying connection until the max is reached (16MB by default). </p> <p>Start with about 500 columns and go up or down as needed. </p> http://www.datastax.com/support-forums/topic/writing-loads-of-columns-using-cql-vs-hector#post-1143 Wed, 15 Feb 2012 09:43:57 +0000 Marius Waldal 1143@http://www.datastax.com/support-forums/ <p>We are trying to use CQL for all Cassandra operations, but in cases that are typical cassandra-ish and not relational-ish (like having a single row with thousands of columns), this seems like bad practice. As a relational db would never have a high number of columns, inserting multiple columns listing first the column names and then column values or updating columns using name=value pairs is practical. </p> <p>But creating a CQL statement with thousands of name=value pairs does not ring well in my ears. Of course, one could do batch inserts instead, but this still seems like trying to force relational db-pants on nosql-legs... </p> <p>Is it in any way better to use e.g. Hector mutators with addInsertion for each column? Will it be more efficient? </p> <p>Marius </p> http://www.datastax.com/support-forums/topic/hash-cluster-single-table#post-1053 Wed, 18 Jan 2012 05:51:06 +0000 Anonymous 1053@http://www.datastax.com/support-forums/ <p>Finally I found out SSTable is indexed by B+Tree.</p> <p><a href="https://twitter.com/#" rel="nofollow">https://twitter.com/#</a>!/mujiang/status/159042770147876864/photo/1/large</p> <p>Thanks,<br /> Charlie | DBA </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1028 Fri, 06 Jan 2012 21:47:56 +0000 zznate 1028@http://www.datastax.com/support-forums/ <p>The original motivation on our side was some experimentation with persisting object graphs:<br /> <a href="https://github.com/riptano/hector-jpa" rel="nofollow">https://github.com/riptano/hector-jpa</a></p> <p>As you may have figured out, though it's been there for a few months, most folks have not really put composites through their paces. Specifically, the grave misunderstanding (and admitedly poor documentation of) DynamicComposites:<br /> <a href="https://issues.apache.org/jira/browse/CASSANDRA-3625" rel="nofollow">https://issues.apache.org/jira/browse/CASSANDRA-3625</a> </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1027 Fri, 06 Jan 2012 21:42:38 +0000 Anonymous 1027@http://www.datastax.com/support-forums/ <p>Yeah, it was this jira that led me to trying this out with composite types. Todd Nine's mention and example (quoted below) of a column scan made me think I might be able to scan within the first and second components. Obviously this is not yet possible as we figured out.</p> <blockquote><p> status &gt; 100 &amp;&amp; status &lt; 300 &amp;&amp; unitId = 10</p> <p>I would need to construct a column scan of the following to get correct result sets.</p> <p>start =&gt; 100+1+10+0</p> <p>end =&gt; 300+0+10+1 </p></blockquote> <p>So given Todd's example, "status &gt; 100 &amp;&amp; status &lt; 300 &amp;&amp; unitId = 10" works but "status &gt; 100 &amp;&amp; status &lt; 300 &amp;&amp; unitId &lt; 10" doesn't.</p> <p>Thanks. </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1026 Fri, 06 Jan 2012 20:40:34 +0000 zznate 1026@http://www.datastax.com/support-forums/ <p>Just remembered a long ago thread regarding how composites do comparisons independently on different components (see <a href="https://issues.apache.org/jira/browse/CASSANDRA-2231" rel="nofollow">https://issues.apache.org/jira/browse/CASSANDRA-2231</a> if you are interested). You will get the expected results, all columns where the first component is "zero" with the following:</p> <p> Composite startRange = new Composite();<br /> startRange.addComponent(0,new Long(0), AbstractComposite.ComponentEquality.EQUAL);</p> <p> Composite endRange = new Composite();<br /> endRange.addComponent(0, new Long(0), AbstractComposite.ComponentEquality.GREATER_THAN_EQUAL);</p> <p> sliceQuery.setRange(startRange, endRange, false, 100); </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1025 Fri, 06 Jan 2012 20:19:42 +0000 Anonymous 1025@http://www.datastax.com/support-forums/ <p>Separately, I'm experimenting with using super columns which seems like a better way to go for my particular use case. Because composite column queries restrict component equality to one component (the first component), I cannot limit the query results like I can in the super column solution. So it seems for my use case, CompositeTypes are not an efficient substitute for SuperColumns. Here's why I think that is...</p> <p>Given data (T1:T2)=&gt; (2:1),(2:0),(1:0),(0:1),(0:0) - DESCENDING ordered<br /> Arguments t1=2 and t2=0 where T1&lt;=t1 and T2&lt;=t2</p> <p>Composite<br /> ----------<br /> slice_query(t1); /* returns (2:1),(2:0),(1:0),(0:1),(0:0) to client */<br /> client_filter(results_of_slice_query, t2); </p> <p>Super - Allows limit to be applied<br /> -----------------------------------<br /> super_slice_query(t1 limit 1); /* returns {(2:1),(2:0)} */<br /> client_filter(results_of_slice_query, t2); </p> <p>The Super column solution is not as efficient if the client_filter fails to find a T2 given t2 because it would require an iterative query. Maybe not so bad given we will have 1000s of different values for T1 and with a composite column solution, it would be inefficient to send all those to the client.</p> <p>There may be other solutions... </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1022 Fri, 06 Jan 2012 19:49:41 +0000 Anonymous 1022@http://www.datastax.com/support-forums/ <p>@zznate same problem with 1.0.6. </p> http://www.datastax.com/support-forums/topic/are-a-compositetype-column-queries-with-less_than_equal-component-equality-supported-in-hector#post-1018 Fri, 06 Jan 2012 18:29:00 +0000 zznate 1018@http://www.datastax.com/support-forums/ <p>@heskech can you try again with 1.0.6? There was a (vaguely related) issue that was addressed (but this is a stretch). </p> <p>You are correct that it should have filtered on equality for the first component - I'll take your code and try to duplicate what you are seeing. Thanks for your patience (and the completeness of your examples!). </p>