Hi Brendon I'm not sure what Sphinx's base memory usage is with no documents (it's worth investigating), but I know that all attribute values for all documents are stored in memory - and so, the only difference between one instance and ten is that base memory usage - you'll still have the documents' attributes (split up over multiple instances or all in one) in memory anyway.
-- Pat On 09/11/2009, at 8:51 PM, Spike wrote: > > Thanks Mike, > > Sounds like a good idea, but I'm a bit concerned because of the number > of search instances that we'd be required to run. As I said in the > above reply we have about 100 schools, so that would mean having to > run 100 search daemons? I'm not sure of the details of how these > daemons work when they're not doing anything but I'd presume this > would be a slight tax on the system? > > I'd be interested to hear how many search instances you were > running. :) > > Cheers, > > Brendon > > On Nov 6, 8:48 pm, Mike Gunderloy <[email protected]> wrote: >> We had a similar requirement on one project. We ended up tackling it >> on two fronts. First, we ended up with a hacked-up configuration.rb >> inside of Thinking Sphinx that uses an internal MultiSite object from >> our code, which returns a string representing the current site. >> Here's >> part of it: >> >> @configuration.searchd.pid_file = "#{self.app_root}/log/ >> searchd.#{environment}.#{MultiSite.site}.pid" >> @configuration.searchd.log = "#{self.app_root}/log/ >> searchd.#{MultiSite.site}.log" >> @configuration.searchd.query_log = "#{self.app_root}/log/ >> searchd.query.#{MultiSite.site}.log" >> >> You get the idea: all the configuration stuff is namespaced by site >> name. Then we run one indexing daemon per site, so we actually have >> completely separate indexes for each of the sites (all of which have >> the exact same database schema, but different database instances, an >> architecture necessitated by some fairly strict business rules about >> what we can physically share between customers). Then, when an >> incoming request comes in that needs to use Sphinx for searching, we >> play games in the controller code to hook up to the right index: >> >> ThinkingSphinx::Configuration.instance.port = >> MultiSite.prop >> (:searchd_port) >> >> That points TS at an instance of sphinx whose port is keyed off the >> MultiSite object, and then it's off to the races to make .search >> calls >> to find data. >> >> Hope that helps, or at least gives you an architecture to start from. >> >> Mike >> >> On Nov 5, 2009, at 8:02 PM, Spike wrote: >> >> >> >> >> >>> Hi there, from my code hunting and general searching I've pretty >>> much >>> determined that thinking sphinx doesn't support indexing the same >>> models across a series of databases. >> >>> I have a CMS app and each clients data is stored in a separate >>> database for many reasons. When the rails app gets a connection it >>> looks at the hostname requested and switches databases >>> accordingly. It >>> all works quote well except when it comes to search. I managed to >>> get >>> Ferret to work with multiple databases by adding another key which >>> was >>> the database name to the ferret index. I also had someone hack >>> ultrasphinx so that it would encode the database in the upper digits >>> of the sphinx index. I've decided to make the switch to thinking >>> sphinx because the setup for ultrasphinx is both complicated and >>> fails >>> quite a lot (well the indexer does anyway). >> >>> Can someone point me in the right direction with regards to >>> modifying >>> thinking sphinx to work with multiple databases? From what I can >>> tell >>> most of the changes would be in the configuration.rb file where code >>> would have to be added to loop both databases and models and index >>> them appropriately. >> >>> Any tips would be greatly appreciated, and I would seriously >>> consider >>> paying to get it added as an official feature of thinking sphinx. >> >>> Looking forward to hearing from you :) >> >>> Brendon > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en -~----------~----~----~----~------~----~------~--~---
