From dev-return-40662-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Thu Oct 18 11:07:39 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id A0AEE18064E for ; Thu, 18 Oct 2018 11:07:38 +0200 (CEST) Received: (qmail 1074 invoked by uid 500); 18 Oct 2018 09:07:37 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 1056 invoked by uid 99); 18 Oct 2018 09:07:36 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Oct 2018 09:07:36 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 76187C1A75 for ; Thu, 18 Oct 2018 09:07:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.302 X-Spam-Level: *** X-Spam-Status: No, score=3.302 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id D9Yq9Dk6MwXA for ; Thu, 18 Oct 2018 09:07:34 +0000 (UTC) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 4AACB5F23D for ; Thu, 18 Oct 2018 09:07:33 +0000 (UTC) Received: by mail-vs1-f45.google.com with SMTP id c205so22603832vsd.3 for ; Thu, 18 Oct 2018 02:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+ffHQ/fN7qUj243JWJhxpJPHHo6p/gfdWhZZJryAeF0=; b=n+lQKYS2nU6PrUbWiEdsnana7dXXBq4mUoTdaax65DXaCTDxxcbUvlDW4eIwzPupLk C5Zg+E4rNx2wBIcWjSGa03T+D1ZMY23IYdoEZIT19V8I3shgD+deBNL5Ige6enJs1H/r Vd8Dzu4eD8+miVBbFokzU/rNtK7oYRkLPlpqJ+C0l7/OrvEajra+7xzTcoFEt5tXVfyS SqklcQfE1gNUMbS5RXMv8IZj7HUfub7600NByGJrOmjN5ZnaJk2qtvfMJHxHUvL4sRiS SnyxHidppm+N5I7lV/w8YJa8j9YdxtL9ANDV7FoLSPjVvv1i27/czPXppun7JFQ3Mk/7 TWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+ffHQ/fN7qUj243JWJhxpJPHHo6p/gfdWhZZJryAeF0=; b=p86ZGTBCc7xzHYphWBNXepFz8iy6WC4n/gyGULZVdeBr5B24xFdwuMP9NHDZFZ8BKY 5OBbhW8vjR5/90tKUIjwRka/NWPMab1mxJZFrvwXF5tiNdUpiwrehGpBiOdj09UtOmVB IvjpxkK6IpOxYSPt+3HSKndT7wHoPXVvvCRv9CuOnSyRsq02xO+UO+uzR0dYKoWmn6NC uD24MU8OE4h94yGc18Do3T8m2dPZKhKwz78uY+GEqng/l4NoYMsKzZ5ctqMELoBNjMHA lFWvf8Bm9AFR4RvmZRqoNIviD7oMe1fO+sekqhxkr65svyR7j1hvemtRd0POhUWC5SGx 9MFA== X-Gm-Message-State: ABuFfoiaRoA1o81AO87EHl/z1ECK2ich+qwqhHmAim5nHbGzNSd1tFO5 HhzD59b/tQTg8aubqrxlOE3rbgOzwVJdkeWybs04HONu8Lg= X-Google-Smtp-Source: ACcGV63+ONYvd8em6JW+Pn86yNxUuiuemfx6AZjWqk0CwVlMObybjMsLr48M3LNn1pwYRH/GoaI/h7OMl8NTfTAj1tM= X-Received: by 2002:a67:6ec5:: with SMTP id j188mr12207440vsc.186.1539853651749; Thu, 18 Oct 2018 02:07:31 -0700 (PDT) MIME-Version: 1.0 References: <1539793187693-0.post@n4.nabble.com> In-Reply-To: From: Vladimir Ozerov Date: Thu, 18 Oct 2018 12:07:19 +0300 Message-ID: Subject: Re: SQL Engine To: dev Content-Type: multipart/alternative; boundary="000000000000eb498a05787d1dd8" --000000000000eb498a05787d1dd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Igor, What Ignite version do you use? Recent versions do not read real rows for the simplest "SELECT COUNT(*) FROM table" query. Instead it goes over index and simply count records, so no copying happens. But let me express again - this is not the case in general. If any expression appears, we have to read the row from offheap. In this case the whole key-value pair is read from offheap including non-SQL fields. This is so because we do not know in advance what parts of key or value will be needed. Even if specific field is not marked as @QuerySqlField, it may be needed if the whole key or value is requested ("SELECT _KEY FROM table"), or if it is used in some custom function, etc.. In future versions we may re-approach this, and try to read only fields required for query from offheap. But this will require significant changes to both storage layer and query engine, so this is not an easy task. On Thu, Oct 18, 2018 at 2:42 AM Igor Tanackovic wrote: > Dmitriy, > > Correct me if I=E2=80=99m wrong, but the concept is to store everything o= ff heap - > which is perfectly fine :). So, the question is how SQL engine actually > works. Analyzing profiler object generation and sizes on heap, I=E2=80=99= ve learned > that for each query entire rows in question are copied on heap which, I= =E2=80=99d > say is a little bit inefficient (more or less depending on domain object)= . > Maybe an example will help to further elaborate on the issue. > > Lets say we have an object ORGANIZATION which has only two query enabled > fields (annotated with @QuerySqlField) and 20 more value fields > (text/blobs, =E2=80=A6) which are not used in queries (not annotated with > @QuerySqlField and thus not visible by SQL engine). So, how COUNT works? > Will SQL engine copy on heap just a part of ORGANIZATION rows (2 fields > that might be part of COUNT query) or entire rows (sql enabled fields + > text/blob fields=E2=80=A6)? > > From what I saw during profiling, I=E2=80=99d say entire rows will be cop= ied on > heap. Just to compare, this is our, real world example: > > Object A (~300k rows, each row has 5 columns, all sql enabled), COUNT(*) > takes ~2MB on heap > Object B (~25k rows, each row has 16 columns, 5 sql enabled fields and 11 > text value fields), COUNT(*) takes ~60MB on heap - nearly 30 times more > > > Regards, > Igor > > > > > On Oct 18, 2018, at 12:24 AM, Dmitriy Setrakyan > wrote: > > > > I do not understand - why are we copying values on-heap? If we must cop= y > > something, why not copy rows into some off-heap space and read what we > have > > from there? At least this way we will not burden the JVM with extra GC > > pressure. > > > > D. > > > > On Wed, Oct 17, 2018 at 10:33 AM Igor Tanackovic < > igor.tanackovic@gmail.com> > > wrote: > > > >> Vladimir, > >> > >> Thanks for explanation... that=E2=80=99s true - ignite never deseriali= ze values > >> during query execution. The point here is why copying fields to heap > that > >> sql engine could not use (not annotated as QuerySqlField)? > >> SQL count is a perfect example where you can benefit (heap space and g= c) > >> copying only field sql engine could use. > >> > >> Regards, > >> Igor > >> > >> On Wed, Oct 17, 2018 at 18:47 Vladimir Ozerov > >> wrote: > >> > >>> Hi Igor, > >>> > >>> We never deserialize values during query execution. Instead, we copy > the > >>> row to heap and extract fields as needed. In general case it is > >> impossible > >>> to avoid reading the whole row because we do not know whether this is > >>> COUNT(*) or COUNT(*) WHERE or COUNT() WHERE > >>> . > >>> We do handle plain COUNT(*) as speical case and iterate over index > only, > >>> but event this simple query cannot avoid row reads in general case wh= en > >> new > >>> snapshot mode is enabled, because an entry in the index may be not > >> visible > >>> to current transaction. > >>> > >>> On Wed, Oct 17, 2018 at 7:19 PM igor.tanackovic < > >> igor.tanackovic@gmail.com > >>>> > >>> wrote: > >>> > >>>> Hello, > >>>> > >>>> Seems that SQL engine always deserialize whole objects instead of > using > >>>> just > >>>> SQL enabled fields (annotated with @QuerySqlField). This may have a > >> huge > >>>> impact on Ignite heap usage and GC overhead as well. > >>>> > >>>> For example, we have a cache holding big objects but with only two s= ql > >>>> query > >>>> fields which for each query execution (SELECT COUNT(*) FROM 'cache') > >>>> consumes large amount on heap memory (~300MB). As a proof of concept= , > >> we > >>>> divided the same cache to *index* cache with only sql query field an= d > a > >>>> *data* holding whole object for materialization. The same query > (SELECT > >>>> COUNT(*) FROM 'index-cache') consumes ~25 time less memory! The same > is > >>>> true > >>>> for all other queries. > >>>> > >>>> The obvious workaround would be to always have separated regions for > >>>> indexes > >>>> (sql query enabled region) and a data/value region for > materialization, > >>> but > >>>> it might be a good idea to fix this in a systematic way during off > heap > >>>> deserialization. > >>>> > >>>> Regards, > >>>> Igor > >>>> > >>>> > >>>> > >>>> -- > >>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > >>>> > >>> > >> > > --000000000000eb498a05787d1dd8--