Yeah, I plan on it... there are still some features I want to add first... and also need to get it into the phrase system. I really just hacked it together in a few minutes as a diversion from what I'm *really* working on.Would love to have these Any chance of releasing them ?
Yeah, I plan on it... there are still some features I want to add first... and also need to get it into the phrase system. I really just hacked it together in a few minutes as a diversion from what I'm *really* working on.
But yes... I will release it when I can.
Truthfully, doing daily stats is probably more work than I'm willing to do for this... You can do it already with Google Analytics if you want (and it does it really well)...That would be awesome, would be even more awesome if you could add in the number of searches, the queries, average fetch times and other relevent information to the daily statistics so we could compare how busy periods and loads compare with postings and the like
Truthfully, doing daily stats is probably more work than I'm willing to do for this... You can do it already with Google Analytics if you want (and it does it really well)...
In your Analytics, go to Admin -> Profiles -> Profile Settings -> Site Search Settings
Enable it and set the query parameter to "q" (without quotes).
You can do some interesting stuff like tracking social interactions... but if you want stuff beyond Google+, it's a little tricky to set up since it requires some extra JavaScript...Oooh thankyou Are there any other nifty tricks you know? To be honest all i've ever used analytics for is to show our advertisers the levels of traffic we get, so haven't realy dug around for information like this.
From what I read recently, is not true. Elastic is a lot heavier on both resources and hardware. Personally, I don't think is fair to post this kind of information that makes Sphinx look like a cheap product. I worked with Sphinx for years and I know this product in and out.Sphinx is lighter weight than Elasticsearch (not by much), however Sphinx excels at simple queries and the need for the incremental indexes mean you have a dead time between an item being posted and being picked up.
So does Sphinx, with RT indices and a 10th of the resources normally used on Elastic.Elasticsearch has the benefit of getting around this, as items are indexed in real time and is much more flexible when it comes to advanced queries.
So does Sphinx, with agents.Elasticsearch also comes with out the box support for distributed resources, and if one node goes down, it automatically shifts control to the other nodes, it also allows for similar documents to be compared and retrieved, something Sphinx cannot do.
So far from what I read, not true. Elastic requires 150 times more resources, compared to Sphinx.To add in, depending on your content type and mapping, ES can also have a lesser impact on your servers resources.
From what I read recently, is not true. Elastic is a lot heavier on both resources and hardware. Personally, I don't think is fair to post this kind of information that makes Sphinx look like a cheap product. I worked with Sphinx for years and I know this product in and out.
So does Sphinx, with RT indices and a 10th of the resources normally used on Elastic.
So does Sphinx, with agents.
So far from what I read, not true. Elastic requires 150 times more resources, compared to Sphinx.
Quick example: a board with 35 million docs requires 70GB of RAM with Elastic, and only 3GB with Sphinx to produce similar results.
I thought so and I appreciate your input. I just wanted to make sure people are aware.At the time of posting on the testbed I was using that information was pretty accurate. (which was compairing a beta version of ES and a user created sphinx search for xf)
In light of now ramping that up to much larger scales my previous post was you pointed out was mostly incorrect.
Well, for starters, you would not need multiple shards with Sphinx. OK, if you need a setup like Craiglist with 3 billion documents, just use a mix of real life and archive indices with a master/slave scheme. Extremely easy to maintain, they currently use 2 masters and 8 slaves to serve their search data. I'm looking forward to see you posting real time specs and Elastic results from your 20 million documents database.Okay... I have a *little* more experience with ES now... And the more I play with it, the more I like it. It does some things that I wish Sphinx would do... for example it's ability to auto-shard and replicate to other nodes (servers) is pretty seamless and awesome.
I thought so and I appreciate your input. I just wanted to make sure people are aware.
Well, for starters, you would not need multiple shards with Sphinx. OK, if you need a setup like Craiglist with 3 billion documents, just use a mix of real life and archive indices with a master/slave scheme. Extremely easy to maintain, they currently use 2 masters and 8 slaves to serve their search data. I'm looking forward to see you posting real time specs and Elastic results from your 20 million documents database.
Quick example: a board with 35 million docs requires 70GB of RAM with Elastic, and only 3GB with Sphinx to produce similar results.
So I decided to do some testing with my multi-threaded reindexer and ran a full index a couple times. Just to see what the difference was with the exact same data, I did it once *with* _source (XF includes it in ES index by default) and once without. It's a pointless bit of data... it just stores the original document you are indexing.
WITH _source included, the index was 14.7GB, without it, the index ended up being 7.09GB... so less than half the size just by removing the unused _source field.
Some stuff will be shared for sure... but it's not going to be a, "Here's everything... go make a clone of my site now." situation...Heh, I've always had a "two steps forward, one step back" feeling with Java too. Congrats on switching over to XF though, that must have been an insane amount of work for you. Any plans on sharing what you've done with XF on your site as a more complete package? I'd gladly pay for it.
We use essential cookies to make this site work, and optional cookies to enhance your experience.