[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles
[ https://issues.apache.org/jira/browse/CASSANDRA-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-8586: Component/s: Core > support millions of sstables by lazily acquiring/caching/dropping filehandles > - > > Key: CASSANDRA-8586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8586 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Tupshin Harper >Priority: Major > Labels: dense-storage > Fix For: 4.x > > > This might turn into a meta ticket if other obstacles are found in the goal > of supporting a huge number of sstables. > Technically, the only gap that I know of to prevent us from supporting absurd > numbers of sstables is the fact that we hold on to an open filehandle for > every single sstable. > For use cases that are willing to take a hit to read-performance in order to > achieve high densities and low write amplification, a mechanism for only > retaining file handles for recently read sstables could be very valuable. > This will allow for alternate compaction strategies and compaction strategy > tuning that don't try to optimize for read performance as aggresively. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles
[ https://issues.apache.org/jira/browse/CASSANDRA-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8586: - Assignee: (was: Aleksey Yeschenko) > support millions of sstables by lazily acquiring/caching/dropping filehandles > - > > Key: CASSANDRA-8586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8586 > Project: Cassandra > Issue Type: New Feature >Reporter: Tupshin Harper > Labels: dense-storage > Fix For: 3.x > > > This might turn into a meta ticket if other obstacles are found in the goal > of supporting a huge number of sstables. > Technically, the only gap that I know of to prevent us from supporting absurd > numbers of sstables is the fact that we hold on to an open filehandle for > every single sstable. > For use cases that are willing to take a hit to read-performance in order to > achieve high densities and low write amplification, a mechanism for only > retaining file handles for recently read sstables could be very valuable. > This will allow for alternate compaction strategies and compaction strategy > tuning that don't try to optimize for read performance as aggresively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles
[ https://issues.apache.org/jira/browse/CASSANDRA-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8586: -- Labels: dense-storage (was: ) support millions of sstables by lazily acquiring/caching/dropping filehandles - Key: CASSANDRA-8586 URL: https://issues.apache.org/jira/browse/CASSANDRA-8586 Project: Cassandra Issue Type: New Feature Reporter: Tupshin Harper Assignee: Aleksey Yeschenko Labels: dense-storage Fix For: 3.1 This might turn into a meta ticket if other obstacles are found in the goal of supporting a huge number of sstables. Technically, the only gap that I know of to prevent us from supporting absurd numbers of sstables is the fact that we hold on to an open filehandle for every single sstable. For use cases that are willing to take a hit to read-performance in order to achieve high densities and low write amplification, a mechanism for only retaining file handles for recently read sstables could be very valuable. This will allow for alternate compaction strategies and compaction strategy tuning that don't try to optimize for read performance as aggresively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles
[ https://issues.apache.org/jira/browse/CASSANDRA-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8586: - Fix Version/s: 3.1 support millions of sstables by lazily acquiring/caching/dropping filehandles - Key: CASSANDRA-8586 URL: https://issues.apache.org/jira/browse/CASSANDRA-8586 Project: Cassandra Issue Type: New Feature Reporter: Tupshin Harper Assignee: Aleksey Yeschenko Fix For: 3.1 This might turn into a meta ticket if other obstacles are found in the goal of supporting a huge number of sstables. Technically, the only gap that I know of to prevent us from supporting absurd numbers of sstables is the fact that we hold on to an open filehandle for every single sstable. For use cases that are willing to take a hit to read-performance in order to achieve high densities and low write amplification, a mechanism for only retaining file handles for recently read sstables could be very valuable. This will allow for alternate compaction strategies and compaction strategy tuning that don't try to optimize for read performance as aggresively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
