Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8C08B184EF for ; Thu, 4 Jun 2015 18:29:41 +0000 (UTC) Received: (qmail 67185 invoked by uid 500); 4 Jun 2015 18:29:40 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 67158 invoked by uid 500); 4 Jun 2015 18:29:40 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 67065 invoked by uid 99); 4 Jun 2015 18:29:40 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jun 2015 18:29:40 +0000 Date: Thu, 4 Jun 2015 18:29:40 +0000 (UTC) From: "Aleksey Yeschenko (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CASSANDRA-9107) More accurate row count estimates MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9107: ----------------------------------------- Fix Version/s: (was: 2.1.x) 2.2.0 rc1 2.1.6 > More accurate row count estimates > --------------------------------- > > Key: CASSANDRA-9107 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9107 > Project: Cassandra > Issue Type: Improvement > Reporter: Chris Lohfink > Assignee: Chris Lohfink > Fix For: 2.1.6, 2.2.0 rc1 > > Attachments: 9107-cassandra2-1.patch, 9107-v2.txt > > > Currently the estimated row count from cfstats is the sum of the number of rows in all the sstables. This becomes very inaccurate with wide rows or heavily updated datasets since the same partition would exist in many sstables. In example: > {code} > create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1}; > create TABLE wide (key text PRIMARY KEY , value text) WITH compaction = {'class': 'SizeTieredCompactionStrategy', 'min_threshold': 30, > 'max_threshold': 100} ; > ------------------------------- > insert INTO wide (key, value) VALUES ('key', 'value'); > // flush > // cfstats output: Number of keys (estimate): 1 (128 in older version from index) > insert INTO wide (key, value) VALUES ('key', 'value'); > // flush > // cfstats output: Number of keys (estimate): 2 (256 in older version from index) > ... etc > {code} > previously it used the index but it still did it per sstable and summed them up which became inaccurate as there are more sstables (just by much worse). With new versions of sstables we can merge the cardinalities to resolve this with a slight hit to accuracy in the case of every sstable having completely unique partitions. > Furthermore I think it would be pretty minimal effort to include the number of rows in the memtables to this count. We wont have the cardinality merging between memtables and sstables but I would consider that a relatively minor negative. -- This message was sent by Atlassian JIRA (v6.3.4#6332)