They can be and it depends on your compaction strategy :)
On Sun, 6 Nov 2016 at 21:24 Ali Akhtar wrote:
> tl;dr? I just want to know if updates are bad for performance, and if so,
> for how long.
>
> On Mon, Nov 7, 2016 at 10:23 AM, Ben Bromhead
Yes, it does mean you’re getting ahead of Cassandra’s ability to keep up
although I would have probably expected a higher number of pending
compactions before you got serious issues (I’ve seen numbers in the
thousands).
I notice from the screenshot you provide that you are using secondary
Thanks Ben. I stopped inserting and checked compaction status as you mentioned.
Seems there is lots of compaction work waiting to do. Please see below. In this
case is it a sign that writting faster than C* can process?
One node,
[root@iZbp11zpafrqfsiys90kzoZ bin]# ./nodetool compactionstats
tl;dr? I just want to know if updates are bad for performance, and if so,
for how long.
On Mon, Nov 7, 2016 at 10:23 AM, Ben Bromhead wrote:
> Check out https://wiki.apache.org/cassandra/WritePathForUsers for the
> full gory details.
>
> On Sun, 6 Nov 2016 at 21:09 Ali
Check out https://wiki.apache.org/cassandra/WritePathForUsers for the full
gory details.
On Sun, 6 Nov 2016 at 21:09 Ali Akhtar wrote:
> How long does it take for updates to get merged / compacted into the main
> data file?
>
> On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead
How long does it take for updates to get merged / compacted into the main
data file?
On Mon, Nov 7, 2016 at 5:31 AM, Ben Bromhead wrote:
> To add some flavor as to how the commitlog implementation is so quick.
>
> It only flushes to disk every 10s by default. So writes are
This sounds to me like your writes go ahead of compactions trying to keep
up which can eventually cause issues. Keep an eye on nodetool
compactionstats if the number of compactions continually climbs then you
are writing faster than Cassandra can actually process. If this is
happening then you
Hi All,
We have one issue on C* testing. At first the inserting was very fast and TPS
was about 30K/s, but when the size of data rows reached 2 billion, the
insertion rate decreased very badly and the TPS was 20K/s. When the size of
rows reached 2.3 billion, the TPS decreased to 0.5K/s, and
To add some flavor as to how the commitlog implementation is so quick.
It only flushes to disk every 10s by default. So writes are effectively
done to memory and then to disk asynchronously later on. This is generally
accepted to be OK, as the write is also going to other nodes.
You can of
Hi,
We are new to Cassandra. For our POC, we tried creating table and inserting
them as JSON and all these went fine. Now we are trying to implement one of
the application scenario, and I am having difficulty in coming up with the
best approach.
Scenario:
We have a Device POJO which have some
Cassandra writes are particularly fast, for a few reasons:
1) Most writes go to a commitlog (append-only file, written linearly, so
particularly fast in terms of disk operations) and then pushed to the memTable.
Memtable is flushed in batches to the permanent data files, so it buffers
Hi all,
Are Cassandra writes are faster than reads ?? If yes, why is this so? I am
using consistency 1 and data is in memory.
Vikas
12 matches
Mail list logo