Return-Path: X-Original-To: apmail-ignite-user-archive@minotaur.apache.org Delivered-To: apmail-ignite-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E6DDC177E2 for ; Thu, 17 Sep 2015 10:11:49 +0000 (UTC) Received: (qmail 12120 invoked by uid 500); 17 Sep 2015 10:11:49 -0000 Delivered-To: apmail-ignite-user-archive@ignite.apache.org Received: (qmail 12079 invoked by uid 500); 17 Sep 2015 10:11:49 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 12069 invoked by uid 99); 17 Sep 2015 10:11:49 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Sep 2015 10:11:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5B2DAF376C for ; Thu, 17 Sep 2015 10:11:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.88 X-Spam-Level: ** X-Spam-Status: No, score=2.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id JU5QCFYOTFdc for ; Thu, 17 Sep 2015 10:11:40 +0000 (UTC) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id A859D20F6D for ; Thu, 17 Sep 2015 10:11:39 +0000 (UTC) Received: by vkao3 with SMTP id o3so7789942vka.2 for ; Thu, 17 Sep 2015 03:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xoBeaXJ4s5q3/vKr/u1WJtKjJNHhPwETho45YY2OZCs=; b=GvL2KZIhb7rXEBUrFQ52IJQwmScCPBunZipckaPMzsTg6u1PPFAONZ1L5go8EuwZU5 qGigi+9nAEo8pLt7vvE1+BnEz+O+sAo3O33HaiMidXP6YwWD4xMn8G6V+c6m6yKpkQzh sBhORrp5fhR36rwnNGK8dr/S1rQ2570wAbgZJSP5zjcMlFfvXhKYLYQzRb1+ZkkEf37M cCL/SMASg1Kz8kNhDHyC4tT6EynryuLrMt16g4cbbubWkiwi5t73+LX+scdPomnyzdiA 4OP1GxjcMGIp2yTKQIgRTAujhAozDHIzcDttbQvfAx34cuprVFiVxyOdvSdmPyxurFEI 6CwA== X-Received: by 10.31.34.7 with SMTP id i7mr32610606vki.60.1442484698466; Thu, 17 Sep 2015 03:11:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.48.76 with HTTP; Thu, 17 Sep 2015 03:10:59 -0700 (PDT) In-Reply-To: References: <1442432722520-1421.post@n6.nabble.com> <1442433735529-1422.post@n6.nabble.com> <1442440694405-1424.post@n6.nabble.com> <1442441957593-1425.post@n6.nabble.com> From: Sergi Vladykin Date: Thu, 17 Sep 2015 13:10:59 +0300 Message-ID: Subject: Re: Btw anyone heard of CQ engine? To: user@ignite.apache.org Content-Type: multipart/alternative; boundary=001a113dc8b80bce31051feea472 --001a113dc8b80bce31051feea472 Content-Type: text/plain; charset=UTF-8 Dmitriy, Time ago we've tested SkipList index implementation which is not snapshotable against our SnapTree and we did not notice any speedups. Sergi 2015-09-17 6:31 GMT+03:00 Dmitriy Setrakyan : > > > On Thu, Sep 17, 2015 at 2:58 AM, Alexey Kuznetsov > wrote: > >> If it is not snapsohtable there could be at least one use-case: populated >> once and never changed cache. >> For example for some analytics. >> User populate 100500 entries into cache, build index and run 100500 >> queries. >> >> > I agree with Alexey. If disabling snapshots provides any kind of > performance optimization for us, we should probably support 2 modes, > snapshotttable and not, at least at configuration level. I am sure that > there are plenty of users that don't care about snapshots, even in the > presence of concurrent updates. > > From the feature standpoint, I don't see anything in CQEngine that Ignite > does not have in its SQL queries. However, from the performance standpoint, > I still think that it is worthwhile to check out the CQ Engine code and see > if we there is anything we can borrow. > > > >> On Thu, Sep 17, 2015 at 6:27 AM, Sergi Vladykin > > wrote: >> >>> Thanks for the pointers! >>> The main difficulty at Ignite side is that we need >>> index data structure to be snapshotable with O(1) complexity and of >>> course >>> without copying of the whole thing, so I'm not sure if we will be able >>> to use something from there as is. >>> But nevertheless CQEngine at least deserves to be investigated for ideas >>> about data structures. >>> >>> Sergi >>> >>> >>> 2015-09-17 1:19 GMT+03:00 vkulichenko : >>> >>>> javadevmtl wrote >>>> > Yeah it's perforamance is crazy. I hadn't experienced any "buggy" >>>> issues >>>> > when i tried. it also has off-heap otion now also. But I find the >>>> concept >>>> > of O(1) indexes very interesting... >>>> >>>> I think that O(1) is achievable only for hash indexes and therefore can >>>> be >>>> used only for equality queries. This is a very rare case in SQL and can >>>> barely be treated as a replacement of tree indexes. >>>> >>>> -Val >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://apache-ignite-users.70518.x6.nabble.com/Btw-anyone-heard-of-CQ-engine-tp1421p1425.html >>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >>>> >>> >>> >> >> >> -- >> Alexey Kuznetsov >> GridGain Systems >> www.gridgain.com >> > > --001a113dc8b80bce31051feea472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dmitriy,

Time ago we've tested SkipLi= st index implementation which is not snapshotable against our SnapTree and = we did
not notice any speedups.

Sergi
=

2015-09-17 = 6:31 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>= :


On Thu, Sep 17, 20= 15 at 2:58 AM, Alexey Kuznetsov <akuznetsov@gridgain.com> wrote:
If it is not = snapsohtable there could be at least one use-case: populated once and never= changed cache.
For example for some analytics.
User populate= 100500 entries into cache, build index and run 100500 queries.
=


I agree with Alexey. If disabling snapshots provide= s any kind of performance optimization for us, we should probably support 2= modes, snapshotttable and not, at least at configuration level. I am sure = that there are plenty of users that don't care about snapshots, even in= the presence of concurrent updates.

From the feat= ure standpoint, I don't see anything in CQEngine that Ignite does not h= ave in its SQL queries. However, from the performance standpoint, I still t= hink that it is worthwhile to check out the CQ Engine code and see if we th= ere is anything we can borrow.

<= div>=C2=A0
<= div>
On Thu, Sep 17, 2015 at 6:27 AM, Sergi = Vladykin <sergi.vladykin@gmail.com> wrote:
Thanks for the poin= ters!
The main difficulty at Ignite side is that we need
index data structure to be snapshotable with O(1) complexity and of cours= e
without copying of the whole thing, so I'm not sure if we will be = able
to use something from there as is.
But nevertheless= CQEngine at least deserves to be investigated for ideas
about data str= uctures.

Sergi
=C2=A0

2015-09-17 1:19 GMT+03:00 vkulichenko <valentin.kulichenko@gmail.com>:
javadevmtl wrote
> Yeah it's perforamance is crazy. I hadn't experienced an= y "buggy" issues
> when i tried. it also has off-heap otion now also. But I find the conc= ept
> of O(1) indexes very interesting...

I think that O(1) is achievable only for hash indexes and therefore = can be
used only for equality queries. This is a very rare case in SQL and can
barely be treated as a replacement of tree indexes.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Btw-a= nyone-heard-of-CQ-engine-tp1421p1425.html
Sent from the Apache Ignite Users mailing list archive at Nabble.= com.




<= /div>--
Alexey Kuznetsov
GridGai= n Systems
www.grid= gain.com


--001a113dc8b80bce31051feea472--