[mlx]

Yeah I'm sure your product is great for those who can afford it and probably superior compared to the free solution. However we knew that before. No need to repeat it over and over again. I guess that's why some people become pissed off here. Easy as that.

Just my 2 cents though.

[TECK]

> No need to repeat it over and over again.
I totally agree. In the previous posts, I only replied to your technical question and passed the general questions.

Regards,

[Simetrical]

Originally Posted by TECK

If you do an "indexer --all --rotate" every 20min, you will blow your servers. It takes in average 20-30min to rebuild the indexes from scratch on a 10GB database. In my product, the indexes are updated every 10min, regardless of the database size. It takes in average 30sec-1min to refresh the data, all the time with no "indexer --all --rotate" commands used ever. Of course, that includes the threads/posts that were deleted or edited. What is the point to store a deleted post into indexes. Not to mention that if you edit the contents of a post, the deleted keywords should not be available into search. When you rebuild the indexes, all "errors" are gone... but that occurs every 24hrs for the vB.org product.

That doesn't seem like a huge advantage to me. The deltas seem to work well enough. I don't actually know how Sphinx works, though ― you're saying that the solution posted here, rotating only the deltas, doesn't pick up edited posts? Any other disadvantages to it?

[TECK]

Personally, I think it is important to have accurate results. If deleted or edited posts still show in search results (when it should not) as well that once a day you perform a full reindex (when you should not), that affects the overall search accuracy as well the server performance. Think of it this way: you have several threads in a forum where the users change a price for their "to be sold" items published few days ago. Because your search index is not updated right away (10min max), other forum users will never know that the price on certain items was revised until next day when indexes are rebuilt entirely...

A better example, related to search accuracy. Let's presume you use the default vBulletin search, query the entire posts for 'spaghetti' (most intensive) and display the results as threads. Then, you perform the same type of search with the vB.org Sphinx search. You will notice the number of missing results very easy, while performing the search with vB.org Sphinx product. There are many other aspects that I rather not cover, because it will sound like I'm trying to advertise my product... Fell free to ask more questions in my forum.

[charlie71]

Its a great piece of software!
May one of you can help me with my problem:

Search for word -> No results
Search for the same word again -> Results are found

[kontrabass]

Is there a definite solution for the "duplicate key" errors? Had been running Orban's original Sphinx solution for 2 years... Migrated site to new servers, then implemented Orbans version .1 solution. Now I'm getting these errors like many others in this thread:


MySQL Error : Duplicate entry 'c7ff13943221ad39284628de371af860-lastpost-DESC' for key 2
Error Number : 1062


I've tried repairing, optimizing, and truncating the table, No change

Someone mentioned modifying the php to read "REPLACE" instead of "INSERT" ? I'm running 3.6

Thanks!

[kmike]

Originally Posted by kontrabass

Someone mentioned modifying the php to read "REPLACE" instead of "INSERT" ? I'm running 3.6

I'm not sure why there are duplicate keys, but looking at the script, I guess that changing INSERT to REPLACE at the end of the script will indeed help.


Another note for those running Sphinx search: if you have "finduser" action handled by Sphinx, it will _not_ find user's posts comprised entirely of separators, i.e. not containing any accepted characters from Sphinx charset_table.
Some examples of the posts ignored by Sphinx:

.....

--------->

It may appear as not important, but it's something to remember when the user's post count differs from the number of his posts found by Sphinx.

[DaiTengu]

I'm looking to upgrade to 3.8, and I've seen a few posts stating that 0.1 is not working properly there. Can anyone confirm/deny this?

[mlx]

We are still using the old instructions with vB 3.8.2 and didn't hear any complaints yet, so I believe it's still working nicely. Not sure about that plugin version though.

[DaiTengu]

Originally Posted by mlx

We are still using the old instructions with vB 3.8.2 and didn't hear any complaints yet, so I believe it's still working nicely. Not sure about that plugin version though.

Yeah, I'm using the plugin version.


Maybe I'll just have to spend some time running some more test upgrades.

[mute]

Has anyone looked into the MySQL binary support in Sphinx 0.9.9? It seems to me like this would greatly simplify the integration of Sphinx into vB. The gist of it is:

"The ultimate new feature couple is MySQL binary protocol and SphinxQL query language. Meaning that searchd can now pretend it's mysqld. Meaning that you can use ye good olde mysql command-line client to connect to searchd and fire your queries using regular SELECT syntax!"

For more info: http://sphinxsearch.com/docs/current.html#sphinxql

[kmike]

SphinxQL isn't quite ready for the production at this moment.

[RedWingFan]

I've had an odd problem come up.

We only have Sphinx running on our private testing-only forum, where our staff puts it through the paces a bit. I noticed a few days ago that, during a search, I came up with this error message:

unknown local index 'threaddelta' in search request

Another of our staff got that error yesterday. I've been trying other searches on and off, but I can't duplicate the error.

On the server side, here's what I found. In my Sphinx data directory, all the files look OK, except for the threaddelta.* files. In fact, there is a set of threaddelta.* files that hasn't been touched since May 29. However, there is now a new group of files, threaddelta.new.* in the same directory that are getting updated every three minutes by our cron job.

I realize I could delete all the files rebuild the indexes, which I will do (this isn't exactly a critical forum, as it's just for testing), but I would still like to know how Sphinx is generating the "threaddelta.new.* files vs. the original "threaddelta.*" files. None of the config files or cron entries have been touched since last year, when I set this up.

We're about to roll out Sphinx on our main forum as we're getting slammed with traffic lately, but I'm still hesitant due to unresolved bugs...

[UK Jimbo]

Originally Posted by RedWingFan

On the server side, here's what I found. In my Sphinx data directory, all the files look OK, except for the threaddelta.* files. In fact, there is a set of threaddelta.* files that hasn't been touched since May 29. However, there is now a new group of files, threaddelta.new.* in the same directory that are getting updated every three minutes by our cron job.

Is the cronjob that's running the indexer creating any output?

Do you see any output if you run the indexer from the command line?

Can you copy/paste the command line you're using along with any output back here?

[mute]

Originally Posted by kmike

SphinxQL isn't quite ready for the production at this moment.

Well, a few months have gone by, hopefully Andrew has fixed most of the outstanding bugs by now. I'm still excited at the prospect of leaving most of the vB search code alone, and just hooking in before the queries get executing and diverting them to sphinx (or something along those lines).

Our sphinx implementation has been going strong for a few years now, and while we still don't have "Find all posts/threads" queries hitting it, or any of the new search functionality, I'm still enormously pleased with what it can do for you.