Re: SSTables are not getting removed

[Nate McCall]

>
>
> memtable_offheap_space_in_mb: 4096
>
> memtable_cleanup_threshold: 0.99
>

^ What led to this setting? You are basically telling Cassandra to not
flush the highest-traffic memtable until the memtable space is 99% full.
With that many tables and keyspaces, you are basically locking up
everything on the flush queue, causing substantial back pressure. If you
run 'nodetool tpstats' you will probably see a massive number of 'All Time
Blocked' for FlushWriter and 'Dropped' for Mutations.

Actually, this is probably why you are seeing a lot of small tables: commit
log segments are being filled and blocked from flushing due to the above,
so they have to attempt to flush repeatedly with whatever is there whenever
they get the chance.

thrift_framed_transport_size_in_mb: 150
>

^ This is also a super bad idea. Thrift buffers grow as needed to
accomodate larger results, but they dont ever shrink. This will lead to a
bunch of open connections holding onto large, empty byte arrays. This will
show up immediately in a heap dump inspection.


> concurrent_compactors: 4
>
> compaction_throughput_mb_per_sec: 0
>
> endpoint_snitch: GossipingPropertyFileSnitch
>
>
>
> This grinds our system to a halt and causes a major GC nearly every second.
>
>
>
> So far the only way to get around this is to run a cron job every hour
> that does a “nodetool compact”.
>

What's the output of 'nodetool compactionstats'? CASSANDRA-9882
and CASSANDRA-9592 could be to blame (both fixed in recent versions) or
this could just be a side effect of the memory pressure from the above
settings.

Start back at the default settings (except snitch - GPFS is always a good
place to start) and change settings serially and in small increments based
on feedback gleaned from monitoring runtimes.


-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: cassandra state listener sends duplicate signals one with public ip and another with private ip

[Robert Coli]

On Thu, Oct 29, 2015 at 8:35 PM, Dhyan Muralidharan <
d.muralidha...@yottaa.com> wrote:

>  Can some one respond to this ?
>
>
> http://stackoverflow.com/questions/33428094/cassandra-state-listener-sends-duplicate-signals-one-with-public-ip-and-another
>

If you actually post your question to the mailing list instead of
stackoverflow, possibly?

=Rob

Re: terrible read/write latency fluctuation

[Anishek Agarwal]

if its some sort of timeseries DTCS might turn out to be better for
compaction. also some disk monitoring might help to understand if disk is
the bottleneck.

On Sun, Oct 25, 2015 at 3:47 PM, 曹志富  wrote:

> I will try to trace a read that take > 20msec
> .
>
> just HDD.no delete just 60days ttl.value size is small ,max length is 140.
>
>
> My data like Time Series . date of 90% reads which timestamp < 7days.
> data almost just insert ,with a lit update.
>

Cassandra Data Model with Narrow partition

[chandrasekar.krc]

Hi,

Could you please suggest if Narrow partition is a  good choice for the below 
use case.


1)  Write heavy event log table with 50m inserts per day with a peak load 
of 20K transaction per sec. There aren't any updates/deletes to records 
inserted. Records are inserted with a TTL of 60 days (retention period)

2)  The table has a single primary key which is a sequence number (27 
digits) generated by source application

3)  There are only two access patterns used - one by using the sequence 
number & the other using sequence number + event date (range scans also 
possible)

4)  My target data model in Cassandra is partitioned with sequence number 
as the primary key + event date as clustering columns to enable range scans on 
date.

5)  The Table has close to 120+ columns and the average row size comes 
close to 32K bytes

6)  Reads are very very less and account to <5% while inserts can be close 
to 95%.

7)  From a functional standpoint, I do not see any other columns that can 
be part of primary key to keep the partition reasonable (<100MB)

Questions:

1)  Is Narrow partition an ideal choice for the above use case.

2)  Is artificial bucketing an alternate choice to make the partition 
reasonable

3)  We are using varint as the data type for sequence number which is 27 
digits long. Is DECIMAL data type ?

4)  Any suggestions on performance impacts during compaction ?

Regards, Chandra Sekar KR

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

Re: Weird replace_address issue in 1.2

[Carlos Alonso]

Well, everything was fine.

The streams finished and after that the node joined the ring nicely and
everyone removed the old one. :)

Thanks!

Carlos Alonso | Software Engineer | @calonso 

On 29 October 2015 at 21:45, Robert Coli  wrote:

> On Thu, Oct 29, 2015 at 6:41 AM, Carlos Alonso  wrote:
>
>> Tonight one of our 3 nodes cluster has died. This is Cassandra 1.2. and
>> RF = 3
>>
>> After bringing up a new node and starting it with -Dreplace_address of
>> the dead one different things are happening.
>>
>> On the new node nodetool status is showing the expected ring (him along
>> with the other two working nodes), but his status is UN, when I would
>> expect it to be UJ, because is joining, right?
>>
>
> I predict that this node has itself in its own seed list, and therefore
> cannot bootstrap. I have no idea what is going on with the streams you
> report.
>
> What version of 1.2.x?
>
> As an aside, you are likely to have a better latency on debugging such
> issues if you join the #cassandra irc channel on freenode.
>
> =Rob
>
>

Re: Cassandra Data Model with Narrow partition

[Carlos Alonso]

Hi Chandra,

Narrow partition is probably your best choice, but you need to bucket data
somehow, otherwise your partitions will soon become unmanageable and you'll
have problems reading them, both because the partitions will become very
big and also because of the tombstones that your expired records will
generate.

In general having a partition that can grow indefinitely is a bad idea, so
I'd advice you to use time based artificial bucketing to limit the maximum
size of your partitions to be as close as possible to the recommendations.

Also 120+ columns sounds like quite many, is there a way you can separate
in different cfs or maybe use collections? I'd advice to do some
benchmarking here: http://mrcalonso.com/benchmarking-cassandra-models/.
This post is a bit outdated as nowadays you can use cassandra-stress with
your own models, but the idea is the same.

About compactions I'd use DTCS or LCS, but given that you will have a big
amount of tombstones due to TTLs I'd never go with STCS.

Hope it helps!

Carlos Alonso | Software Engineer | @calonso 

On 30 October 2015 at 10:55,  wrote:

> Hi,
>
>
>
> Could you please suggest if Narrow partition is a  good choice for the
> below use case.
>
>
>
> 1)  Write heavy event log table with 50m inserts per day with a peak
> load of 20K transaction per sec. There aren’t any updates/deletes to
> records inserted. Records are inserted with a TTL of 60 days (retention
> period)
>
> 2)  The table has a single primary key which is a sequence number (27
> digits) generated by source application
>
> 3)  There are only two access patterns used – one by using the
> sequence number & the other using sequence number + event date (range scans
> also possible)
>
> 4)  My target data model in Cassandra is partitioned with sequence
> number as the primary key + event date as clustering columns to enable
> range scans on date.
>
> 5)  The Table has close to 120+ columns and the average row size
> comes close to 32K bytes
>
> 6)  Reads are very very less and account to <5% while inserts can be
> close to 95%.
>
> 7)  From a functional standpoint, I do not see any other columns that
> can be part of primary key to keep the partition reasonable (<100MB)
>
>
>
> Questions:
>
> 1)  Is Narrow partition an ideal choice for the above use case.
>
> 2)  Is artificial bucketing an alternate choice to make the partition
> reasonable
>
> 3)  We are using varint as the data type for sequence number which is
> 27 digits long. Is DECIMAL data type ?
>
> 4)  Any suggestions on performance impacts during compaction ?
>
>
>
> Regards, Chandra Sekar KR
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>

nodetool upgradesstables skip major version

[Xu Zhongxing]

Can I run
nodetool upgradesstables
after updating a Cassandra 2.0 node directly to Cassandra 3.0?


Or do I have to upgrade to 2.1 and then upgrade to 3.0?

Re: Cassandra Data Model with Narrow partition

[Kai Wang]

agree with Carlos, you should bucket your key, for example, into (pk, day,
hour). Otherwise your partition is going to be large enough to cause
problems.

On Fri, Oct 30, 2015 at 8:04 AM, Carlos Alonso  wrote:

> Hi Chandra,
>
> Narrow partition is probably your best choice, but you need to bucket data
> somehow, otherwise your partitions will soon become unmanageable and you'll
> have problems reading them, both because the partitions will become very
> big and also because of the tombstones that your expired records will
> generate.
>
> In general having a partition that can grow indefinitely is a bad idea, so
> I'd advice you to use time based artificial bucketing to limit the maximum
> size of your partitions to be as close as possible to the recommendations.
>
> Also 120+ columns sounds like quite many, is there a way you can separate
> in different cfs or maybe use collections? I'd advice to do some
> benchmarking here: http://mrcalonso.com/benchmarking-cassandra-models/.
> This post is a bit outdated as nowadays you can use cassandra-stress with
> your own models, but the idea is the same.
>
> About compactions I'd use DTCS or LCS, but given that you will have a big
> amount of tombstones due to TTLs I'd never go with STCS.
>
> Hope it helps!
>
> Carlos Alonso | Software Engineer | @calonso 
>
> On 30 October 2015 at 10:55,  wrote:
>
>> Hi,
>>
>>
>>
>> Could you please suggest if Narrow partition is a  good choice for the
>> below use case.
>>
>>
>>
>> 1)  Write heavy event log table with 50m inserts per day with a peak
>> load of 20K transaction per sec. There aren’t any updates/deletes to
>> records inserted. Records are inserted with a TTL of 60 days (retention
>> period)
>>
>> 2)  The table has a single primary key which is a sequence number
>> (27 digits) generated by source application
>>
>> 3)  There are only two access patterns used – one by using the
>> sequence number & the other using sequence number + event date (range scans
>> also possible)
>>
>> 4)  My target data model in Cassandra is partitioned with sequence
>> number as the primary key + event date as clustering columns to enable
>> range scans on date.
>>
>> 5)  The Table has close to 120+ columns and the average row size
>> comes close to 32K bytes
>>
>> 6)  Reads are very very less and account to <5% while inserts can be
>> close to 95%.
>>
>> 7)  From a functional standpoint, I do not see any other columns
>> that can be part of primary key to keep the partition reasonable (<100MB)
>>
>>
>>
>> Questions:
>>
>> 1)  Is Narrow partition an ideal choice for the above use case.
>>
>> 2)  Is artificial bucketing an alternate choice to make the
>> partition reasonable
>>
>> 3)  We are using varint as the data type for sequence number which
>> is 27 digits long. Is DECIMAL data type ?
>>
>> 4)  Any suggestions on performance impacts during compaction ?
>>
>>
>>
>> Regards, Chandra Sekar KR
>>
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email.
>> www.wipro.com
>>
>
>

Re: Cassandra 2.2.1 on Windows (disk_access_mode: mmap_index_only)

[Alaa Zubaidi (PDF)]

Hi,
Just an update...
we changed the disk_access_mode to mmap_index_only and the memory problem
disappeared. However, we did NOT confirm yet, the exact affect on
performance, but in general acceptable so far, it could due to the fact
that its not optimized anyways yet, since we just started using 2.2.1
recently.

We also had to add this to cassandra.yaml file
index_summary_resize_interval_in_minutes=-1
after issues with automatic compaction CASSANDRA-10270

If any one has any feedback on this or on windows configuration or
cassandra configuration on windows, it would be mush appreciated.

Thanks,

On Wed, Oct 28, 2015 at 1:57 PM, Alaa Zubaidi (PDF) 
wrote:

> Thanks Rob,
> We are using 7GB JVM on a 32GB RAM VM
> Alaa
>
> On Wed, Oct 28, 2015 at 11:18 AM, Robert Coli 
> wrote:
>
>> On Tue, Oct 27, 2015 at 8:47 PM, Alaa Zubaidi (PDF) > > wrote:
>>
>>> We have Cassandra 2.2.1 on Windows 2008R2-64-bit.
>>>
>>> We are noticing that during compaction Cassandra consumes all the
>>> available memory for the VM and bring the VM to a crawl. compaction
>>> settings are default, and we are using sized tiered compaction.
>>>
>>> When investigating this, we find through VMMAP that the memory is
>>> consumed by mapped files.
>>> These are almost all the sstables (index and data) for all keyspaces,
>>> mapped into memory (system and user defined keyspaces) .
>>>
>>> Is this normal, or should these files not be mapped into memroy after
>>> compaction?
>>>
>>
>> https://wiki.apache.org/cassandra/FAQ#mmap
>>
>> However that is probably not really your problem, you probably just have
>> too small of a heap if GC is failing?
>>
>> =Rob
>>
>>
>
>
>
> --
>
> Alaa Zubaidi
> PDF Solutions, Inc.
> 333 West San Carlos Street, Suite 1000
> San Jose, CA 95110  USA
> Tel: 408-283-5639
> fax: 408-938-6479
> email: alaa.zuba...@pdf.com
>
>


-- 

Alaa Zubaidi
PDF Solutions, Inc.
333 West San Carlos Street, Suite 1000
San Jose, CA 95110  USA
Tel: 408-283-5639
fax: 408-938-6479
email: alaa.zuba...@pdf.com

-- 
*This message may contain confidential and privileged information. If it 
has been sent to you in error, please reply to advise the sender of the 
error and then immediately permanently delete it and all attachments to it 
from your systems. If you are not the intended recipient, do not read, 
copy, disclose or otherwise use this message or any attachments to it. The 
sender disclaims any liability for such unauthorized use. PLEASE NOTE that 
all incoming e-mails sent to PDF e-mail accounts will be archived and may 
be scanned by us and/or by external service providers to detect and prevent 
threats to our systems, investigate illegal or inappropriate behavior, 
and/or eliminate unsolicited promotional e-mails (“spam”). If you have any 
concerns about this process, please contact us at *
*legal.departm...@pdf.com* *.*

[Announcement]: Achilles 4 released

[DuyHai Doan]

Hello all

 I am pleased to announce the release of Achilles 4.0.0

 After 6 months of incubation, the latest version is out. This new version
is a *complete rewrite* of the framework, using *compile-code code
generation* to provide *better type-safety*, fluent *DSL for query* as well
as latest Java 8 features (*type annotations*, *CompletableFuture* ...).

 For more details, the wiki: https://github.com/doanduyhai/Achilles/wiki

Regards

Duy Hai DOAN

Re: Cassandra stalls and dropped messages not due to GC

[Nate McCall]

Does tpstats show unusually high counts for blocked flush writers?

As Sebastian suggests, running ttop will paint a clearer picture about what
is happening within C*. I would however recommend going back to CMS in this
case as that is the devil we all know and more folks will be able to offer
advice on seeing its output (and it removes a delta).


> It’s starting to look to me like it’s possibly related to brief IO spikes
> that are smaller than my usual graphing granularity. It feels surprising to
> me that these would affect the Gossip threads, but it’s the best current
> lead I have with my debugging right now. More to come when I learn it.
>

Probably not the case since this was a result of an upgrade, but I've seen
similar behavior on systems where some kernels had issues with irqbalance
doing the right thing and would end up parking most interrupts on CPU0
(like say for the disk and ethernet modules) regardless of the number of
cores. Check out proc via 'cat /proc/interrupts' and make sure the
interrupts are spread out of CPU cores. You can steer them off manually at
runtime if they are not spread out.

Also, did you upgrade anything besides Cassandra?


-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

SSTables are not getting removed

[Walsh, Stephen]

Hey all,

First off, thank you for taking the time to read this.

---
SYSTEM SPEC
---

We're using Cassandra Version 2.1.6 (please don't ask us to upgrade just yet 
less you are aware of an existing bug for this issue)
We are running on AWS 4 core . 16 GB server
We are running a 4 core Cluster
We are writing about 1220 rows per second
We are querying about 3400 rows per second
There are 100 Key spaces each with 10 CF's
Our Replication factor is 3
All our data has a TTL of 10 seconds
Our "gc_grace_seconds" is 0
Durable writes is disabled
Read & write Consistency is ONE
Our HEAP size is 8GB (rest of the heap is default)
Our Compaction Strategy is Level Tiered
-XX:CMSInitiatingOccupancyFraction=50

---
Cassandra.yaml
---
Below are the values we've changed

hinted_handoff_enabled: false
data_file_directories:
- /var/lib/cassandra/data
commitlog_directory: /cassandra
saved_caches_directory: /var/lib/cassandra/saved_caches
memtable_offheap_space_in_mb: 4096
memtable_cleanup_threshold: 0.99
memtable_allocation_type: offheap_objects
memtable_flush_writers: 4
thrift_framed_transport_size_in_mb: 150
concurrent_compactors: 4
compaction_throughput_mb_per_sec: 0
endpoint_snitch: GossipingPropertyFileSnitch


---
Issue
---
Over time all our CF's develop about 1 SSTable per 30 min.
Each SSTable contains only 36 rows with data that is all "Marked for deletion"
Over about 15 hours we could have up to 112000 SSTables over all nodes for all 
CF's
This grinds our system to a halt and causes a major GC nearly every second.

So far the only way to get around this is to run a cron job every hour that 
does a "nodetool compact".

Is there any reason that these SSTables are not being deleted during normal 
compaction  / minor GC / major GC ?

Regards
Stephen Walsh




This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.

Re: SSTables are not getting removed

[Jeff Jirsa]

After 15 hours, you have "112000 SSTables over all nodes for all CF’s” - 
assuming I’m parsing that correctly, that’s about 30 per table (100 KS * 10 
tables * 4 nodes), which is actually not unreasonable with LCS.

Your symptom is heavy GC and you’re running 2.1.6 and don’t want to upgrade 
unless there’s a bug that fixes it. There was a memory leak 
https://issues.apache.org/jira/browse/CASSANDRA-9549 – fixed in 2.1.7. Most 
users who saw this saw it using DTCS rather than LCS; I’m unsure if it could be 
the cause of your pain, but if I were in your position, I’d be upgrading to 
find out.

- Jeff

From:  "Walsh, Stephen"
Reply-To:  "user@cassandra.apache.org"
Date:  Friday, October 30, 2015 at 10:20 AM
To:  "user@cassandra.apache.org"
Subject:  SSTables are not getting removed

Hey all,

 

First off, thank you for taking the time to read this.

 

---

SYSTEM SPEC

---

 

We’re using Cassandra Version 2.1.6 (please don’t ask us to upgrade just yet 
less you are aware of an existing bug for this issue)

We are running on AWS 4 core . 16 GB server

We are running a 4 core Cluster

We are writing about 1220 rows per second

We are querying about 3400 rows per second

There are 100 Key spaces each with 10 CF’s

Our Replication factor is 3

All our data has a TTL of 10 seconds

Our “gc_grace_seconds” is 0

Durable writes is disabled

Read & write Consistency is ONE

Our HEAP size is 8GB (rest of the heap is default)

Our Compaction Strategy is Level Tiered

-XX:CMSInitiatingOccupancyFraction=50

 

---

Cassandra.yaml

---

Below are the values we’ve changed 

 

hinted_handoff_enabled: false

data_file_directories:

- /var/lib/cassandra/data

commitlog_directory: /cassandra

saved_caches_directory: /var/lib/cassandra/saved_caches

memtable_offheap_space_in_mb: 4096

memtable_cleanup_threshold: 0.99

memtable_allocation_type: offheap_objects

memtable_flush_writers: 4

thrift_framed_transport_size_in_mb: 150

concurrent_compactors: 4

compaction_throughput_mb_per_sec: 0

endpoint_snitch: GossipingPropertyFileSnitch

 

 

---

Issue

---

Over time all our CF’s develop about 1 SSTable per 30 min.

Each SSTable contains only 36 rows with data that is all “Marked for deletion”

Over about 15 hours we could have up to 112000 SSTables over all nodes for all 
CF’s

This grinds our system to a halt and causes a major GC nearly every second.

 

So far the only way to get around this is to run a cron job every hour that 
does a “nodetool compact”.

 

Is there any reason that these SSTables are not being deleted during normal 
compaction  / minor GC / major GC ?

 

Regards

Stephen Walsh

 

 

 

 
This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments. 



smime.p7s
Description: S/MIME cryptographic signature

Re: Cassandra Data Model with Narrow partition

[Jeff Jirsa]

I’m going to disagree with Carlos in two points.

You do have a lot of columns, so many that it’s likely to impact performance. 
Rather than using collections, serializing those into a single JSON field is 
far more performant. Since you write each record exactly once, this should be 
easily managed.
Your use case is the canonical use case for DTCS – all data has a TTL, you 
write in order, you write each row one time. However, I’m going to suggest to 
you that DTCS is currently a bit buggy in certain operations 
(adding/removing/replacing nodes, in particular, can be very painful with 
larger installations using DTCS). You’re small enough it may not matter, but if 
you expect to grow above a handful of nodes, you may consider waiting until 
DTCS is more stable. 
- Jeff

From:  Carlos Alonso
Reply-To:  "user@cassandra.apache.org"
Date:  Friday, October 30, 2015 at 5:04 AM
To:  "user@cassandra.apache.org"
Subject:  Re: Cassandra Data Model with Narrow partition

Hi Chandra, 

Narrow partition is probably your best choice, but you need to bucket data 
somehow, otherwise your partitions will soon become unmanageable and you'll 
have problems reading them, both because the partitions will become very big 
and also because of the tombstones that your expired records will generate.

In general having a partition that can grow indefinitely is a bad idea, so I'd 
advice you to use time based artificial bucketing to limit the maximum size of 
your partitions to be as close as possible to the recommendations.

Also 120+ columns sounds like quite many, is there a way you can separate in 
different cfs or maybe use collections? I'd advice to do some benchmarking 
here: http://mrcalonso.com/benchmarking-cassandra-models/. This post is a bit 
outdated as nowadays you can use cassandra-stress with your own models, but the 
idea is the same.

About compactions I'd use DTCS or LCS, but given that you will have a big 
amount of tombstones due to TTLs I'd never go with STCS.

Hope it helps!

Carlos Alonso | Software Engineer | @calonso

On 30 October 2015 at 10:55,  wrote:
Hi,

 

Could you please suggest if Narrow partition is a  good choice for the below 
use case.

 

1)  Write heavy event log table with 50m inserts per day with a peak load 
of 20K transaction per sec. There aren’t any updates/deletes to records 
inserted. Records are inserted with a TTL of 60 days (retention period)

2)  The table has a single primary key which is a sequence number (27 
digits) generated by source application

3)  There are only two access patterns used – one by using the sequence 
number & the other using sequence number + event date (range scans also 
possible)

4)  My target data model in Cassandra is partitioned with sequence number 
as the primary key + event date as clustering columns to enable range scans on 
date.

5)  The Table has close to 120+ columns and the average row size comes 
close to 32K bytes

6)  Reads are very very less and account to <5% while inserts can be close 
to 95%.

7)  From a functional standpoint, I do not see any other columns that can 
be part of primary key to keep the partition reasonable (<100MB)

 

Questions:

1)  Is Narrow partition an ideal choice for the above use case.

2)  Is artificial bucketing an alternate choice to make the partition 
reasonable

3)  We are using varint as the data type for sequence number which is 27 
digits long. Is DECIMAL data type ?

4)  Any suggestions on performance impacts during compaction ?

 

Regards, Chandra Sekar KR

 
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com 




smime.p7s
Description: S/MIME cryptographic signature