From user-return-63684-archive-asf-public=cust-asf.ponee.io@cassandra.apache.org Wed Apr 17 13:12:30 2019 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 029E2180672 for ; Wed, 17 Apr 2019 15:12:29 +0200 (CEST) Received: (qmail 9602 invoked by uid 500); 17 Apr 2019 13:12:18 -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 9592 invoked by uid 99); 17 Apr 2019 13:12:18 -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, 17 Apr 2019 13:12:18 +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 0C526C0868 for ; Wed, 17 Apr 2019 13:12:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.8 X-Spam-Level: ** X-Spam-Status: No, score=2.8 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); domainkeys=pass (768-bit key) header.from=onmstester@zoho.com header.d=zoho.com; dkim=pass (1024-bit key) header.d=zoho.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 51HnmJu3GEk0 for ; Wed, 17 Apr 2019 13:12:13 +0000 (UTC) Received: from sender-pp-o92.zoho.com (sender-pp-092.zoho.com [135.84.80.237]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 3C8B25FB83 for ; Wed, 17 Apr 2019 13:12:12 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1555506723; cv=none; d=zoho.com; s=zohoarc; b=Hdky8ewoh9RCkKx/AWs5hn2YmW4jQWx7hTJ/+8fqzhlkX19pZ5sVD/QOiC9Ezd4QEQDMLZkTofE/8AYMiDdNRvP0Y5jeUTh8SDvjmeBFEOM8gGhUjRao/YjcHYvGBiYqvdlHNlkg87g4RwhpEiOiAPnXvOLg74bAC9B5inNZ1bM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1555506723; h=Content-Type:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=v57YoakUVxDOkKC85vU7JxfxC4pFxfKysVItFg5WfUo=; b=ZjvnEl2OvQtYA+zK0ZgBJzzrRKFYz1ryaEomWHV62iL2GBtG7gRWKZZBb//hHz4/6WApvPx5RTxkaprXtZDXUg5t+MXyfufRZC6QNA+g0r4euwW9W3j5W3ix/S20vGtTVzuOQnga9HePTqc7DJgSvVuL5ZP4tVBnvntqw35x5Z4= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=onmstester@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=aSd67+C8bFsJhZDM581YHCT3nlsnB0Y25GboHu6QwsPVufAyhGUu/Wod9Bkd8U4efGvYzwF1PmHl NWcdYEFnJ+9oW5zxlZUGyx78/mSX3YbD/OgJmUxWOzFaCCsGLn/y Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1555506717189197.69875172690854; Wed, 17 Apr 2019 06:11:57 -0700 (PDT) Received: from [173.236.49.12] by mail.zoho.com with HTTP;Wed, 17 Apr 2019 06:11:57 -0700 (PDT) Date: Wed, 17 Apr 2019 17:41:57 +0430 From: onmstester onmstester To: "user" Message-Id: <16a2b6ce201.d84289082696.1944967757962271019@zoho.com> In-Reply-To: References: Subject: Re: gc_grace config for time serie database MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7259_1954788992.1555506717186" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail ------=_Part_7259_1954788992.1555506717186 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do not use table default ttl (every row has its own TTL) and also no upda= te occurs to the rows. I suppose that (because of immutable nature of everything in cassandra) ca= ssandra would keep only the insertion timestamp + the original ttl and=C2= =A0 computes ttl of a row using these two and current timestamp of the syst= em whenever needed (when you select ttl or when the compaction occurs). So there should be something like this attached to every row: "this row ins= erted at 4/17/2019 12:20 PM=C2=A0 and should be deleted in 2 months", so wh= atever happens to the row replicas, my intention of removing it at 6/17 sho= uld not be changed! Would you suggest that my idea of "gc_grace =3D max_hint =3D 3 hours" for a= time serie db is not reasonable? Sent using https://www.zoho.com/mail/ ---- On Wed, 17 Apr 2019 17:13:02 +0430 Stefan Miklosovic wrote ---- TTL value is decreasing every second and it is set to original TTL=20 value back after some update occurs on that row (see example below).=20 Does not it logically imply that if a node is down for some time and=20 updates are occurring on live nodes and handoffs are saved for three=20 hours and after three hours it stops to do them, your data on other=20 nodes would not be deleted as TTLS are reset upon every update and=20 countdown starts again, which is correct, but they would be deleted on=20 that node which was down because it didnt receive updates so if you=20 query that node, data will not be there but they should.=20 =20 On the other hand, a node was down, it was TTLed on healthy nodes and=20 tombstone was created, then you start the first one which was down and=20 as it counts down you hit that node with update. So there is not a=20 tombstone on the previously dead node but there are tombstones on=20 healthy ones and if you delete tombstones after 3 hours, previously=20 dead node will never get that info and it your data might actually end=20 up being resurrected as they would be replicated to always healthy=20 nodes as part of the repair.=20 =20 Do you see some flaw in my reasoning?=20 =20 cassandra@cqlsh> DESCRIBE TABLE test.test;=20 =20 CREATE TABLE test.test (=20 id uuid PRIMARY KEY,=20 value text=20 ) WITH bloom_filter_fp_chance =3D 0.6=20 AND caching =3D {'keys': 'ALL', 'rows_per_partition': 'NONE'}=20 AND comment =3D ''=20 AND compaction =3D {'class':=20 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',=20 'max_threshold': '32', 'min_threshold': '4'}=20 AND compression =3D {'chunk_length_in_kb': '64', 'class':=20 'org.apache.cassandra.io.compress.LZ4Compressor'}=20 AND crc_check_chance =3D 1.0=20 AND dclocal_read_repair_chance =3D 0.1=20 AND default_time_to_live =3D 60=20 AND gc_grace_seconds =3D 864000=20 AND max_index_interval =3D 2048=20 AND memtable_flush_period_in_ms =3D 0=20 AND min_index_interval =3D 128=20 AND read_repair_chance =3D 0.0=20 AND speculative_retry =3D '99PERCENTILE';=20 =20 =20 cassandra@cqlsh> select ttl(value) from test.test where id =3D=20 4f860bf0-d793-4408-8330-a809c6cf6375;=20 =20 ttl(value)=20 ------------=20 25=20 =20 (1 rows)=20 cassandra@cqlsh> UPDATE test.test SET value =3D 'c' WHERE id =3D=20 4f860bf0-d793-4408-8330-a809c6cf6375;=20 cassandra@cqlsh> select ttl(value) from test.test where id =3D=20 4f860bf0-d793-4408-8330-a809c6cf6375;=20 =20 ttl(value)=20 ------------=20 59=20 =20 (1 rows)=20 cassandra@cqlsh> select * from test.test ;=20 =20 id | value=20 --------------------------------------+-------=20 4f860bf0-d793-4408-8330-a809c6cf6375 | c=20 =20 =20 On Wed, 17 Apr 2019 at 19:18, fald 1970 wrote= :=20 >=20 >=20 >=20 > Hi,=20 >=20 > According to these Facts:=20 > 1. If a node is down for longer than max_hint_window_in_ms (3 hours by de= fault), the coordinator stops writing new hints.=20 > 2. The main purpose of gc_grace property is to prevent Zombie data and al= so it determines for how long the coordinator should keep hinted files=20 >=20 > When we use Cassandra for Time series data which:=20 > A) Every row of data has TTL and there would be no explicit delete so not= so much worried about zombies=20 > B) At every minute there should be hundredrs of write requets to each nod= e, so if one of the node was down for longer than max_hint_window_in_ms, we= should run manual repair on that node, so anyway stored hints on the coord= inator won't be necessary.=20 >=20 > So Finally the question, is this a good idea to set gc_grace equal to max= _hint_window_in_ms (/1000 to convert to seconds),=20 > for example set them both to 3 hours (why should keep the tombstones for = 10 days when they won't be needed at all)?=20 >=20 > Best Regards=20 > Federica Albertini=20 =20 ---------------------------------------------------------------------=20 To unsubscribe, e-mail: mailto:user-unsubscribe@cassandra.apache.org=20 For additional commands, e-mail: mailto:user-help@cassandra.apache.org ------=_Part_7259_1954788992.1555506717186 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I do not use table default ttl (every row has its = own TTL) and also no update occurs to the rows.
I suppose th= at (because of immutable nature of everything in cassandra) cassandra would= keep only the insertion timestamp + the original ttl and  computes tt= l of a row using these two and current timestamp of the system whenever nee= ded (when you select ttl or when the compaction occurs).
So t= here should be something like this attached to every row: "this row inserte= d at 4/17/2019 12:20 PM  and should be deleted in 2 months", so whatev= er happens to the row replicas, my intention of removing it at 6/17 should = not be changed!

Would you suggest that my idea= of "gc_grace =3D max_hint =3D 3 hours" for a time serie db is not reasonab= le?

Sent using Zoho Mail=


<= div>
---- On Wed, 17 Apr 2019 17:13:02 +0= 430 Stefan Miklosovic <stefan.miklosovic@instaclustr.com> wrot= e ----

= TTL value is decreasing every second and it is set to original TTL
value back after some update occurs on that row (see example below).=
Does not it logically imply that if a node is down for some= time and
updates are occurring on live nodes and handoffs a= re saved for three
hours and after three hours it stops to d= o them, your data on other
nodes would not be deleted as TTL= S are reset upon every update and
countdown starts again, wh= ich is correct, but they would be deleted on
that node which= was down because it didnt receive updates so if you
query t= hat node, data will not be there but they should.

On the other hand, a node was down, it was TTLed on healthy nodes and=
tombstone was created, then you start the first one which w= as down and
as it counts down you hit that node with update.= So there is not a
tombstone on the previously dead node but= there are tombstones on
healthy ones and if you delete tomb= stones after 3 hours, previously
dead node will never get th= at info and it your data might actually end
up being resurre= cted as they would be replicated to always healthy
nodes as = part of the repair.

Do you see some flaw in = my reasoning?

cassandra@cqlsh> DESCRIBE T= ABLE test.test;

CREATE TABLE test.test (
id uuid PRIMARY KEY,
value text
) WITH bloom_filter_fp_chance =3D 0.6
AND caching =3D {'ke= ys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment =3D '= '
AND compaction =3D {'class':
'org.apache.c= assandra.db.compaction.SizeTieredCompactionStrategy',
'max_t= hreshold': '32', 'min_threshold': '4'}
AND compression =3D = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.= io.compress.LZ4Compressor'}
AND crc_check_chance =3D 1.0
AND dclocal_read_repair_chance =3D 0.1
AND de= fault_time_to_live =3D 60
AND gc_grace_seconds =3D 864000 <= br>
AND max_index_interval =3D 2048
AND memtable= _flush_period_in_ms =3D 0
AND min_index_interval =3D 128
AND read_repair_chance =3D 0.0
AND speculativ= e_retry =3D '99PERCENTILE';


= cassandra@cqlsh> select ttl(value) from test.test where id =3D
4f860bf0-d793-4408-8330-a809c6cf6375;

= ttl(value)
------------
25
=
(1 rows)
cassandra@cqlsh> UPDATE test.test= SET value =3D 'c' WHERE id =3D
4f860bf0-d793-4408-8330-a80= 9c6cf6375;
cassandra@cqlsh> select ttl(value) from test.t= est where id =3D
4f860bf0-d793-4408-8330-a809c6cf6375;
<= /div>

ttl(value)
------------
59

(1 rows)
cassandra@= cqlsh> select * from test.test ;

id = | value
---------------------= -----------------+-------
4f860bf0-d793-4408-8330-a809c6cf6= 375 | c


On Wed, 17 Apr 2= 019 at 19:18, fald 1970 <falldi1970@gmail.com> wrote:
>
>
>
> Hi,
>=
> According to these Facts:
> 1. If a = node is down for longer than max_hint_window_in_ms (3 hours by default), th= e coordinator stops writing new hints.
> 2. The main purp= ose of gc_grace property is to prevent Zombie data and also it determines f= or how long the coordinator should keep hinted files
>
> When we use Cassandra for Time series data which:
> A) Every row of data has TTL and there would be no explicit de= lete so not so much worried about zombies
> B) At every m= inute there should be hundredrs of write requets to each node, so if one of= the node was down for longer than max_hint_window_in_ms, we should run man= ual repair on that node, so anyway stored hints on the coordinator won't be= necessary.
>
> So Finally the question= , is this a good idea to set gc_grace equal to max_hint_window_in_ms (/1000= to convert to seconds),
> for example set them both to 3= hours (why should keep the tombstones for 10 days when they won't be neede= d at all)?
>
> Best Regards
<= div>> Federica Albertini

----------------= -----------------------------------------------------
To uns= ubscribe, e-mail: user-unsubscribe@cassandra.apache.org
= For additional commands, e-mail: user-help@cassandra.apache.org



------=_Part_7259_1954788992.1555506717186--