[jira] [Issue Comment Deleted] (CASSANDRA-9283) Deprecate unlogged batches
[ https://issues.apache.org/jira/browse/CASSANDRA-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Kolyadenko updated CASSANDRA-9283: - Comment: was deleted (was: Hi there, in my understanding, cross-partition unlogged batches are widely used by community for fast hustle free bulk data import into Cassandra. Other alternative approaches: - CQLSSTableWriter - much harder to setup and maintain in the program logic - individual Async writes - much slower than unlogged batch in few nodes setup (up to 10 times slower in my observations) - logged bacth - slower than unlogged batch - (3 times slower in my observations) Is it possible to undeprecate/keep unlogged batch, or develop some other simple to use bulk insert API for fast insertion of data? Thank you.) > Deprecate unlogged batches > -- > > Key: CASSANDRA-9283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9283 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Jonathan Ellis >Assignee: T Jake Luciani > Fix For: 2.2.0 beta 1 > > > Officially mark unlogged batches deprecated. > Note that the main "good" use case for unlogged batches, of multiple updates > in a single partition key, is "free" when done as a logged batch. So really > unlogged batches mainly serve as a honeypot to trick new users into abusing > them in misguided bulk loading attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9283) Deprecate unlogged batches
[ https://issues.apache.org/jira/browse/CASSANDRA-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429814#comment-15429814 ] Andriy Kolyadenko commented on CASSANDRA-9283: -- Hi there, in my understanding, cross-partition unlogged batches are widely used by community for fast hustle free bulk data import into Cassandra. Other alternative approaches: - CQLSSTableWriter - much harder to setup and maintain in the program logic - individual Async writes - much slower than unlogged batch in few nodes setup (up to 10 times slower in my observations) - logged bacth - slower than unlogged batch - (3 times slower in my observations) Is it possible to undeprecate/keep unlogged batch, or develop some other simple to use bulk insert API for fast insertion of data? Thank you. > Deprecate unlogged batches > -- > > Key: CASSANDRA-9283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9283 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Jonathan Ellis >Assignee: T Jake Luciani > Fix For: 2.2.0 beta 1 > > > Officially mark unlogged batches deprecated. > Note that the main "good" use case for unlogged batches, of multiple updates > in a single partition key, is "free" when done as a logged batch. So really > unlogged batches mainly serve as a honeypot to trick new users into abusing > them in misguided bulk loading attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Kolyadenko updated CASSANDRA-3741: - Just would like to report that I have the same behavior with 1.2.4. OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13267238#comment-13267238 ] Andriy Kolyadenko commented on CASSANDRA-3741: -- Another attempt to fix this: https://github.com/apache/cassandra/pull/10 Please consider my patch. It's very annoying to have Cassandra dying in such situations. OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
