Return-Path: Delivered-To: apmail-incubator-cassandra-commits-archive@minotaur.apache.org Received: (qmail 6142 invoked from network); 14 Feb 2010 22:29:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Feb 2010 22:29:49 -0000 Received: (qmail 48793 invoked by uid 500); 14 Feb 2010 22:29:49 -0000 Delivered-To: apmail-incubator-cassandra-commits-archive@incubator.apache.org Received: (qmail 48777 invoked by uid 500); 14 Feb 2010 22:29:49 -0000 Mailing-List: contact cassandra-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-dev@incubator.apache.org Delivered-To: mailing list cassandra-commits@incubator.apache.org Received: (qmail 48767 invoked by uid 99); 14 Feb 2010 22:29:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Feb 2010 22:29:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Feb 2010 22:29:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 3C03A234C045 for ; Sun, 14 Feb 2010 14:29:28 -0800 (PST) Message-ID: <1431948846.266801266186568234.JavaMail.jira@brutus.apache.org> Date: Sun, 14 Feb 2010 22:29:28 +0000 (UTC) From: "Jonathan Ellis (JIRA)" To: cassandra-commits@incubator.apache.org Subject: [jira] Resolved: (CASSANDRA-791) Intelligent RAM Caching In-Reply-To: <541976366.266591266184887907.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-791. -------------------------------------- Resolution: Duplicate yes. James, see CASSANDRA-678 and CASSANDRA-688. > Intelligent RAM Caching > ----------------------- > > Key: CASSANDRA-791 > URL: https://issues.apache.org/jira/browse/CASSANDRA-791 > Project: Cassandra > Issue Type: New Feature > Components: Core > Reporter: James Churchman > > It should be possibly to predefine what cassandra holds in-momory and what it does not, or the priority of data to be cached. > An example would be a column family that stores huge amount of logs of user data, but the user rarely every access that data once it has been inserted. The other column family is the login details of each user, probably very tiny but all of it accessed hundreds of times day. When the large column family is updated i presume that all data healed in ram from the smaller one is removed from the ram? it would be preferable that priorities or specific "ram quotas" could be assigned to each column family to determine how lightly it is for the data to stay in ram. This would mean that memory caching programs like mem-cache that have that slightly finer level of control (by allocating each individual mem-chache a total amount of ram) would no longer be needed and it would simplify system design -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.