incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Kutcharian <d...@venarc.com>
Subject Re: 2.0
Date Mon, 03 Dec 2012 03:57:45 GMT
I agree with Edward here. We use Thrift too and we haven't really found a good enough reason
to move to CQL3.

-- Drew

On Dec 1, 2012, at 10:24 AM, Edward Capriolo <edlinuxguru@gmail.com> wrote:

> I do not understand why everyone wants to force this issue on removing
> thrift. If cql, cql sparse tables and the new transport are better people
> will naturally begin to use them, but as it stands now I see the it
> this way:
> 
> Thrift still has more clients for more languages, thrift has more higher
> level clients for more languages.
> Thrift has Hadoop support hive support and pig support in the wild.
> Thrift has third party tools like Orm tools, support for tools like flume.
> 
> Most of cql3 features like collections do not work with compact tables,
> and compact tables are much more space efficient then their cql3 sparse
> counterparts, composite rows with UTf column names, blank rows, etc.
> Cql3 binary client is only available for in beta stage for a few languages.
> 
> So the project can easily remove thrift today but until a majority of the
> tooling by the community adopts the transport and for the most part cqls
> sparse tables it is not going to mean anything. Many people already have
> code live in production working fine with the old toolset and will be
> unwilling to convert something just because....
> 
> Think about it like this a company like mine that already has something in
> production. Even if you could convince me us that cql native transport was
> better, which by the way no one has showed me a vast performance reason to
> this point, they still may not want to invest the resources to convert
> their app. Many companies endured the painful transition from Cassandra 0.6
> to Cassandra 0.7 conversion and they are not eagerly going to entertain
> another change which is mostly cosmetic.
> 
> Also I find issues like this extremely frustrating.
> https://issues.apache.org/jira/browse/CASSANDRA-4924
> 
> It seems like the project is drawing a hard line in the sand dividing
> people. Is it the case that cql3's sparse tables can't be accessed
> by thrift, or is it the case that no one wants to make this happen? Like is
> it technically impossible? It seems not to me in Cassandra
> Row key, column, and value are all still byte arrays right? So I do not see
> why thrift users need to be locked out of them. Just like composites we
> will figure out how to pack the bytes.
> 
> I hope that we can stop talking about removing thrift until there is some
> consensus between active users that it is not in use anymore.
> This consensus is not as simple as n committers saying that something is
> technically not needed anymore. It has to look at the users, the number of
> clients, the number of languages, the number of high level tools available.
> In the mean time when issues like 4924 pop up it would be better if people
> tried to find solutions for maximum forward and backward compatibility
> instead of drawing a line and trying to shut thrift users out of things.
> 
> Avro was much the same way . I had a spirited debate on irc and got
> basicallly insulted because i belived thrift was not dead. The glory of
> avro never came true because it really did not work for clients outside a
> few languages. Cql and the binary transport has to pass this same litmus
> test. Let it gain momentum and have rock solid clients for 5 languages and
> have higher level tools written on top of it then its easy to say thrift is
> not needed anymore.
> 
> 
> On Saturday, December 1, 2012, Sylvain Lebresne wrote:
> 
>> I agree on 2.0.
>> 
>> For the thrift part, we've said clearly that we wouldn't remove it any time
>> soon so let's stick to that. Besides, I would agree it's too soon anyway.
>> What we can do however in the relatively short term on that front, is to
>> pull thrift in it's own jar (we've almost removed all internal dependencies
>> on thrift, and the few remaining ones will be easy to kill) and make that
>> jar optional if you don't want to use it.
>> 
>> --
>> Sylvain
>> 
>> 
>> On Sat, Dec 1, 2012 at 2:52 AM, Ray Slakinski <ray.slakinski@gmail.com<javascript:;>
>>> wrote:
>> 
>>> I agree, I don't think its a great idea to drop thrift until the back
>>> end tools are 100% compatible and have some level of agreement from the
>>> major users of
>>> Cassandra.
>>> 
>>> Paying off technical dept though I'm all for, and I think its key to the
>>> long term success of the application. Right now Supercolumns to someone
>>> new coming to the system might think "Hey, these things look great. Lets
>>> use them" and in a few months time hate all things that are cassandra.
>>> 
>>> Ray Slakinski
>>> 
>>> On 12/01, Jonathan Ellis wrote:
>>>> As attractive as it would be to clean house, I think we owe it to our
>>>> users to keep Thrift around for the forseeable future rather than
>>>> orphan all Thrift-using applications (which is virtually everyone) on
>>>> 1.2.
>>>> 
>>>> On Sat, Dec 1, 2012 at 7:33 AM, Jason Brown <jasedbrown@gmail.com<javascript:;>
>>> 
>>> wrote:
>>>>> Hi Jonathan,
>>>>> 
>>>>> I'm in favor of paying off the technical debt, as well, and I wonder
>> if
>>>>> there is value in removing support for thrift with 2.0? We're
>>> currently in
>>>>> 'do as little as possible' mode with thrift, so should we
>> aggressively
>>> cast
>>>>> it off and push the binary CQL protocol? Seems like a jump to '2.0',
>>> along
>>>>> with the other initiatives, would be a reasonable time/milestone to
>> do
>>> so.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> -Jason
>>>>> 
>>>>> 
>>>>> On Fri, Nov 30, 2012 at 12:12 PM, Jonathan Ellis <jbellis@gmail.com<javascript:;>
>>> 
>>> wrote:
>>>>> 
>>>>>> The more I think about it, the more I think we should call 1.2-next,
>>>>>> 2.0.  I'd like to spend some time paying off our technical debt:
>>>>>> 
>>>>>> - replace supercolumns with composites (CASSANDRA-3237)
>>>>>> - rewrite counters (CASSANDRA-4775)
>>>>>> - improve storage engine support for wide rows
>>>>>> - better stage management to improve latency (disruptor? lightweight
>>>>>> threads?  custom executor + queue?)
>>>>>> - improved repair (CASSANDRA-3362, 2699)
>>>>>> 
>>>>>> Of course, we're planning some new features as well:
>>>>>> - triggers (CASSANDRA-1311)
>>>>>> - improved query fault tolerance (CASSANDRA-4705)
>>>>>> - row size limits (CASSANDRA-3929)
>>>>>> - cql3 integration for hadoop (CASSANDRA-4421)
>>>>>> - improved caching (CASSANDRA-1956, 2864)
>>>>>> 
>>>>>> --
>>>>>> Jonathan Ellis
>>>>>> Project Chair, Apache Cassandra
>>>>>> co-founder, http://www.datastax.com
>>>>>> @spyced
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Jonathan Ellis
>>>> Project Chair, Apache Cassandra
>>>> co-founder, http://www.datastax.com
>>>> @spyced
>>> 
>> 


Mime
View raw message