Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9B6F49B74 for ; Thu, 29 Sep 2011 16:30:55 +0000 (UTC) Received: (qmail 59782 invoked by uid 500); 29 Sep 2011 16:30:53 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 59728 invoked by uid 500); 29 Sep 2011 16:30:53 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 59719 invoked by uid 99); 29 Sep 2011 16:30:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Sep 2011 16:30:52 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of anthony.ikeda.dev@gmail.com designates 209.85.210.172 as permitted sender) Received: from [209.85.210.172] (HELO mail-iy0-f172.google.com) (209.85.210.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Sep 2011 16:30:43 +0000 Received: by iaby26 with SMTP id y26so1079179iab.31 for ; Thu, 29 Sep 2011 09:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=EHnUKACwYBKzVQxTnMmBb8/dyqiC6xZTrA2OC9pQchc=; b=UqsiYOy0B/hTAPD7l+Qt93Swiz05HYtmrFD64ipP7k1k0RHVNpvrYVIJwRMS2drWB0 wQp9/+bpqRIK5iED/13C8wp/CyzFmbt8BX1uaotNGGz+FOY0LQS2KYMym2QQsgOb4ZA9 Uc98yM5PX6EVJVlHtTqtqySfpkX5qA+gEKwMk= Received: by 10.43.134.72 with SMTP id ib8mr1080785icc.94.1317313822923; Thu, 29 Sep 2011 09:30:22 -0700 (PDT) Received: from [10.0.1.9] (c-24-5-79-250.hsd1.ca.comcast.net. [24.5.79.250]) by mx.google.com with ESMTPS id r14sm3217306ibe.7.2011.09.29.09.30.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Sep 2011 09:30:22 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) Subject: Re: Best indexing solution for Cassandra From: Ikeda Anthony In-Reply-To: Date: Thu, 29 Sep 2011 09:30:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87466F03-AA07-4A1D-97B1-6DEF1862EED0@gmail.com> References: <1317242745.69767.YahooMailNeo@web130113.mail.mud.yahoo.com> To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1244.3) X-Virus-Checked: Checked by ClamAV on apache.org =46rom a usability standpoint, elastic search is looking promising. I'll = have to get more info through use on it's distribution as well. Thanks :) On 28/09/2011, at 14:01 PM, Mohit Anchlia wrote: > look at elasticsearch too. It shards differently. >=20 > On Wed, Sep 28, 2011 at 1:45 PM, Rafael Almeida = wrote: >> =46rom Anthony Ikeda : >>> Well, we go live with our project very soon and we are now looking = into what we will be doing for the next phase. One of the enhancements = we would like to consider is an indexing platform to start building = searches into our application. >>>=20 >>>=20 >>> Right now we are just using column families to index the information = (different views based on what we want to find) however it is proving to = be quite a task to keep the index views in sync with the data - although = not a showstopper, it isn't something we want to be handling all the = time especially since operations like deletions require changes to = multiple column families. >>>=20 >>>=20 >>> I've heard of Solandra and Lucandra but I want to understand the = experiences of people that may have used them or other suggestions. >>=20 >>=20 >> I've had some experience with that. My main problem was that I had a = limited vocabulary and a large number of documents. It seems like = solandra kept all my documents on the same row for a given term. That = means the documents don't get spread out throught the cluster and search = was painfully slow. We ended up rolling up our own solution and not = using cassandra at all for that purpose (althought we still use it for = storage). >>=20 >>=20