<div dir="ltr">Somehow I missed that thread.<div><br></div><div>Great news !</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 10:54 PM, Lukas Krejci <span dir="ltr"><<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Titan does not use the lightweight transactions of Cassandra, but<br>
instead uses a locking mechanism of its own making [1]. We use some of<br>
those mechanisms to ensure the consistency but frankly I've not done too<br>
much research into all the failure scenarios that might happen (this is<br>
definitely something we'd like to add to our perf tests, hint hint<br>
jkremser ;) ).<br>
<br>
IMHO the change in the performance I've seen in the perf tests after the<br>
fixes in Inventory have more to do with caching of data that Titan does<br>
within a transaction boundary than some perf improvements gained from<br>
the backends.<br>
<br>
[1] <a href="http://s3.thinkaurelius.com/docs/titan/0.5.0/eventual-consistency.html" rel="noreferrer" target="_blank">http://s3.thinkaurelius.com/docs/titan/0.5.0/eventual-consistency.html</a><br>
<span class=""><br>
On 02/23/2016 08:53 PM, John Sanda wrote:<br>
> Lukas do you have any insight into how Titan supports transactions with<br>
> Cassandra? I know that Titan still uses the thrift API,which presumably<br>
> rules out the light weight transactions introduced in C* 2.0. These are<br>
> not to be confused with ACID transactions. It is more of an atomic<br>
> update using a consensus protocol. Then you have atomic or logged<br>
> batches which are atomic in the sense that either all of the statements<br>
> will succeed or none will; however, they can succeed *eventually*. These<br>
> have more overhead than unlogged batches because the mutations are first<br>
> written to a batch log. Applying multiple mutations to the same<br>
> partitions is an atomic operation. In other words, whether you update 1<br>
> or 50 columns, if it is done within the same partition (and within the<br>
> same operation), it is atomic.<br>
><br>
> My point being that Cassandra is definitely not a transactional data<br>
> store, so I am really curious about what Titan is doing.<br>
><br>
>> On Feb 23, 2016, at 1:48 PM, Lukas Krejci <<a href="mailto:lkrejci@redhat.com">lkrejci@redhat.com</a><br>
</span><div><div class="h5">>> <mailto:<a href="mailto:lkrejci@redhat.com">lkrejci@redhat.com</a>>> wrote:<br>
>><br>
>><br>
>><br>
>> On 02/23/2016 07:42 PM, Jay Shaughnessy wrote:<br>
>>><br>
>>> Lukas,<br>
>>><br>
>>> That's excellent news. Multiple backends is not something we really<br>
>>> want to deal with. Also, it might be nice to see a short presentation<br>
>>> on the "best practices" for Tx handling. But then again, that Tx stuff<br>
>>> is handled at the Gremlin level? So, perhaps not relevant to direct C*<br>
>>> consumers like Alerts.<br>
>>><br>
>><br>
>> You're right. Inventory uses Gremlin to handle transactions, so it<br>
>> doesn't directly "see" what is Titan doing behind the scenes.<br>
>><br>
>>> On 2/23/2016 12:43 PM, Lukas Krejci wrote:<br>
>>>> Hi all,<br>
>>>><br>
>>>> lately I've become really dissatisfied with how Inventory performed and<br>
>>>> semi-publicly blamed Titan for that (because that was what looked like<br>
>>>> the cause of all world's problems in my then uneducated eyes ;) ).<br>
>>>><br>
>>>> I decided to do some performance comparisons. Because we didn't want<br>
>>>> Hawkular to ship with 2 different NoSQL backends (C* for metrics and<br>
>>>> whatever else for Inventory), I chose an RDBMS as a good conservative<br>
>>>> alternative (because people, IMHO, are still more comfortable dealing<br>
>>>> with an RDBMS than with NoSQL databases).<br>
>>>><br>
>>>> Currently, inventory is written against the graph DSL called Gremlin<br>
>>>> (from Tinkerpop 2.6.0). Fortunately, there exists a "toy" SQL backend<br>
>>>> for Tinkerpop 2 that we could try and see if it performed any good<br>
>>>> (which would frankly be surprising, given the fact it stores the graph<br>
>>>> data rather naively). With some luck, no code would have to be changed<br>
>>>> on our side to see the results.<br>
>>>><br>
>>>> We had no such luck.<br>
>>>><br>
>>>> Making the inventory run with the SQL backend was literally a day worth<br>
>>>> of work (if that) and the first preliminary tests showed that Inventory<br>
>>>> with Postgres backend performed much much better that Titan with<br>
>>>> embedded Cassandra. But the tests also uncovered some problems with the<br>
>>>> way Inventory code handled transactions.<br>
>>>><br>
>>>> Fast forward 3 weeks and see large parts of Hawkular inventory updated<br>
>>>> to correctly handle transactions. Now a single call to Inventory really<br>
>>>> results in at most 1 transaction in the backend.<br>
>>>><br>
>>>> So, I went and re-ran the tests. Also, I refrained from using embedded<br>
>>>> Cassandra and instead use a locally running 2-node cluster.<br>
>>>><br>
>>>> The results caught me by surprise. Not so much that the naive SQL<br>
>>>> backend didn't perform particularly well, but the difference between the<br>
>>>> performance of Titan before and after the transaction handling fixes.<br>
>>>><br>
>>>> To not keep you waiting any longer for the results: Titan + C* is the<br>
>>>> winner.<br>
>>>><br>
>>>> For nice charts that include comparison to the old misbehaving impl,<br>
>>>> see:<br>
>>>> <a href="https://dashboards.ly/ua-tALzrY9rEoRBXvsLXbZJHT" rel="noreferrer" target="_blank">https://dashboards.ly/ua-tALzrY9rEoRBXvsLXbZJHT</a><br>
>>>><br>
>>>> Cheers,<br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> hawkular-dev mailing list<br>
</div></div>>>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>><br>
<span class="">>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
>>><br>
>><br>
>> --<br>
>> Lukas Krejci<br>
>> _______________________________________________<br>
>> hawkular-dev mailing list<br>
</span>>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
> _______________________________________________<br>
> hawkular-dev mailing list<br>
> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
><br>
<br>
--<br>
Lukas Krejci<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>