Този въпрос изисква много широк отговор, на който трябва да се отговори във всички аспекти. Има много добре определени спецификации, които могат да направят една система по-добра от друга за специален случай на употреба, но искам да покрия основите тук.
Ще се занимавам изцяло със Solr като пример за няколко търсачки, които функционират приблизително по същия начин.
Искам да започна с някои твърди факти:
-
Не можете да разчитате на Solr/Lucene като сигурна база данни. Има списък с факти защо, но те се състоят предимно от липсващи опции за възстановяване, липса на киселинни транзакции, възможни усложнения и т.н. Ако решите да използвате solr, трябва да попълните своя индекс от друг източник, като например SQL таблица. Всъщност solr е идеален за съхраняване на документи, които включват данни от няколко таблици и релации, които иначе биха изисквали конструиране на сложни съединения.
-
Solr/Lucene предоставя умопомрачителни функции за анализ на текст / извличане / оценка на търсене в пълен текст / размиване. Неща, които просто не можете да правите с MySQL. Всъщност пълнотекстово търсене в MySql е ограничено до MyIsam и точкуването е много тривиално и ограничено. Претеглянето на полетата, подобряването на документи по определени показатели, резултатите от резултатите въз основа на близостта на фразите, точността на съвпадението и т.н. е много тежка работа до почти невъзможна.
-
В Solr/Lucene имате документи. Не можете наистина да съхранявате връзки и процеси. Разбира се, можете да индексирате ключовете на други документи в многозначно поле на някакъв документ, така че по този начин всъщност можете да съхранявате 1:n релации и да го правите и по двата начина, за да получите n:n, но неговите данни режийни. Не ме разбирайте погрешно, той е идеален и ефективен за много цели (например за някакъв продуктов каталог, където искате да съхранявате дистрибуторите за продукти и искате да търсите само части, които са налични при определени дистрибутори или нещо подобно). Но стигате до края на възможностите с ИМА/НЕ. Почти не можете да направите нещо от рода на „вземете всички продукти, които се предлагат от поне 3 дистрибутора“.
-
Solr/Lucene има много хубави характеристики на фасетиране и анализ след търсене. Например:След много широко търсене, което е имало 40 000 посещения, можете да покажете, че ще получите само 3 попадения, ако прецизирате търсенето си до комбинацията от това поле да има тази стойност и това поле тази стойност. Неща, които се нуждаят от допълнителни заявки в MySQL, се извършват ефективно и удобно.
И така, нека обобщим
-
Силата на Lucene е търсене/анализ на текст. Освен това е умопомрачително бърз поради обратната структура на индекса. Наистина можете да извършите много последваща обработка и да задоволите други нужди. Въпреки че е ориентиран към документи и няма "запитване на графики", както правят тройните магазини със SPARQL, основните отношения N:M са възможни за съхраняване и запитване. Ако приложението ви е фокусирано върху търсене на текст, определено трябва да изберете Solr/Lucene, ако нямате основателни причини, като много сложни, многоизмерни заявки за филтриране на диапазон, за да направите друго.
-
Ако нямате текстово търсене, а нещо, където можете да посочите и щракнете върху нещо, но не и да въведете текст, добрите стари релационни бази данни вероятно са по-добрият начин.
