Re: which astyanax version to use?

[Minh Do]

The latest version of Astyanax won't work with Cassandra 2.1+.  So you are
better off using Java Driver from Datastax.

/Minh

On Tue, Nov 17, 2015 at 7:29 PM, Lijun Huang  wrote:

> Hi All,
>
> I have the similar problem, if I use the Cassandra 2.1 version, which
> Astyanax version is the best one for me? For the versions in Astyanax
> Github pages make me a little confused, I need some experience about this.
> Thanks in advance.
>
> Thanks,
> Lijun Huang
>
>
> -- Original --
> *From: * "Lu, Boying";;
> *Date: * Mon, Nov 9, 2015 04:56 PM
> *To: * "user@cassandra.apache.org";
> *Subject: * which astyanax version to use?
>
> Hi, All,
>
>
>
> We plan to upgrade Cassandra from 2.0.17 to 2.1.11 (the latest stable
> release recommended to be used in the product environment) in our product.
>
> Currently we are using Astyanax 1.56.49 as Java client, I found there are
> many new Astyanax at https://github.com/Netflix/astyanax/releases
>
> So which version should we use in a product environment 3.8.0?
>
>
>
> Thanks
>
>
> Boying
>
>
>

Re: ScyllaDB, a new open source, Cassandra-compatible NoSQL

[Minh Do]

First glance at their github, it looks like they re-implemented Cassandra
in C++.  90% components in Cassandra are
in scylladb, i.e. compaction, repair, CQL, gossip, SStable.


With C++, I believe this helps performance to some extent up to a point
when compaction has not run yet.
Then, it will be disk IO to be the dominant factor in the performance
measurement as the more traffics to a node the more degrading
the performance is across the cluster.

Also, they only support Thrift protocol so it won't work with Java Driver
with the new asynchronous protocol.  I doubt their tests
are truly a fair one.

On Tue, Sep 22, 2015 at 2:13 PM, Venkatesh Arivazhagan <
venkey.a...@gmail.com> wrote:

> I came across this article:
> zdnet.com/article/kvm-creators-open-source-fast-cassandra-drop-in-replacement-scylla/
>
> Tzach, I would love to know/understand moree about ScyllaDB too. Also the
> benchmark seems to have only 1 DB Server. Do you have benchmark numbers
> where more than 1 DB servers were involved? :)
>
>
> On Tue, Sep 22, 2015 at 1:40 PM, Sachin Nikam  wrote:
>
>> Tzach,
>> Can you point to any documentation on scylladb site which talks about
>> how/why scylla db performs better than Cassandra while using the same
>> architecture?
>> Regards
>> Sachin
>>
>> On Tue, Sep 22, 2015 at 9:18 AM, Tzach Livyatan <
>> tz...@cloudius-systems.com> wrote:
>>
>>> Hello Cassandra users,
>>>
>>> We are pleased to announce a new member of the Cassandra Ecosystem -
>>> ScyllaDB
>>> ScyllaDB is a new, open source, Cassandra-compatible NoSQL data store,
>>> written with the goal of delivering superior performance and consistent low
>>> latency.  Today, ScyllaDB runs 1M tps per server with sub 1ms latency.
>>>
>>> ScyllaDB  supports CQL, is compatible with Cassandra drivers, and works
>>> out of the box with Cassandra tools like cqlsh, Spark connector, nodetool
>>> and cassandra-stress. ScyllaDB is a drop-in replacement solution for the
>>> Cassandra server side packages.
>>>
>>> Scylla is implemented using the new shared-nothing Seastar
>>>  framework for extreme performance on
>>> modern multicore hardware, and the Data Plane Development Kit (DPDK) for
>>> high-speed low-latency networking.
>>>
>>> Try Scylla Now - http://www.scylladb.com
>>>
>>> We will be at Cassandra summit 2015, you are welcome to visit our booth
>>> to hear more and see a demo.
>>> Avi Kivity, our CTO, will host a session on Scylla on Thursday, 1:50 PM
>>> - 2:30 PM in rooms M1 - M3.
>>>
>>> Regards
>>> Tzach
>>> scylladb
>>>
>>>
>>
>

Re: Exploring Simply Queueing

[Minh Do]

Hi Jan,

Both Chris and Shane say what I believe the correct thinking.

Just let you know if you base your implementation on Netflix's queue
recipe, there are many issues with it.

In general, we don't advise people to use that recipe so I suggest you to
save your time by not going that same route again.


Minh


On Mon, Oct 6, 2014 at 7:34 AM, Shane Hansen  wrote:

> Sorry if I'm hijacking the conversation, but why in the world would you
> want
> to implement a queue on top of Cassandra? It seems like using a proper
> queuing service
> would make your life a lot easier.
>
> That being said, there might be a better way to play to the strengths of
> C*. Ideally everything you do
> is append only with few deletes or updates. So an interesting way to
> implement a queue might be
> to do one insert to put the job in the queue and another insert to mark
> the job as done or in process
> or whatever. This would also give you the benefit of being able to replay
> the state of the queue.
>
>
> On Mon, Oct 6, 2014 at 12:57 AM, Jan Algermissen <
> jan.algermis...@nordsc.com> wrote:
>
>> Chris,
>>
>> thanks for taking a look.
>>
>> On 06 Oct 2014, at 04:44, Chris Lohfink  wrote:
>>
>> > It appears you are aware of the tombstones affect that leads people to
>> label this an anti-pattern.  Without "due" or any time based value being
>> part of the partition key means you will still get a lot of buildup.  You
>> only have 1 partition per shard which just linearly decreases the
>> tombstones.  That isn't likely to be enough to really help in a situation
>> of high queue throughput, especially with the default of 4 shards.
>>
>> Yes, dealing with the tombstones effect is the whole point. The work
>> loads I have to deal with are not really high throughput, it is unlikely
>> we’ll ever reach multiple messages per second.The emphasis is also more on
>> coordinating producer and consumer than on high volume capacity problems.
>>
>> Your comment seems to suggest to include larger time frames (e.g. the
>> due-hour) in the partition keys and use the current time to select the
>> active partitions (e.g. the shards of the hour). Once an hour has passed,
>> the corresponding shards will never be touched again.
>>
>> Am I understanding this correctly?
>>
>> >
>> > You may want to consider switching to LCS from the default STCS since
>> re-writing to same partitions a lot. It will still use STCS in L0 so in
>> high write/delete scenarios, with low enough gc_grace, when it never gets
>> higher then L1 it will be sameish write throughput. In scenarios where you
>> get more LCS will shine I suspect by reducing number of obsolete
>> tombstones.  Would be hard to identify difference in small tests I think.
>>
>> Thanks, I’ll try to explore the various effects
>>
>> >
>> > Whats the plan to prevent two consumers from reading same message off
>> of a queue?  You mention in docs you will address it at a later point in
>> time but its kinda a biggy.  Big lock & batch reads like astyanax recipe?
>>
>> I have included a static column per shard to act as a lock (the ’lock’
>> column in the examples) in combination with conditional updates.
>>
>> I must admit, I have not quite understood what Netfix is doing in terms
>> of coordination - but since performance isn’t our concern, CAS should do
>> fine, I guess(?)
>>
>> Thanks again,
>>
>> Jan
>>
>>
>> >
>> > ---
>> > Chris Lohfink
>> >
>> >
>> > On Oct 5, 2014, at 6:03 PM, Jan Algermissen 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> I have put together some thoughts on realizing simple queues with
>> Cassandra.
>> >>
>> >> https://github.com/algermissen/cassandra-ruby-queue
>> >>
>> >> The design is inspired by (the much more sophisticated) Netfilx
>> approach[1] but very reduced.
>> >>
>> >> Given that I am still a C* newbie, I’d be very glad to hear some
>> thoughts on the design path I took.
>> >>
>> >> Jan
>> >>
>> >> [1] https://github.com/Netflix/astyanax/wiki/Message-Queue
>> >
>>
>>
>