asynchronous writes (aka consistency = 0)
Is there any mechanism that would allow me to write to Cassandra with no blocking at all? I spent a long time figuring out a problem I encountered with one node in each datacenter: LA, and NY using SS RF=1 and write consistency 1. My row keys are -mm-dd-h so basically for every hour a row would pin to one datacenter and I would get fast writes from one location. This would change periodically as the hour changed (took forever to figure out what was going on). The whole point of switching to SS from NTS was so I could reduce data redundancy (this is basically throw away data), but the delay in writing cross country is too high with SS since the minimum consistency will cause cassandra blocks to ensure there is ONE write (assuming all nodes are up). NTS does allow me to localize the block on writes by doing strategy options NY=1,LA=1.. but then I am back to storing duplicate data. I'd like to be able to use SS with RF1 and write consistency=0 (or some thing like that). Any thoughts?
Re: asynchronous writes (aka consistency = 0)
There used to be a ZERO consistency level but it was removed because it was harming more people than it was helping. If what you want is very high availability, i.e. being able to write even if the sole replica (in your RF=1 case) is down, then what you want to use is CL ANY. If you don't want to wait for the write to be applied by Cassandra before doing something else, then you can do that easily[1] client side. [1] if you are a php user, you may want to remove the word easily from the sentence. -- Sylvain On Tue, Aug 30, 2011 at 12:30 PM, Eric tamme wrote: > Is there any mechanism that would allow me to write to Cassandra with > no blocking at all? > > I spent a long time figuring out a problem I encountered with one node > in each datacenter: LA, and NY using SS RF=1 and write consistency 1. > My row keys are -mm-dd-h so basically for every hour a row would > pin to one datacenter and I would get fast writes from one location. > This would change periodically as the hour changed (took forever to > figure out what was going on). > > The whole point of switching to SS from NTS was so I could reduce data > redundancy (this is basically throw away data), but the delay in > writing cross country is too high with SS since the minimum > consistency will cause cassandra blocks to ensure there is ONE write > (assuming all nodes are up). > > NTS does allow me to localize the block on writes by doing strategy > options NY=1,LA=1.. but then I am back to storing duplicate data. I'd > like to be able to use SS with RF1 and write consistency=0 (or some > thing like that). > > Any thoughts? >
Re: Cassandra 0.8 & schematool
Look for a file called schema-sample.txt under the conf folder. You'll find a sample schema and the command to load the same. On Tue, Aug 30, 2011 at 11:30 AM, Jenny wrote: > Hi > > I notice that schematool was removed from the release of Cassandra 0.8. I > would like to know the reason of doing that and how i can load the schema > from configure file(like .yaml) automatically. > > > Best Regards! > > Jenny >
Re: Cassandra 0.8 & schematool
The right way to do this is to use a script of "create" commands: bin/cassandra-cli -f my-schema-creation-script On Tue, Aug 30, 2011 at 1:00 AM, Jenny wrote: > Hi > I notice that schematool was removed from the release of Cassandra 0.8. I > would like to know the reason of doing that and how i can load the schema > from configure file(like .yaml) automatically. > > Best Regards! > Jenny -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: asynchronous writes (aka consistency = 0)
On Tue, Aug 30, 2011 at 6:54 AM, Sylvain Lebresne wrote: > If you don't want to wait for the write to be applied by Cassandra before > doing something else, then you can do that easily[1] client side. Right. Also consider that if you did have local replicas in each DC you could get low-latency reads from that as well. Cassandra is designed to trade some replication overhead for latency and reliability; generally you're better served by accepting that instead of fighting it. :) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Updates lost
The problem still happens with very high probability even when it pauses for 5 milliseconds at every loop. If Pycassa uses microseconds it can't be the cause. Also I have the same problem with a Java client using Pelops. On Tue, Aug 30, 2011 at 12:14 AM, Tyler Hobbs wrote: > > On Mon, Aug 29, 2011 at 4:56 PM, Peter Schuller > wrote: >> >> > If the client sleeps for a few ms at each loop, the success rate >> > increases. At 15 ms, the script always succeeds so far. Interestingly, >> > the problem seems to be sensitive to alphabetical order. Updating the >> > value from 'aaa' to 'bbb' never has problem. No pause needed. >> >> Is it possible the version of pycassa you're using does not guarantee >> that successive queries use non-identical and monotonically increasing >> timestamps? > > By default, pycassa uses microsecond-precision timestamps. > ColumnFamily.insert() returns the timestamp used for the insert, so you > could always check that it was different. However, I doubt that you're > getting more than one insert per microsecond, unless you have VM issues with > the system clock. > > -- > Tyler Hobbs > Software Engineer, DataStax > Maintainer of the pycassa Cassandra Python client library > >
Re: Updates lost
> The problem still happens with very high probability even when it > pauses for 5 milliseconds at every loop. If Pycassa uses microseconds > it can't be the cause. Also I have the same problem with a Java client > using Pelops. You connect to localhost, but is that a single node or part of a cluster with RF > 1? If the latter, you need to use QUORUM consistency level to ensure that a read sees your write. If it's a single node and not a pycassa / client issue, I don't know off hand. -- / Peter Schuller (@scode on twitter)
Re: Updates lost
It's a single node. Thanks for the theory. I suspect part of it may still be right. Will dig more. On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller wrote: >> The problem still happens with very high probability even when it >> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds >> it can't be the cause. Also I have the same problem with a Java client >> using Pelops. > > You connect to localhost, but is that a single node or part of a > cluster with RF > 1? If the latter, you need to use QUORUM consistency > level to ensure that a read sees your write. > > If it's a single node and not a pycassa / client issue, I don't know off hand. > > -- > / Peter Schuller (@scode on twitter) >
RE: Disk usage for CommitLog
> 86GB in commitlog and 42GB in data Whoa, that seems really wrong, particularly given your data spans 13 months. Have you changed any of the default cassandra.yaml setting? What is the maximum memtable_flush_after across all your CFs? Any warnings/errors in the Cassandra log? > Out of curiosity, why do global flush thresholds work better than per-CF settings? My first thought is that I would want finer grained controls as my CFs can be extremely different in write/read patterns. By 'work better' I mean maximize memtable sizes (ie minimize flushing) without causing memory problems. The main reason to play with per-cf settings is to cause them to flush more than required which is generally not what you want to do (unless flushes are *currently* being triggered by the per-cf settings). Dan From: Derek Andree [mailto:dand...@lacunasystems.com] Sent: August-29-11 23:20 To: user@cassandra.apache.org Subject: Re: Disk usage for CommitLog Thanks Dan, good info. > First off, what version of Cassandra are you using? Sorry my bad, 0.8.4 > Provided you are using a recent Cassandra version (late 0.7 or 0.8.x) I doubt the commit log is your problem. My experience using Cassandra as a time series data store (with a full 30 days of data + various aggregations) has been that the commit log is a trivial fraction of the actual data. That said, its highly dependent on how you use your data and when it expires/gets deleted (with considerations for gc_grace). We keep 5 minute data on a few thousand "objects" for 13 months. We also do "rollup" aggregation for generating longer time period graphs and reports, very RRD like. With a few months of data, I see 86GB in commitlog and 42GB in data. but then again this is while I'm still in data as fast as I can for a test case, so that may have something to do with it :) > > As one final point, as of 0.8, I would not recommend playing with per-CF flush settings. There are global thresholds which work far better and account for things like java overhead. > Out of curiosity, why do global flush thresholds work better than per-CF settings? My first thought is that I would want finer grained controls as my CFs can be extremely different in write/read patterns. Thanks, -Derek
Re: Cassandra 0.8 & schematool
Thank you. problem solved 在 2011-8-30，下午9:12， Jonathan Ellis 写道： > The right way to do this is to use a script of "create" commands: > > bin/cassandra-cli -f my-schema-creation-script > > On Tue, Aug 30, 2011 at 1:00 AM, Jenny wrote: >> Hi >> I notice that schematool was removed from the release of Cassandra 0.8. I >> would like to know the reason of doing that and how i can load the schema >> from configure file(like .yaml) automatically. >> >> Best Regards! >> Jenny > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com Best Regards! Yi Wang(Jenny) Institute of Massive Computing Software Engineering Institute East China Normal University NO.109(West), Math Building, NO.3663, Zhongshan Road(North), Shanghai, China
Re: Querying a composite key with cassandra-cli
One thing I have noticed is that when you query via the cli with an invalid "assume" you no longer get the MarshalException beyond 0.8.1, it just states "null" Any chance this could be more user friendly? It kind of stumped me when I switched to 0.8.4. Anthony On Mon, Aug 29, 2011 at 2:35 PM, Anthony Ikeda wrote: > Yeah I figured out what happened. I inadvertently set the keys to utf8 on > the column family: > > assume ColumnFamily keys as utf8; > > which broke whichever default mechanism was in place to perform the colon > separated values for the Composite key. When I restarted cassandra-cli, the > query worked again. > > Any idea what type the key is on a Composite key such that I may be able to > re-assume it? > > Anthony > > > On Mon, Aug 29, 2011 at 2:21 PM, Jonathan Ellis wrote: > >> Sounds like you need to specify a key_validation_class so the cli >> knows how to encode the key. (It used to assume keys were always >> ascii.) >> >> On Mon, Aug 29, 2011 at 4:02 PM, Anthony Ikeda >> wrote: >> > Is there currently a way to query a composite key in cassandra-cli? >> > I was sure I used to be able to call: >> > get ColumnFamily['comp1:comp2'] >> > But this has recently stopped working. >> > Anthony >> > >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of DataStax, the source for professional Cassandra support >> http://www.datastax.com >> > >
Re: Querying a composite key with cassandra-cli
Sounds like a bug. Can you create a ticket on https://issues.apache.org/jira/browse/CASSANDRA ? On Tue, Aug 30, 2011 at 11:28 AM, Anthony Ikeda wrote: > One thing I have noticed is that when you query via the cli with an invalid > "assume" you no longer get the MarshalException beyond 0.8.1, it just states > "null" > Any chance this could be more user friendly? It kind of stumped me when I > switched to 0.8.4. > Anthony > > On Mon, Aug 29, 2011 at 2:35 PM, Anthony Ikeda > wrote: >> >> Yeah I figured out what happened. I inadvertently set the keys to utf8 on >> the column family: >> assume ColumnFamily keys as utf8; >> which broke whichever default mechanism was in place to perform the colon >> separated values for the Composite key. When I restarted cassandra-cli, the >> query worked again. >> Any idea what type the key is on a Composite key such that I may be able >> to re-assume it? >> Anthony >> >> On Mon, Aug 29, 2011 at 2:21 PM, Jonathan Ellis wrote: >>> >>> Sounds like you need to specify a key_validation_class so the cli >>> knows how to encode the key. (It used to assume keys were always >>> ascii.) >>> >>> On Mon, Aug 29, 2011 at 4:02 PM, Anthony Ikeda >>> wrote: >>> > Is there currently a way to query a composite key in cassandra-cli? >>> > I was sure I used to be able to call: >>> > get ColumnFamily['comp1:comp2'] >>> > But this has recently stopped working. >>> > Anthony >>> > >>> >>> >>> >>> -- >>> Jonathan Ellis >>> Project Chair, Apache Cassandra >>> co-founder of DataStax, the source for professional Cassandra support >>> http://www.datastax.com >> > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Querying a composite key with cassandra-cli
No problems. Anthony On Tue, Aug 30, 2011 at 9:31 AM, Jonathan Ellis wrote: > Sounds like a bug. Can you create a ticket on > https://issues.apache.org/jira/browse/CASSANDRA ? > > On Tue, Aug 30, 2011 at 11:28 AM, Anthony Ikeda > wrote: > > One thing I have noticed is that when you query via the cli with an > invalid > > "assume" you no longer get the MarshalException beyond 0.8.1, it just > states > > "null" > > Any chance this could be more user friendly? It kind of stumped me when I > > switched to 0.8.4. > > Anthony > > > > On Mon, Aug 29, 2011 at 2:35 PM, Anthony Ikeda < > anthony.ikeda@gmail.com> > > wrote: > >> > >> Yeah I figured out what happened. I inadvertently set the keys to utf8 > on > >> the column family: > >> assume ColumnFamily keys as utf8; > >> which broke whichever default mechanism was in place to perform the > colon > >> separated values for the Composite key. When I restarted cassandra-cli, > the > >> query worked again. > >> Any idea what type the key is on a Composite key such that I may be able > >> to re-assume it? > >> Anthony > >> > >> On Mon, Aug 29, 2011 at 2:21 PM, Jonathan Ellis > wrote: > >>> > >>> Sounds like you need to specify a key_validation_class so the cli > >>> knows how to encode the key. (It used to assume keys were always > >>> ascii.) > >>> > >>> On Mon, Aug 29, 2011 at 4:02 PM, Anthony Ikeda > >>> wrote: > >>> > Is there currently a way to query a composite key in cassandra-cli? > >>> > I was sure I used to be able to call: > >>> > get ColumnFamily['comp1:comp2'] > >>> > But this has recently stopped working. > >>> > Anthony > >>> > > >>> > >>> > >>> > >>> -- > >>> Jonathan Ellis > >>> Project Chair, Apache Cassandra > >>> co-founder of DataStax, the source for professional Cassandra support > >>> http://www.datastax.com > >> > > > > > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
Re: Solandra error - spaces in search
Could you reproduce it?
Re: Recommendations on moving to Hadoop/Hive with Cassandra + RDBMS
FWIW, we are using Pig (and Hadoop) with Cassandra and are looking to potentially move to Brisk because of the simplicity of operations there. Not sure what you mean about the true power of Hadoop. In my mind the true power of Hadoop is the ability to parallelize jobs and send each task to where the data resides. HDFS exists to enable that. Brisk is just another HDFS compatible implementation. If you're already storing your data in Cassandra and are looking to use Hadoop with it, then I would seriously consider using Brisk. That said, Cassandra with Hadoop works fine. On Aug 30, 2011, at 11:58 AM, Tharindu Mathew wrote: > Hi Eric, > > Thanks for your response. > > On Tue, Aug 30, 2011 at 5:35 PM, Eric Djatsa wrote: > >> Hi Tharindu, try having a look at Brisk( >> http://www.datastax.com/products/brisk) it integrates Hadoop with >> Cassandra and is shipped with Hive for SQL analysis. You can then install >> Sqoop(http://www.cloudera.com/downloads/sqoop/) on top of Hadoop in order >> to enable data import/export between Hadoop and MySQL. >> Does this sound ok to you ? >> >> These do sound ok. But I was looking at using something from Apache itself. > > Brisk sounds nice, but I feel that disregarding HDFS and totally switching > to Cassandra is not the right thing to do. Just my opinion there. I feel we > are not using the true power of Hadoop then. > > I feel Pig has more integration with Cassandra, so I might take a look > there. > > Whichever I choose, I will contribute the code back to the Apache projects I > use. Here's a sample data analysis I do with my language. Maybe, there is no > generic way to do what I want to do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> 2011/8/29 Tharindu Mathew >> >>> Hi, >>> >>> I have an already running system where I define a simple data flow (using >>> a simple custom data flow language) and configure jobs to run against stored >>> data. I use quartz to schedule and run these jobs and the data exists on >>> various data stores (mainly Cassandra but some data exists in RDBMS like >>> mysql as well). >>> >>> Thinking about scalability and already existing support for standard data >>> flow languages in the form of Pig and HiveQL, I plan to move my system to >>> Hadoop. >>> >>> I've seen some efforts on the integration of Cassandra and Hadoop. I've >>> been reading up and still am contemplating on how to make this change. >>> >>> It would be great to hear the recommended approach of doing this on Hadoop >>> with the integration of Cassandra and other RDBMS. For example, a sample >>> task that already runs on the system is "once in every hour, get rows from >>> column family X, aggregate data in columns A, B and C and write back to >>> column family Y, and enter details of last aggregated row into a table in >>> mysql" >>> >>> Thanks in advance. >>> >>> -- >>> Regards, >>> >>> Tharindu >>> >> >> >> >> -- >> *Eric Djatsa Yota* >> *Double degree MsC Student in Computer Science Engineering and >> Communication Networks >> Télécom ParisTech (FRANCE) - Politecnico di Torino (ITALY)* >> *Intern at AMADEUS S.A.S Sophia Antipolis* >> djatsa...@gmail.com >> *Tel : 0601791859* >> >> > > > -- > Regards, > > Tharindu
Re: Updates lost
Looks like the theory is correct for the java case at least. The default timestamp precision of Pelops is millisecond. Hence the problem as explained by Peter. Once I supplied timestamps precise to microsecond (using System.nanoTime()), the problem went away. I previously stated that sleeping for a few milliseconds didn't help. It was actually because of the precision of Java Thread.sleep(). Sleeping for less than 15ms often doesn't sleep at all. Haven't checked the Python side to see if it's similar situation. Cheers. Jiang On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote: > It's a single node. Thanks for the theory. I suspect part of it may > still be right. Will dig more. > > On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller > wrote: >>> The problem still happens with very high probability even when it >>> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds >>> it can't be the cause. Also I have the same problem with a Java client >>> using Pelops. >> >> You connect to localhost, but is that a single node or part of a >> cluster with RF > 1? If the latter, you need to use QUORUM consistency >> level to ensure that a read sees your write. >> >> If it's a single node and not a pycassa / client issue, I don't know off >> hand. >> >> -- >> / Peter Schuller (@scode on twitter) >> >
Re: Updates lost
I would not use nano time with cassandra. Internally and throughout the clients, milliseconds is pretty much a standard. You can get into trouble because when comparing nanoseconds with milliseconds as long numbers, nanoseconds will always win. That bit us a while back when we deleted something and it couldn't come back because we deleted it with nanoseconds as the timestamp value. See the caveats for System.nanoTime() for why milliseconds is a standard: http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29 On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote: > Looks like the theory is correct for the java case at least. > > The default timestamp precision of Pelops is millisecond. Hence the > problem as explained by Peter. Once I supplied timestamps precise to > microsecond (using System.nanoTime()), the problem went away. > > I previously stated that sleeping for a few milliseconds didn't help. > It was actually because of the precision of Java Thread.sleep(). > Sleeping for less than 15ms often doesn't sleep at all. > > Haven't checked the Python side to see if it's similar situation. > > Cheers. > > Jiang > > On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote: >> It's a single node. Thanks for the theory. I suspect part of it may >> still be right. Will dig more. >> >> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller >> wrote: The problem still happens with very high probability even when it pauses for 5 milliseconds at every loop. If Pycassa uses microseconds it can't be the cause. Also I have the same problem with a Java client using Pelops. >>> >>> You connect to localhost, but is that a single node or part of a >>> cluster with RF > 1? If the latter, you need to use QUORUM consistency >>> level to ensure that a read sees your write. >>> >>> If it's a single node and not a pycassa / client issue, I don't know off >>> hand. >>> >>> -- >>> / Peter Schuller (@scode on twitter) >>> >>
Re: Updates lost
On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna wrote: > I would not use nano time with cassandra. Internally and throughout the > clients, milliseconds is pretty much a standard. You can get into trouble > because when comparing nanoseconds with milliseconds as long numbers, > nanoseconds will always win. That bit us a while back when we deleted > something and it couldn't come back because we deleted it with nanoseconds > as the timestamp value. > > See the caveats for System.nanoTime() for why milliseconds is a standard: > > http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29 > > On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote: > > > Looks like the theory is correct for the java case at least. > > > > The default timestamp precision of Pelops is millisecond. Hence the > > problem as explained by Peter. Once I supplied timestamps precise to > > microsecond (using System.nanoTime()), the problem went away. > > > > I previously stated that sleeping for a few milliseconds didn't help. > > It was actually because of the precision of Java Thread.sleep(). > > Sleeping for less than 15ms often doesn't sleep at all. > > > > Haven't checked the Python side to see if it's similar situation. > > > > Cheers. > > > > Jiang > > > > On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote: > >> It's a single node. Thanks for the theory. I suspect part of it may > >> still be right. Will dig more. > >> > >> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller > >> wrote: > The problem still happens with very high probability even when it > pauses for 5 milliseconds at every loop. If Pycassa uses microseconds > it can't be the cause. Also I have the same problem with a Java client > using Pelops. > >>> > >>> You connect to localhost, but is that a single node or part of a > >>> cluster with RF > 1? If the latter, you need to use QUORUM consistency > >>> level to ensure that a read sees your write. > >>> > >>> If it's a single node and not a pycassa / client issue, I don't know > off hand. > >>> > >>> -- > >>> / Peter Schuller (@scode on twitter) > >>> > >> > > Isn't the standard microseconds ? (System.currentTimeMillis()*1000L) http://wiki.apache.org/cassandra/DataModel The CLI uses microseconds. If your code and the CLI are doing different things with time BadThingsWillHappen TM
Re: Updates lost
Ed- you're right - milliseconds * 1000. That's right. The other stuff about nano time still stands, but you're right - microseconds. Sorry about that. On Aug 30, 2011, at 1:20 PM, Edward Capriolo wrote: > > > On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna > wrote: > I would not use nano time with cassandra. Internally and throughout the > clients, milliseconds is pretty much a standard. You can get into trouble > because when comparing nanoseconds with milliseconds as long numbers, > nanoseconds will always win. That bit us a while back when we deleted > something and it couldn't come back because we deleted it with nanoseconds as > the timestamp value. > > See the caveats for System.nanoTime() for why milliseconds is a standard: > http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29 > > On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote: > > > Looks like the theory is correct for the java case at least. > > > > The default timestamp precision of Pelops is millisecond. Hence the > > problem as explained by Peter. Once I supplied timestamps precise to > > microsecond (using System.nanoTime()), the problem went away. > > > > I previously stated that sleeping for a few milliseconds didn't help. > > It was actually because of the precision of Java Thread.sleep(). > > Sleeping for less than 15ms often doesn't sleep at all. > > > > Haven't checked the Python side to see if it's similar situation. > > > > Cheers. > > > > Jiang > > > > On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote: > >> It's a single node. Thanks for the theory. I suspect part of it may > >> still be right. Will dig more. > >> > >> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller > >> wrote: > The problem still happens with very high probability even when it > pauses for 5 milliseconds at every loop. If Pycassa uses microseconds > it can't be the cause. Also I have the same problem with a Java client > using Pelops. > >>> > >>> You connect to localhost, but is that a single node or part of a > >>> cluster with RF > 1? If the latter, you need to use QUORUM consistency > >>> level to ensure that a read sees your write. > >>> > >>> If it's a single node and not a pycassa / client issue, I don't know off > >>> hand. > >>> > >>> -- > >>> / Peter Schuller (@scode on twitter) > >>> > >> > > > Isn't the standard microseconds ? (System.currentTimeMillis()*1000L) > > http://wiki.apache.org/cassandra/DataModel > > The CLI uses microseconds. If your code and the CLI are doing different > things with time BadThingsWillHappen TM > >
Re: Recommendations on moving to Hadoop/Hive with Cassandra + RDBMS
Thanks Jeremy for your response. That gives me some encouragement, that I might be on that right track. I think I need to try out more stuff before coming to a conclusion on Brisk. For Pig operations over Cassandra, I only could find http://svn.apache.org/repos/asf/cassandra/trunk/contrib/pig. Are there any other resource that you can point me to? There seems to be a lack of samples on this subject. On Tue, Aug 30, 2011 at 10:56 PM, Jeremy Hanna wrote: > FWIW, we are using Pig (and Hadoop) with Cassandra and are looking to > potentially move to Brisk because of the simplicity of operations there. > > Not sure what you mean about the true power of Hadoop. In my mind the true > power of Hadoop is the ability to parallelize jobs and send each task to > where the data resides. HDFS exists to enable that. Brisk is just another > HDFS compatible implementation. If you're already storing your data in > Cassandra and are looking to use Hadoop with it, then I would seriously > consider using Brisk. > > That said, Cassandra with Hadoop works fine. > > On Aug 30, 2011, at 11:58 AM, Tharindu Mathew wrote: > > > Hi Eric, > > > > Thanks for your response. > > > > On Tue, Aug 30, 2011 at 5:35 PM, Eric Djatsa > wrote: > > > >> Hi Tharindu, try having a look at Brisk( > >> http://www.datastax.com/products/brisk) it integrates Hadoop with > >> Cassandra and is shipped with Hive for SQL analysis. You can then > install > >> Sqoop(http://www.cloudera.com/downloads/sqoop/) on top of Hadoop in > order > >> to enable data import/export between Hadoop and MySQL. > >> Does this sound ok to you ? > >> > >> These do sound ok. But I was looking at using something from Apache > itself. > > > > Brisk sounds nice, but I feel that disregarding HDFS and totally > switching > > to Cassandra is not the right thing to do. Just my opinion there. I feel > we > > are not using the true power of Hadoop then. > > > > I feel Pig has more integration with Cassandra, so I might take a look > > there. > > > > Whichever I choose, I will contribute the code back to the Apache > projects I > > use. Here's a sample data analysis I do with my language. Maybe, there is > no > > generic way to do what I want to do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> 2011/8/29 Tharindu Mathew > >> > >>> Hi, > >>> > >>> I have an already running system where I define a simple data flow > (using > >>> a simple custom data flow language) and configure jobs to run against > stored > >>> data. I use quartz to schedule and run these jobs and the data exists > on > >>> various data stores (mainly Cassandra but some data exists in RDBMS > like > >>> mysql as well). > >>> > >>> Thinking about scalability and already existing support for standard > data > >>> flow languages in the form of Pig and HiveQL, I plan to move my system > to > >>> Hadoop. > >>> > >>> I've seen some efforts on the integration of Cassandra and Hadoop. I've > >>> been reading up and still am contemplating on how to make this change. > >>> > >>> It would be great to hear the recommended approach of doing this on > Hadoop > >>> with the integration of Cassandra and other RDBMS. For example, a > sample > >>> task that already runs on the system is "once in every hour, get rows > from > >>> column family X, aggregate data in columns A, B and C and write back to > >>> column family Y, and enter details of last aggregated row into a table > in > >>> mysql" > >>> > >>> Thanks in advance. > >>> > >>> -- > >>> Regards, > >>> > >>> Tharindu > >>> > >> > >> > >> > >> -- > >> *Eric Djatsa Yota* > >> *Double degree MsC Student in Computer Science Engineering and > >> Communication Networks > >> Télécom ParisTech (FRANCE) - Politecnico di Torino (ITALY)* > >> *Intern at AMADEUS S.A.S Sophia Antipolis* > >> djatsa...@gmail.com > >> *Tel : 0601791859* > >> > >> > > > > > > -- > > Regards, > > > > Tharindu > > -- Regards, Tharindu
Re: Updates lost
Indeed it's microseconds. We are talking about how to achieve the
precision of microseconds. One way is System.currentTimeInMillis() *
1000. It's only precise to milliseconds. If there are more than one
update in the same millisecond, the second one may be lost. That's my
original problem.
The other way is to derive from System.nanoTime(). This function
doesn't directly return the time since epoch. I used the following:
private static long nanotimeOffset = System.nanoTime()
- System.currentTimeMillis() * 100;
private static long currentTimeNanos() {
return System.nanoTime() - nanotimeOffset;
}
The timestamp to use is then currentTimeNanos() / 1000.
Anyone sees problem with this approach?
On Tue, Aug 30, 2011 at 2:20 PM, Edward Capriolo wrote:
>
>
> On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna
> wrote:
>>
>> I would not use nano time with cassandra. Internally and throughout the
>> clients, milliseconds is pretty much a standard. You can get into trouble
>> because when comparing nanoseconds with milliseconds as long numbers,
>> nanoseconds will always win. That bit us a while back when we deleted
>> something and it couldn't come back because we deleted it with nanoseconds
>> as the timestamp value.
>>
>> See the caveats for System.nanoTime() for why milliseconds is a standard:
>>
>> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>>
>> On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote:
>>
>> > Looks like the theory is correct for the java case at least.
>> >
>> > The default timestamp precision of Pelops is millisecond. Hence the
>> > problem as explained by Peter. Once I supplied timestamps precise to
>> > microsecond (using System.nanoTime()), the problem went away.
>> >
>> > I previously stated that sleeping for a few milliseconds didn't help.
>> > It was actually because of the precision of Java Thread.sleep().
>> > Sleeping for less than 15ms often doesn't sleep at all.
>> >
>> > Haven't checked the Python side to see if it's similar situation.
>> >
>> > Cheers.
>> >
>> > Jiang
>> >
>> > On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote:
>> >> It's a single node. Thanks for the theory. I suspect part of it may
>> >> still be right. Will dig more.
>> >>
>> >> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller
>> >> wrote:
>> The problem still happens with very high probability even when it
>> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
>> it can't be the cause. Also I have the same problem with a Java
>> client
>> using Pelops.
>> >>>
>> >>> You connect to localhost, but is that a single node or part of a
>> >>> cluster with RF > 1? If the latter, you need to use QUORUM consistency
>> >>> level to ensure that a read sees your write.
>> >>>
>> >>> If it's a single node and not a pycassa / client issue, I don't know
>> >>> off hand.
>> >>>
>> >>> --
>> >>> / Peter Schuller (@scode on twitter)
>> >>>
>> >>
>>
>
> Isn't the standard microseconds ? (System.currentTimeMillis()*1000L)
> http://wiki.apache.org/cassandra/DataModel
> The CLI uses microseconds. If your code and the CLI are doing different
> things with time BadThingsWillHappen TM
>
>
Re: Updates lost
Yes - the reason why internally Cassandra uses milliseconds * 1000 is because
System.nanoTime javadoc says "This method can only be used to measure elapsed
time and is not related to any other notion of system or wall-clock time."
http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
On Aug 30, 2011, at 1:31 PM, Jiang Chen wrote:
> Indeed it's microseconds. We are talking about how to achieve the
> precision of microseconds. One way is System.currentTimeInMillis() *
> 1000. It's only precise to milliseconds. If there are more than one
> update in the same millisecond, the second one may be lost. That's my
> original problem.
>
> The other way is to derive from System.nanoTime(). This function
> doesn't directly return the time since epoch. I used the following:
>
> private static long nanotimeOffset = System.nanoTime()
> - System.currentTimeMillis() * 100;
>
> private static long currentTimeNanos() {
> return System.nanoTime() - nanotimeOffset;
> }
>
> The timestamp to use is then currentTimeNanos() / 1000.
>
> Anyone sees problem with this approach?
>
> On Tue, Aug 30, 2011 at 2:20 PM, Edward Capriolo
> wrote:
>>
>>
>> On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna
>> wrote:
>>>
>>> I would not use nano time with cassandra. Internally and throughout the
>>> clients, milliseconds is pretty much a standard. You can get into trouble
>>> because when comparing nanoseconds with milliseconds as long numbers,
>>> nanoseconds will always win. That bit us a while back when we deleted
>>> something and it couldn't come back because we deleted it with nanoseconds
>>> as the timestamp value.
>>>
>>> See the caveats for System.nanoTime() for why milliseconds is a standard:
>>>
>>> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>>>
>>> On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote:
>>>
Looks like the theory is correct for the java case at least.
The default timestamp precision of Pelops is millisecond. Hence the
problem as explained by Peter. Once I supplied timestamps precise to
microsecond (using System.nanoTime()), the problem went away.
I previously stated that sleeping for a few milliseconds didn't help.
It was actually because of the precision of Java Thread.sleep().
Sleeping for less than 15ms often doesn't sleep at all.
Haven't checked the Python side to see if it's similar situation.
Cheers.
Jiang
On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote:
> It's a single node. Thanks for the theory. I suspect part of it may
> still be right. Will dig more.
>
> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller
> wrote:
>>> The problem still happens with very high probability even when it
>>> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
>>> it can't be the cause. Also I have the same problem with a Java
>>> client
>>> using Pelops.
>>
>> You connect to localhost, but is that a single node or part of a
>> cluster with RF > 1? If the latter, you need to use QUORUM consistency
>> level to ensure that a read sees your write.
>>
>> If it's a single node and not a pycassa / client issue, I don't know
>> off hand.
>>
>> --
>> / Peter Schuller (@scode on twitter)
>>
>
>>>
>>
>> Isn't the standard microseconds ? (System.currentTimeMillis()*1000L)
>> http://wiki.apache.org/cassandra/DataModel
>> The CLI uses microseconds. If your code and the CLI are doing different
>> things with time BadThingsWillHappen TM
>>
>>
Re: Recommendations on moving to Hadoop/Hive with Cassandra + RDBMS
I've tried to help out with some UDFs and references that help with our use case: https://github.com/jeromatron/pygmalion/ There are some brisk docs on pig as well that might be helpful: http://www.datastax.com/docs/0.8/brisk/about_pig On Aug 30, 2011, at 1:30 PM, Tharindu Mathew wrote: > Thanks Jeremy for your response. That gives me some encouragement, that I > might be on that right track. > > I think I need to try out more stuff before coming to a conclusion on Brisk. > > For Pig operations over Cassandra, I only could find > http://svn.apache.org/repos/asf/cassandra/trunk/contrib/pig. Are there any > other resource that you can point me to? There seems to be a lack of samples > on this subject. > > On Tue, Aug 30, 2011 at 10:56 PM, Jeremy Hanna > wrote: > FWIW, we are using Pig (and Hadoop) with Cassandra and are looking to > potentially move to Brisk because of the simplicity of operations there. > > Not sure what you mean about the true power of Hadoop. In my mind the true > power of Hadoop is the ability to parallelize jobs and send each task to > where the data resides. HDFS exists to enable that. Brisk is just another > HDFS compatible implementation. If you're already storing your data in > Cassandra and are looking to use Hadoop with it, then I would seriously > consider using Brisk. > > That said, Cassandra with Hadoop works fine. > > On Aug 30, 2011, at 11:58 AM, Tharindu Mathew wrote: > > > Hi Eric, > > > > Thanks for your response. > > > > On Tue, Aug 30, 2011 at 5:35 PM, Eric Djatsa wrote: > > > >> Hi Tharindu, try having a look at Brisk( > >> http://www.datastax.com/products/brisk) it integrates Hadoop with > >> Cassandra and is shipped with Hive for SQL analysis. You can then install > >> Sqoop(http://www.cloudera.com/downloads/sqoop/) on top of Hadoop in order > >> to enable data import/export between Hadoop and MySQL. > >> Does this sound ok to you ? > >> > >> These do sound ok. But I was looking at using something from Apache itself. > > > > Brisk sounds nice, but I feel that disregarding HDFS and totally switching > > to Cassandra is not the right thing to do. Just my opinion there. I feel we > > are not using the true power of Hadoop then. > > > > I feel Pig has more integration with Cassandra, so I might take a look > > there. > > > > Whichever I choose, I will contribute the code back to the Apache projects I > > use. Here's a sample data analysis I do with my language. Maybe, there is no > > generic way to do what I want to do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> 2011/8/29 Tharindu Mathew > >> > >>> Hi, > >>> > >>> I have an already running system where I define a simple data flow (using > >>> a simple custom data flow language) and configure jobs to run against > >>> stored > >>> data. I use quartz to schedule and run these jobs and the data exists on > >>> various data stores (mainly Cassandra but some data exists in RDBMS like > >>> mysql as well). > >>> > >>> Thinking about scalability and already existing support for standard data > >>> flow languages in the form of Pig and HiveQL, I plan to move my system to > >>> Hadoop. > >>> > >>> I've seen some efforts on the integration of Cassandra and Hadoop. I've > >>> been reading up and still am contemplating on how to make this change. > >>> > >>> It would be great to hear the recommended approach of doing this on Hadoop > >>> with the integration of Cassandra and other RDBMS. For example, a sample > >>> task that already runs on the system is "once in every hour, get rows from > >>> column family X, aggregate data in columns A, B and C and write back to > >>> column family Y, and enter details of last aggregated row into a table in > >>> mysql" > >>> > >>> Thanks in advance. > >>> > >>> -- > >>> Regards, > >>> > >>> Tharindu > >>> > >> > >> > >> > >> -- > >> *Eric Djatsa Yota* > >> *Double degree MsC Student in Computer Science Engineering and > >> Communication Networks > >> Télécom ParisTech (FRANCE) - Politecnico di Torino (ITALY)* > >> *Intern at AMADEUS S.A.S Sophia Antipolis* > >> djatsa...@gmail.com > >> *Tel : 0601791859* > >> > >> > > > > > > -- > > Regards, > > > > Tharindu > > > > > -- > Regards, > > Tharindu
Re: Updates lost
Do you see any problem with my approach to derive the current time in
nano seconds though?
On Tue, Aug 30, 2011 at 2:39 PM, Jeremy Hanna
wrote:
> Yes - the reason why internally Cassandra uses milliseconds * 1000 is because
> System.nanoTime javadoc says "This method can only be used to measure elapsed
> time and is not related to any other notion of system or wall-clock time."
>
> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>
> On Aug 30, 2011, at 1:31 PM, Jiang Chen wrote:
>
>> Indeed it's microseconds. We are talking about how to achieve the
>> precision of microseconds. One way is System.currentTimeInMillis() *
>> 1000. It's only precise to milliseconds. If there are more than one
>> update in the same millisecond, the second one may be lost. That's my
>> original problem.
>>
>> The other way is to derive from System.nanoTime(). This function
>> doesn't directly return the time since epoch. I used the following:
>>
>> private static long nanotimeOffset = System.nanoTime()
>> - System.currentTimeMillis() * 100;
>>
>> private static long currentTimeNanos() {
>> return System.nanoTime() - nanotimeOffset;
>> }
>>
>> The timestamp to use is then currentTimeNanos() / 1000.
>>
>> Anyone sees problem with this approach?
>>
>> On Tue, Aug 30, 2011 at 2:20 PM, Edward Capriolo
>> wrote:
>>>
>>>
>>> On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna
>>> wrote:
I would not use nano time with cassandra. Internally and throughout the
clients, milliseconds is pretty much a standard. You can get into trouble
because when comparing nanoseconds with milliseconds as long numbers,
nanoseconds will always win. That bit us a while back when we deleted
something and it couldn't come back because we deleted it with nanoseconds
as the timestamp value.
See the caveats for System.nanoTime() for why milliseconds is a standard:
http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote:
> Looks like the theory is correct for the java case at least.
>
> The default timestamp precision of Pelops is millisecond. Hence the
> problem as explained by Peter. Once I supplied timestamps precise to
> microsecond (using System.nanoTime()), the problem went away.
>
> I previously stated that sleeping for a few milliseconds didn't help.
> It was actually because of the precision of Java Thread.sleep().
> Sleeping for less than 15ms often doesn't sleep at all.
>
> Haven't checked the Python side to see if it's similar situation.
>
> Cheers.
>
> Jiang
>
> On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote:
>> It's a single node. Thanks for the theory. I suspect part of it may
>> still be right. Will dig more.
>>
>> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller
>> wrote:
The problem still happens with very high probability even when it
pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
it can't be the cause. Also I have the same problem with a Java
client
using Pelops.
>>>
>>> You connect to localhost, but is that a single node or part of a
>>> cluster with RF > 1? If the latter, you need to use QUORUM consistency
>>> level to ensure that a read sees your write.
>>>
>>> If it's a single node and not a pycassa / client issue, I don't know
>>> off hand.
>>>
>>> --
>>> / Peter Schuller (@scode on twitter)
>>>
>>
>>>
>>> Isn't the standard microseconds ? (System.currentTimeMillis()*1000L)
>>> http://wiki.apache.org/cassandra/DataModel
>>> The CLI uses microseconds. If your code and the CLI are doing different
>>> things with time BadThingsWillHappen TM
>>>
>>>
>
>
Re: Updates lost
Sorry - misread your earlier email. I would login to IRC and ask in
#cassandra. I would think given the nature of nanotime you'll run into harder
to track down problems, but it may be fine.
On Aug 30, 2011, at 2:06 PM, Jiang Chen wrote:
> Do you see any problem with my approach to derive the current time in
> nano seconds though?
>
> On Tue, Aug 30, 2011 at 2:39 PM, Jeremy Hanna
> wrote:
>> Yes - the reason why internally Cassandra uses milliseconds * 1000 is
>> because System.nanoTime javadoc says "This method can only be used to
>> measure elapsed time and is not related to any other notion of system or
>> wall-clock time."
>>
>> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>>
>> On Aug 30, 2011, at 1:31 PM, Jiang Chen wrote:
>>
>>> Indeed it's microseconds. We are talking about how to achieve the
>>> precision of microseconds. One way is System.currentTimeInMillis() *
>>> 1000. It's only precise to milliseconds. If there are more than one
>>> update in the same millisecond, the second one may be lost. That's my
>>> original problem.
>>>
>>> The other way is to derive from System.nanoTime(). This function
>>> doesn't directly return the time since epoch. I used the following:
>>>
>>> private static long nanotimeOffset = System.nanoTime()
>>> - System.currentTimeMillis() * 100;
>>>
>>> private static long currentTimeNanos() {
>>> return System.nanoTime() - nanotimeOffset;
>>> }
>>>
>>> The timestamp to use is then currentTimeNanos() / 1000.
>>>
>>> Anyone sees problem with this approach?
>>>
>>> On Tue, Aug 30, 2011 at 2:20 PM, Edward Capriolo
>>> wrote:
On Tue, Aug 30, 2011 at 1:41 PM, Jeremy Hanna
wrote:
>
> I would not use nano time with cassandra. Internally and throughout the
> clients, milliseconds is pretty much a standard. You can get into trouble
> because when comparing nanoseconds with milliseconds as long numbers,
> nanoseconds will always win. That bit us a while back when we deleted
> something and it couldn't come back because we deleted it with nanoseconds
> as the timestamp value.
>
> See the caveats for System.nanoTime() for why milliseconds is a standard:
>
> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>
> On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote:
>
>> Looks like the theory is correct for the java case at least.
>>
>> The default timestamp precision of Pelops is millisecond. Hence the
>> problem as explained by Peter. Once I supplied timestamps precise to
>> microsecond (using System.nanoTime()), the problem went away.
>>
>> I previously stated that sleeping for a few milliseconds didn't help.
>> It was actually because of the precision of Java Thread.sleep().
>> Sleeping for less than 15ms often doesn't sleep at all.
>>
>> Haven't checked the Python side to see if it's similar situation.
>>
>> Cheers.
>>
>> Jiang
>>
>> On Tue, Aug 30, 2011 at 9:57 AM, Jiang Chen wrote:
>>> It's a single node. Thanks for the theory. I suspect part of it may
>>> still be right. Will dig more.
>>>
>>> On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller
>>> wrote:
> The problem still happens with very high probability even when it
> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
> it can't be the cause. Also I have the same problem with a Java
> client
> using Pelops.
You connect to localhost, but is that a single node or part of a
cluster with RF > 1? If the latter, you need to use QUORUM consistency
level to ensure that a read sees your write.
If it's a single node and not a pycassa / client issue, I don't know
off hand.
--
/ Peter Schuller (@scode on twitter)
>>>
>
Isn't the standard microseconds ? (System.currentTimeMillis()*1000L)
http://wiki.apache.org/cassandra/DataModel
The CLI uses microseconds. If your code and the CLI are doing different
things with time BadThingsWillHappen TM
>>
>>
Re: Disk usage for CommitLog
> > 86GB in commitlog and 42GB in data > > Whoa, that seems really wrong, particularly given your data spans 13 months. > Have you changed any of the default cassandra.yaml setting? What is the > maximum memtable_flush_after across all your CFs? Any warnings/errors in the > Cassandra log? > It seems wrong to me too. It got so bad that /var/lib/cassandra looked like this: $ du -hs ./* 122G./commitlog 55G ./data 17M ./saved_caches I restarted cassandra, and it took a while to chew through all the commitlog files, then disk utilization was like so: du -hs ./* 1.1M./commitlog 56G ./data 17M ./saved_caches This isn't with 13 months of data, only with a couple months of data. Upon going through the cassandra logs, I saw a ton of "too many open files" warnings: WARN [Thread-4] 2011-08-30 12:07:27,601 CustomTThreadPoolServer.java (line 112) Transport error occurred during acceptance of message. org.apache.thrift.transport.TTransportException: java.net.SocketException: Too many open files at org.apache.thrift.transport.TServerSocket.acceptImpl(TServerSocket.java:118) at org.apache.cassandra.thrift.TCustomServerSocket.acceptImpl(TCustomServerSocket.java:68) at org.apache.cassandra.thrift.TCustomServerSocket.acceptImpl(TCustomServerSocket.java:39) at org.apache.thrift.transport.TServerTransport.accept(TServerTransport.java:31) at org.apache.cassandra.thrift.CustomTThreadPoolServer.serve(CustomTThreadPoolServer.java:102) at org.apache.cassandra.thrift.CassandraDaemon$ThriftServer.run(CassandraDaemon.java:198) Caused by: java.net.SocketException: Too many open files at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at org.apache.thrift.transport.TServerSocket.acceptImpl(TServerSocket.java:113) I guess I should set the number of allowed files to some big number with ulimit. Anyone have a suggestion for how big? I was thinking ulimit -n 1, but first I'm going to try to reproduce the "too many files open" condition and then have a look at lsof to see just how many files are really open. On a side note, why does cassandra seem to log to /var/log/cassandra.log no matter what's in log4j.properties? I ended up having to link that to /dev/null to keep from filling up my root partition with cassandra logs that I already have elsewhere on another filesystem. -Derek smime.p7s Description: S/MIME cryptographic signature
Re: Disk usage for CommitLog
Okay I figured this out, the default for MemtableFlushAfterMins is not 60 minutes like some here said and what datastax docs say (http://www.datastax.com/docs/0.8/configuration/storage_configuration), it's 24 hours (1440). I changed them all to 60 for every CF and now commit logs only hang around for an hour, which is way better for me. So, is the value of 1440 correct and the docs are wrong, or is 60 correct and 1440 made it into 0.8.4 somehow? Am I correct in assuming that if even one CF has it's MemtableFlushAfterMins set high (like 1440) and if data from that CF makes it into any commitlog segment then that commitlog segment will be on disk for 24 hours even if all the other CFs have MemtableFlushAfterMins set to 60? If so then maybe this should be a global setting, or alternatively each CF could have it's own CommitLog. I don't know enough about cassandra internals to know if there is a reason commitlogs need to contain data for all CFs (performance, too many files, etc). Thanks, -Derek > > 86GB in commitlog and 42GB in data > > Whoa, that seems really wrong, particularly given your data spans 13 months. > Have you changed any of the default cassandra.yaml setting? What is the > maximum memtable_flush_after across all your CFs? Any warnings/errors in the > Cassandra log? smime.p7s Description: S/MIME cryptographic signature
Re: Cassandra upgrading
NEWS.txt covers upgrading. [moving to user list.] On Tue, Aug 30, 2011 at 8:47 PM, 邓志远 wrote: > Hi All: > Now i use Cassandra0.7.5 in the cluster .how to upgrade to Cassandra0.8.4? > there are a large data in Cassandra0.7.5. Can you tell me how to upgrade ? > > Thanks! -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Recommendations on moving to Hadoop/Hive with Cassandra + RDBMS
Thanks Jeremy. These will be really useful. On Wed, Aug 31, 2011 at 12:12 AM, Jeremy Hanna wrote: > I've tried to help out with some UDFs and references that help with our use > case: https://github.com/jeromatron/pygmalion/ > > There are some brisk docs on pig as well that might be helpful: > http://www.datastax.com/docs/0.8/brisk/about_pig > > On Aug 30, 2011, at 1:30 PM, Tharindu Mathew wrote: > > > Thanks Jeremy for your response. That gives me some encouragement, that I > might be on that right track. > > > > I think I need to try out more stuff before coming to a conclusion on > Brisk. > > > > For Pig operations over Cassandra, I only could find > http://svn.apache.org/repos/asf/cassandra/trunk/contrib/pig. Are there any > other resource that you can point me to? There seems to be a lack of samples > on this subject. > > > > On Tue, Aug 30, 2011 at 10:56 PM, Jeremy Hanna < > jeremy.hanna1...@gmail.com> wrote: > > FWIW, we are using Pig (and Hadoop) with Cassandra and are looking to > potentially move to Brisk because of the simplicity of operations there. > > > > Not sure what you mean about the true power of Hadoop. In my mind the > true power of Hadoop is the ability to parallelize jobs and send each task > to where the data resides. HDFS exists to enable that. Brisk is just > another HDFS compatible implementation. If you're already storing your data > in Cassandra and are looking to use Hadoop with it, then I would seriously > consider using Brisk. > > > > That said, Cassandra with Hadoop works fine. > > > > On Aug 30, 2011, at 11:58 AM, Tharindu Mathew wrote: > > > > > Hi Eric, > > > > > > Thanks for your response. > > > > > > On Tue, Aug 30, 2011 at 5:35 PM, Eric Djatsa > wrote: > > > > > >> Hi Tharindu, try having a look at Brisk( > > >> http://www.datastax.com/products/brisk) it integrates Hadoop with > > >> Cassandra and is shipped with Hive for SQL analysis. You can then > install > > >> Sqoop(http://www.cloudera.com/downloads/sqoop/) on top of Hadoop in > order > > >> to enable data import/export between Hadoop and MySQL. > > >> Does this sound ok to you ? > > >> > > >> These do sound ok. But I was looking at using something from Apache > itself. > > > > > > Brisk sounds nice, but I feel that disregarding HDFS and totally > switching > > > to Cassandra is not the right thing to do. Just my opinion there. I > feel we > > > are not using the true power of Hadoop then. > > > > > > I feel Pig has more integration with Cassandra, so I might take a look > > > there. > > > > > > Whichever I choose, I will contribute the code back to the Apache > projects I > > > use. Here's a sample data analysis I do with my language. Maybe, there > is no > > > generic way to do what I want to do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> 2011/8/29 Tharindu Mathew > > >> > > >>> Hi, > > >>> > > >>> I have an already running system where I define a simple data flow > (using > > >>> a simple custom data flow language) and configure jobs to run against > stored > > >>> data. I use quartz to schedule and run these jobs and the data exists > on > > >>> various data stores (mainly Cassandra but some data exists in RDBMS > like > > >>> mysql as well). > > >>> > > >>> Thinking about scalability and already existing support for standard > data > > >>> flow languages in the form of Pig and HiveQL, I plan to move my > system to > > >>> Hadoop. > > >>> > > >>> I've seen some efforts on the integration of Cassandra and Hadoop. > I've > > >>> been reading up and still am contemplating on how to make this > change. > > >>> > > >>> It would be great to hear the recommended approach of doing this on > Hadoop > > >>> with the integration of Cassandra and other RDBMS. For example, a > sample > > >>> task that already runs on the system is "once in every hour, get rows > from > > >>> column family X, aggregate data in columns A, B and C and write back > to > > >>> column family Y, and enter details of last aggregated row into a > table in > > >>> mysql" > > >>> > > >>> Thanks in advance. > > >>> > > >>> -- > > >>> Regards, > > >>> > > >>> Tharindu > > >>> > > >> > > >> > > >> > > >> -- > > >> *Eric Djatsa Yota* > > >> *Double degree MsC Student in Computer Science Engineering and > > >> Communication Networks > > >> Télécom ParisTech (FRANCE) - Politecnico di Torino (ITALY)* > > >> *Intern at AMADEUS S.A.S Sophia Antipolis* > > >> djatsa...@gmail.com > > >> *Tel : 0601791859* > > >> > > >> > > > > > > > > > -- > > > Regards, > > > > > > Tharindu > > > > > > > > > > -- > > Regards, > > > > Tharindu > > -- Regards, Tharindu
