Oké, zo zie ik het werken.
Ik heb precies hetzelfde probleem met MongoDB. MongoDB "biedt" zoekmogelijkheden, maar net als MySQL zou je ze nooit moeten gebruiken, tenzij je verstikt wilt worden door IO-, CPU- en geheugenproblemen en gedwongen wilt worden om veel meer servers te gebruiken om met je index om te gaan dan je normaal zou doen.
Het hele idee bij het gebruik van Sphinx (of een andere zoektechnologie) is om de kosten per server te verlagen door een performante indexzoeker te hebben.
Sphinx is echter geen opslagmotor. Het is niet zo eenvoudig om exacte relaties tussen tabellen op te vragen, ze hebben dit een beetje verholpen met SphinxQL, maar vanwege de aard van de volledige tekstindex doet het nog steeds geen integrale join zoals je zou krijgen in MySQL.
In plaats daarvan zou ik de relaties in MySQL opslaan, maar een index van "gebruikers" hebben binnen Sphinx.
Op mijn website heb ik persoonlijk 2 indexen:
- main (huisvest gebruikers, video's, kanalen en afspeellijsten)
- help (help systeem zoeken)
Deze worden eenmaal per minuut delta bijgewerkt. Omdat realtime-indexen soms nog wat experimenteel zijn en ik persoonlijk problemen heb gezien met hoge invoeg-/verwijderingspercentages, blijf ik bij delta-updates. Ik zou dus een delta-index gebruiken om de belangrijkste doorzoekbare objecten van mijn site bij te werken, aangezien dit minder arbeidsintensief is en beter presteert dan realtime-indexen (van mijn eigen tests).
Houd er rekening mee dat om verwijderingen en wat niet uw Sphinx-verzameling via delta te verwerken, u een killlist en bepaalde filters voor uw delta-index nodig heeft. Hier is een voorbeeld uit mijn index:
source main_delta : main
{
sql_query_pre = SET NAMES utf8
sql_query_pre =
sql_query = \
SELECT id, deleted, _id, uid, listing, title, description, category, tags, author_name, duration, rating, views, type, adult, videos, UNIX_TIMESTAMP(date_uploaded) AS date_uploaded \
FROM documents \
WHERE id>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) OR update_time >( SELECT last_index_time FROM sph_counter WHERE counter_id=1 )
sql_query_killlist = SELECT id FROM documents WHERE update_time>=( SELECT last_index_time FROM sph_counter WHERE counter_id=1 ) OR deleted = 1
}
Dit verwerkt elke minuut verwijderingen en toevoegingen, wat vrijwel realtime is voor een echte web-app.
Dus nu weten we hoe we onze indexen moeten opslaan. Ik moet het hebben over de relaties. Sphinx (ook al heeft het SphinxQL) zal geen integrale joins over gegevens doen, dus ik zou persoonlijk aanraden om de relatie buiten Sphinx te doen, niet alleen dat, maar zoals ik al zei, deze relatietabel zal zwaar worden belast, dus dit is iets dat van invloed kan zijn op de Sphinx-index.
Ik zou een query uitvoeren om alle id's te selecteren en die set id's gebruiken om de "filter" -methode op de sphinx-API te gebruiken om de hoofdindex te filteren tot specifieke document-id's. Zodra dit is gebeurd, kunt u normaal zoeken in Sphinx. Dit is de meest performante methode die ik tot nu toe heb gevonden om hiermee om te gaan.
Het belangrijkste om te onthouden is dat Sphinx een zoektechnologie is, terwijl MySQL een opslagtechnologie is. Houd dat in gedachten en je zou in orde moeten zijn.
Bewerken
Zoals @NB al zei (wat ik in mijn antwoord over het hoofd zag) heeft Sphinx SphinxSE. Hoewel primitief en nog steeds in een soort testfase van zijn ontwikkeling (hetzelfde als realtime indexen), biedt het Sphinx een echte MyISAM/InnoDB-opslag. Dit is geweldig. Er zijn echter kanttekeningen (zoals bij alles):
- De taal is primitief
- De joins zijn primitief
Het kan/zou echter het werk doen waarnaar u op zoek bent, dus zorg ervoor dat u er naar kijkt.