Re: Professional Support
Thanks for sharing the info.. though I contacted datastax using contact form but no reply yet after more than a week. Probably I need to contact Ben directly. From: Ben Coverston To: user@cassandra.apache.org Sent: Tuesday, September 6, 2011 11:15 PM Subject: Re: Professional Support We were glad to help William, thanks for sharing! On Tue, Sep 6, 2011 at 12:13 PM, William Oberman wrote: I also have used datastax with great success (same disclaimer). > > >A specific example: > >-I setup a one-on-one call to talk through an issue, in my case a server >reconfiguration. It took 2 days to find a time to meet, though that was my >fault as I believe they could have worked me in within a day. I wanted to >split an existing cluster into 'oltp' and 'analytics', similar to what brisk >does now out of the box. >-During the call they walked me through all of the steps I'd have to do, >answered any questions I had, and filled in the blanks for some of the >reasoning behind their recommendations. >-After the call I recieved constant support through the reconfiguration. For >example: I found out that Ec2Snitch doesn't play nicely with >PropertyFileSnitch in a rolling restart (all of the Ec2Snitch based servers >stopped working immediately as soon as a PropFileSnitch server joined the >ring, this is in 0.8.4), and they wrote a custom patch for me that made it >work within a day. >-In particular, Ben and Jackson helped me, so if either of you read the user >list, thanks again! > > >will > > > >On Tue, Sep 6, 2011 at 1:25 PM, Jim Ancona wrote: > >We use Datastax (http://www.datastax.com) and we have been very happy >>with the support we've received. >> >>We haven't tried any of the other providers on that page, so I can't >>comment on them. >> >>Jim >>(Disclaimer: no connection with Datastax other than as a satisfied customer.) >> >> >>On Tue, Sep 6, 2011 at 1:15 PM, China Stoffen wrote: >>> There is a link to a page which lists few professional support providers on >>> Cassandra homepage. I have contacted few of them and couple are just out of >>> providing support and others didn't reply. So, do you know about any >>> professional support provider for Cassandra solutions and how much they >>> charge per year? >>> >> > >
Professional Support
There is a link to a page which lists few professional support providers on Cassandra homepage. I have contacted few of them and couple are just out of providing support and others didn't reply. So, do you know about any professional support provider for Cassandra solutions and how much they charge per year?
Re: commodity server spec
>>In general, more smaller is better than fewer big. Probably go for >>what's cost-effective. Cost effective solution is few and fat servers because it also saves hosting cost. >>The exception to that would be if you're truly only caring about >>writes and have *very* few reads that are not latency critical (so >>you're okay with waiting for several disk seeks on reads and the >>number of reads is low enough that serving them from platters will >>work). In such cases it might make sense to have fewer Big Fat >>Machines with lots of memory and a lot of disk space. But... even so. >>I would not recommend huge 48 tb nodes... unless you really know what >>you're doing. I want writes should be as fast as possible but reads are not necessary to be in milliseconds. If you don't recommend 48tb then how much max disk space I can go with? ----- Original Message - From: Peter Schuller To: user@cassandra.apache.org; China Stoffen Cc: Sent: Saturday, September 3, 2011 1:08 PM Subject: Re: commodity server spec > Is there any recommendation about commodity server hardware specs if 100TB > database size is expected and its heavily write application. > Should I got with high powered CPU (12 cores) and 48TB HDD and 640GB RAM and > total of 3 servers of this spec. Or many smaller commodity servers are > recommended? In general, more smaller is better than fewer big. Probably go for what's cost-effective. In your case, 100 TB is *quite* big. I would definitely recommend against doing anything like your 3 server setup. You'll probably want 100-1000 small servers. The exception to that would be if you're truly only caring about writes and have *very* few reads that are not latency critical (so you're okay with waiting for several disk seeks on reads and the number of reads is low enough that serving them from platters will work). In such cases it might make sense to have fewer Big Fat Machines with lots of memory and a lot of disk space. But... even so. I would not recommend huge 48 tb nodes... unless you really know what you're doing. In reality, more information about your use-case would be required to offer terribly useful advice. -- / Peter Schuller (@scode on twitter)
Re: commodity server spec
Then what will be the sweetspot for Cassandra? I am more interested in Cassandra because my application is write heavy. Till now what I have understood is that Cassandra will not work best for SANs too? P.S Mongodb is also a nosql database and designed for horizontal scaling then how its good for the same hardware for which Cassandra is not a good candidate? - Original Message - From: Bill To: user@cassandra.apache.org Cc: Sent: Sunday, September 4, 2011 4:34 AM Subject: Re: commodity server spec [100% agree with Chris] China, the machines you're describing sound nice for mongodb/postgres/mysql, but probably not the sweetspot for Cassandra. Obviously (well depending on near term load) you don't want to get burned on excess footprint. But a realistic, don't lose data, be fairly available deployment is going to span at least 2 racks/power supplies and have data replicated offsite (at least as passive for DR). So I would consider 6-9 relatively weaker servers rather than 3 scale up joints. You'll save some capex, and the amount of opex overhead is probably worth it traded off against the operational risk. 3 is an awkward number to operate for anything that needs to be available (although many people seem to start with that, I am guessing because triplication is traditionally understood under failure) as it immediately puts 50% extra load on the remaining 2 when one node goes away. One will go away, even transiently, when it is upgraded, crashes, gets into a funk due to compaction or garbage collection, and load will then be shunted onto the other 2 - remember Cassandra has no backoff/throttling in place. I'd allow for something breaking at some point (dbs even the mature ones, fail from time to time) and 2 doesn't give you much room to maneuver in production. Bill On 03/09/11 23:05, Chris Goffinet wrote: > It will also depend on how long you can handle recovery time. So imagine > this case: > > 3 nodes w/ RF of 3 > Each node has 30TB of space used (you never want to fill up entire node). > If one node fails and you must recover, that will take over 3.6 days in > just transferring data alone. That's with a sustained 800megabit/s > (100MB/s). In the real world it's going to fluctuate so add some > padding. Also, since you will be saturating one of the other nodes, now > you're network latency performance is suffering and you only have 1 > machine to handle the remaining traffic while you're recovering. And if > you want to expand the cluster in the future (more nodes), the amount of > data to transfer is going to be very large and most likely days to add > machines. From my experience it's must better to have a larger cluster > setup upfront for future growth than getting by with 6-12 nodes at the > start. You will feel less pain, easier to manage node failures (bad > disks, mem, etc). > > 3 nodes with RF of 1 wouldn't make sense. > > > On Sat, Sep 3, 2011 at 4:05 AM, China Stoffen <mailto:chinastof...@yahoo.com>> wrote: > > Many small servers would drive up the hosting cost way too high so > want to avoid this solution if we can. > > - Original Message - > From: Radim Kolar mailto:h...@sendmail.cz>> > To: user@cassandra.apache.org <mailto:user@cassandra.apache.org> > Cc: > Sent: Saturday, September 3, 2011 9:37 AM > Subject: Re: commodity server spec > > many smaller servers way better > >
Re: commodity server spec
Many small servers would drive up the hosting cost way too high so want to avoid this solution if we can. - Original Message - From: Radim Kolar To: user@cassandra.apache.org Cc: Sent: Saturday, September 3, 2011 9:37 AM Subject: Re: commodity server spec many smaller servers way better
commodity server spec
Hi, Is there any recommendation about commodity server hardware specs if 100TB database size is expected and its heavily write application. Should I got with high powered CPU (12 cores) and 48TB HDD and 640GB RAM and total of 3 servers of this spec. Or many smaller commodity servers are recommended? Thanks. China
