From user-return-59350-archive-asf-public=cust-asf.ponee.io@cassandra.apache.org Wed Jan 10 15:52:55 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 11C0918072F for ; Wed, 10 Jan 2018 15:52:55 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 01E0A160C2E; Wed, 10 Jan 2018 14:52:55 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 0B2F7160C23 for ; Wed, 10 Jan 2018 15:52:53 +0100 (CET) Received: (qmail 62239 invoked by uid 500); 10 Jan 2018 14:52:52 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 62228 invoked by uid 99); 10 Jan 2018 14:52:52 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jan 2018 14:52:52 +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 96101C2561 for ; Wed, 10 Jan 2018 14:52:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id cjHOF9SpXKcv for ; Wed, 10 Jan 2018 14:52:50 +0000 (UTC) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id E16FC5FB93 for ; Wed, 10 Jan 2018 14:52:49 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id l63so11680004vke.5 for ; Wed, 10 Jan 2018 06:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xlPLaTPtdP05/6XuBYJDw0/sWy+XE7mLIwHmVtet6SA=; b=R9j/uuUiO+MKwTULVSEJccBLvAS6VLuYR2ESEXATj7TZaR2F0K7QFtKQih0+4A3h/0 /i8kw6VpfIKwh5SLuA2NDgX0yShczRow0EJyfx9byE6WrukMyksJnNpWxFbgIGl1iK2R t/YWxAHNdV2R3+LT2c+K4EL3F40eEs0sjOc7zaibE/xDtWNN3vdA+wFH1X+G2ZlF3nfR b4kaw/zyXK5NWrj0U+pkTL2LURTODa8GXb8Owxpx2EsgeJMsGP8n+Se2tm/j96tB2qUZ 069Xp6jVUteH/4kb4M7Rub2psIirQMHxD56yst3TIWA5gKDfj5mkBsk6h5+3eoD33TgA g1rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xlPLaTPtdP05/6XuBYJDw0/sWy+XE7mLIwHmVtet6SA=; b=gTLOSJo9qC+pR9ZV/y0ifNlizqU0/dzG4rFegrYaFqcuwZV3BuRhKh6LlYCN3EliM9 9TevvG4/nuDUKfoDPQMf+qd4Ec2B0rfO4ynouX+5UDrYKtXiZpyKBZv6NeHY9QdK+bPR iD3QSAb6FB/0vgMW4GitajtSKvpqdgz0gXat3dpxUJEPRscyaCQCxN4xJDp4sHnWEuKm B8Z6JjonrXkPeVRfky7eUitbSCfUtpS/gyg46re77KLUDeLANtSM/baTGb2VKVMtfV5R 3udIv3umTYgVaEh2Ay9C3ntpQVOSerE7rasZyrS28jHN6jFZ7eGDrv7h/rD2xUsrLZ4M rNQQ== X-Gm-Message-State: AKwxyte78k6ZzjLbr87W7Q4pyDm2b4nssPKrfBxIUSP3imhIostXl2S+ /Z/81yNH6YlcKHmgMBPZ6ErpqulcfDSDWWUPU8eFyxda X-Google-Smtp-Source: ACJfBov088CEHIhcpYp2zAFzFSjfBmnxNwdLDKmDOBbGTConQKPeHAJYV+Y8HwHBmy+rOaSHIksGAwqQXVAjnlm6wEg= X-Received: by 10.31.99.68 with SMTP id x65mr17489241vkb.170.1515595963099; Wed, 10 Jan 2018 06:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.109.6 with HTTP; Wed, 10 Jan 2018 06:52:22 -0800 (PST) In-Reply-To: References: From: DuyHai Doan Date: Wed, 10 Jan 2018 15:52:22 +0100 Message-ID: Subject: Re: Too many tombstones using TTL To: user Content-Type: multipart/alternative; boundary="94eb2c06aed400f04a05626d2f70" --94eb2c06aed400f04a05626d2f70 Content-Type: text/plain; charset="UTF-8" "The question is why Cassandra creates a tombstone for every column instead of single tombstone per row?" --> Simply because technically it is possible to set different TTL value on each column of a CQL row On Wed, Jan 10, 2018 at 2:59 PM, Python_Max wrote: > Hello, C* users and experts. > > I have (one more) question about tombstones. > > Consider the following example: > cqlsh> create keyspace test_ttl with replication = {'class': > 'SimpleStrategy', 'replication_factor': '1'}; use test_ttl; > cqlsh> create table items(a text, b text, c1 text, c2 text, c3 text, > primary key (a, b)); > cqlsh> insert into items(a,b,c1,c2,c3) values('AAA', 'BBB', 'C111', > 'C222', 'C333') using ttl 60; > bash$ nodetool flush > bash$ sleep 60 > bash$ nodetool compact test_ttl items > bash$ sstabledump mc-2-big-Data.db > > [ > { > "partition" : { > "key" : [ "AAA" ], > "position" : 0 > }, > "rows" : [ > { > "type" : "row", > "position" : 58, > "clustering" : [ "BBB" ], > "liveness_info" : { "tstamp" : "2018-01-10T13:29:25.777Z", "ttl" : > 60, "expires_at" : "2018-01-10T13:30:25Z", "expired" : true }, > "cells" : [ > { "name" : "c1", "deletion_info" : { "local_delete_time" : > "2018-01-10T13:29:25Z" } > }, > { "name" : "c2", "deletion_info" : { "local_delete_time" : > "2018-01-10T13:29:25Z" } > }, > { "name" : "c3", "deletion_info" : { "local_delete_time" : > "2018-01-10T13:29:25Z" } > } > ] > } > ] > } > ] > > The question is why Cassandra creates a tombstone for every column instead > of single tombstone per row? > > In production environment I have a table with ~30 columns and It gives me > a warning for 30k tombstones and 300 live rows. It is 30 times more then it > could be. > Can this behavior be tuned in some way? > > Thanks. > > -- > Best regards, > Python_Max. > --94eb2c06aed400f04a05626d2f70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"The question is why= Cassandra creates a tombstone for every column instead of single tombstone= per row?"=C2=A0

--> Simply because technic= ally it is possible to set different TTL value on each column of a CQL row<= /span>

On Wed, Jan 10, 2018 at 2:59 PM, Python_Max <python.max@gmail.com= > wrote:
Hello= , C* users and experts.

I have (one more) question about= tombstones.

Consider the following example:
cqlsh> create keyspace test_ttl with replication =3D {'clas= s': 'SimpleStrategy', 'replication_factor': '1'= }; use test_ttl;
cqlsh>=C2=A0create table items(a text, b = text, c1 text, c2 text, c3 text, primary key (a, b));
cqlsh>= =C2=A0insert into items(a,b,c1,c2,c3) values('AAA', 'BBB', = 'C111', 'C222', 'C333') using ttl 60;
bas= h$ nodetool flush
bash$ sleep 60
bash$ nodetool=C2=A0co= mpact test_ttl items
bash$ sstabledump=C2=A0mc-2-big-Data.db

[
=C2=A0 {
=C2=A0= =C2=A0 "partition" : {
=C2=A0 =C2=A0 =C2=A0 "key&= quot; : [ "AAA" ],
=C2=A0 =C2=A0 =C2=A0 "position&= quot; : 0
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "rows&quo= t; : [
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 "type" : "row",
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 "position" : 58,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "= clustering" : [ "BBB" ],
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 "liveness_info" : { "tstamp" : "2018-01-10T13:= 29:25.777Z", "ttl" : 60, "expires_at" : "2018= -01-10T13:30:25Z", "expired" : true },
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 "cells" : [
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 { "name" : "c1", "deletion_info" := { "local_delete_time" : "2018-01-10T13:29:25Z" }
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 { "name" : "c2", "deletion_info"= ; : { "local_delete_time" : "2018-01-10T13:29:25Z" }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 { "name" : "c3", "deletion_info&= quot; : { "local_delete_time" : "2018-01-10T13:29:25Z" = }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]<= /div>
=C2=A0 }
]

The question = is why Cassandra creates a tombstone for every column instead of single tom= bstone per row?

In production environment I have a= table with ~30 columns and It gives me a warning for 30k tombstones and 30= 0 live rows. It is 30 times more then it could be.
Can this behav= ior be tuned in some way?

Thanks.

--
Best regards,
Python= _Max.

--94eb2c06aed400f04a05626d2f70--