Re: Large number of tombstones without delete or update

otocol V4, variables can be left “unset”, in which case they will be > ignored server-side (no tombstones will be generated).” > > > From: Ralf Steppacher [mailto:ralf.viva...@gmail.com > <mailto:ralf.viva...@gmail.com>] > Sent: Thursday, March 24, 2016 11:19 AM > To: use

Re: Large number of tombstones without delete or update

Ralf, Thank YOU very much Ralf. You are the first one who could finally shed some light on something I observed, but I could not put my finger on what exactly is causing my Tombstones. I cannot judge your method for evaluating the amount of tombstone. It seems valid to me. Jean On 24 Mar

RE: Large number of tombstones without delete or update

:36 AM To: user@cassandra.apache.org Subject: Re: Large number of tombstones without delete or update How does this improvement apply to inserting JSON? The prepared statement has exactly one parameter and it is always bound to the JSON message: INSERT INTO event_by_patient_timestamp JSON ? How w

Re: Large number of tombstones without delete or update

Jean, yes, I am using the native protocol v4 (auto-negotiated between java driver 3.0.0 and C* 2.2.4, verified by logging cluster.getConfiguration().getProtocolOptions().getProtocolVersion() ). My first approach for testing for tombstones was “brute force”. Add records and soon enough (after

Re: Large number of tombstones without delete or update

l be generated).” From: Ralf Steppacher [mailto:ralf.viva...@gmail.com] Sent: Thursday, March 24, 2016 11:19 AM To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: Re: Large number of tombstones without delete or update I did some more tests with my particular schema/m

Re: Large number of tombstones without delete or update

Sent: Thursday, March 24, 2016 11:19 AM > To: user@cassandra.apache.org > Subject: Re: Large number of tombstones without delete or update > > I did some more tests with my particular schema/message structure: > > A null text field inside a UDT instance does NOT yield tombstones. > A null

RE: Large number of tombstones without delete or update

rated)." From: Ralf Steppacher [mailto:ralf.viva...@gmail.com] Sent: Thursday, March 24, 2016 11:19 AM To: user@cassandra.apache.org Subject: Re: Large number of tombstones without delete or update I did some more tests with my particular schema/message structure: A null text field inside

Re: Large number of tombstones without delete or update

I did some more tests with my particular schema/message structure: A null text field inside a UDT instance does NOT yield tombstones. A null map does NOT yield tombstones. A null text field does yield tombstones. Ralf > On 24.03.2016, at 09:42, Ralf Steppacher wrote: >

Re: Large number of tombstones without delete or update

Same for me. Only inserts not replacing old records. On 24 Mar,2016, at 07:42, Ralf Steppacher > wrote: Eric, I am writing the whole record in a single INSERT INTO ... JSON. I am not "insert-updating" over an existing record nor do I run

Re: Large number of tombstones without delete or update

Eric, I am writing the whole record in a single INSERT INTO … JSON. I am not "insert-updating" over an existing record nor do I run any UPDATE statements. Ralf > On 24.03.2016, at 01:47, Eric Stevens wrote: > > In addition to writing null values acting as tombstones, also

Re: Large number of tombstones without delete or update

Hi, I also have loads of tombstones while only inserting new rows without ever deleting rows. My rows contain null columns and also collections. How can I avoid the creation of these tombstones? Thanks for your help. On 24 Mar,2016, at 02:08, Steve Robenalt

Re: Large number of tombstones without delete or update

Yes. In this particular test there are four fields null., one of them in a UDT instance. I don’t set fields to null explicitly. I insert as JSON and those fields are not in the particular message. But when I select the record the fields are shown as null. In real live almost all fields are

Re: Large number of tombstones without delete or update

Hi Henry, Since new values are written without checking for previous values, the only way to assure that a nulled column blocks a previously valid one is to write a tombstone to occlude whatever value might have been present. I believe there are some recent changes as to the handling of null

Re: Large number of tombstones without delete or update

What is the reason for the tombstone for a brand new insert? Do the fields get written as a whole (both nulls and non-nulls? I understand the rationale for tombstones for deletes and updates but it does not make sense for an insert (I am trying to make sense of it). I understand Cassandra writes

Re: Large number of tombstones without delete or update

In addition to writing null values acting as tombstones, also INSERTing a collection (or UPDATE where you set the collection rather than append to it) are also operations which will create tombstones. On Wed, Mar 23, 2016 at 12:09 PM Robert Coli wrote: > On Wed, Mar 23,

Re: Large number of tombstones without delete or update

On Wed, Mar 23, 2016 at 9:50 AM, Ralf Steppacher wrote: > How come I end up with that large a number of tombstones? > Are you inserting NULLs? =Rob

Large number of tombstones without delete or update

Hi all, I started running “stress tests” against my application which writes event data to a local single-node Cassandra cluster (C* v2.2.4). After inserting a couple thousand rows (all for the same partition key) I am starting to get warnings in the C* log informing me about large numbers of