Эфектыўнае Джанго паўнатэкставы пошук без Хейстек

Які наступны лепшы варыянт для базы дадзеных агностыку паўнатэкставага пошуку для Django без Haystack?

У мяне ёсць мадэлі, як:

class Paper(models.Model):
    title = models.CharField(max_length=1000)

class Person(models.Model):
    name = models.CharField(max_length=100)

class PaperReview(models.Model):
    paper = models.ForeignKey(Paper)
    person = models.ForeignKey(Person)

Мне трэба шукаць для работ па назве і імя рэцэнзента, але я таксама хачу, каб шукаць з пункту гледжання чалавека, і высветліць, якія дакументы ў іх ёсць і не рэцэнзуюцца. З Хейстек, гэта проста рэалізаваць паўнатэкставы індэкс для пошуку па назве і імёнаў палёў, але, наколькі я магу сказаць, што няма ніякага спосабу, каб зрабіць «левае вонкавае аб'яднанне» неабходна знайсці дакументы без разгляду канкрэтнага чалавека ,

2

7 адказы

Стог з'яўляецца проста абалонкай, якая дае некалькі розных рухавічкоў пошукавых сістэм:

  • Solr
  • ElasticSearch
  • Свіст
  • Xapian

Там могуць быць і іншыя рухавікі, а таксама даступныя ў выглядзе убудоў.

Такім чынам, рэальны пытанне тут, значыць пошук бэкенд, які дае мне патрэбную функцыянальнасць, і ня стозе выкрыць гэтую функцыянальнасць?

Адказ на гэтае пытанне, вы, верагодна, можна выкарыстоўваць elasticsearch *, але зьвярніце ўвагу на Asterix.

Як правіла, пры стварэнні індэкса пошуку, гэта добрая ідэя, каб думаць пра дакументы, у тым жа, як вы, магчыма, калі вы ствараеце базу дадзеных не-отна і вы хочаце, каб гэтыя дакументы, каб быць як мага больш плоскімі.

Такім чынам, адна з магчымасцяў можа быць, каб мець масіў знакавых палёў на індэксе paperreview. Масіў будзе змяшчаць усе адпаведныя спасылкі на знешнія ключы.

Іншы можа быць выкарыстанне «ўкладзеных дакументаў» у elasticsearch.

І, нарэшце, выкарыстоўваць «бацька/нашчадак дакументы» у elasticsearch.

Вы ўсё яшчэ можаце выкарыстоўваць стог для індэксацыі, з некаторым хакерство, але вы, верагодна, захочаце выкарыстоўваць адзін з сырых бэкэнд непасрэдна, напрыклад, pyelasticsearch або pyes.

1
дададзена
Я думаю, што мая больш агульная кропкай з'яўляецца тыпам пошуку я раблю гэта непрыдатна для тыпу функцыянальнасці пошуку Стагі абгортак. Магчыма, індэксаваная табліцы SQL ручкі левае вонкавае вельмі эфектыўна ўключаецца, і нават апрацоўваць паўнатэкставай пошук таксама ў некаторых выпадках. Я паспрабаваў Свіст (жудасны), Solr і ElasticSearch, і ніхто не апрацоўваць гэты канкрэтны выпадак вельмі добра.
дададзена аўтар Cerin, крыніца
@Cerin Ці вы чыталі мае каментары вышэй пра бацька/нашчадак дакументаў у elasticsearch?
дададзена аўтар James R, крыніца

Стог з'яўляецца проста абалонкай, якая дае некалькі розных рухавічкоў пошукавых сістэм:

  • Solr
  • ElasticSearch
  • Свіст
  • Xapian

Там могуць быць і іншыя рухавікі, а таксама даступныя ў выглядзе убудоў.

Такім чынам, рэальны пытанне тут, значыць пошук бэкенд, які дае мне патрэбную функцыянальнасць, і ня стозе выкрыць гэтую функцыянальнасць?

Адказ на гэтае пытанне, вы, верагодна, можна выкарыстоўваць elasticsearch *, але зьвярніце ўвагу на Asterix.

Як правіла, пры стварэнні індэкса пошуку, гэта добрая ідэя, каб думаць пра дакументы, у тым жа, як вы, магчыма, калі вы ствараеце базу дадзеных не-отна і вы хочаце, каб гэтыя дакументы, каб быць як мага больш плоскімі.

Такім чынам, адна з магчымасцяў можа быць, каб мець масіў знакавых палёў на індэксе paperreview. Масіў будзе змяшчаць усе адпаведныя спасылкі на знешнія ключы.

Іншы можа быць выкарыстанне «ўкладзеных дакументаў» у elasticsearch.

І, нарэшце, выкарыстоўваць «бацька/нашчадак дакументы» у elasticsearch.

Вы ўсё яшчэ можаце выкарыстоўваць стог для індэксацыі, з некаторым хакерство, але вы, верагодна, захочаце выкарыстоўваць адзін з сырых бэкэнд непасрэдна, напрыклад, pyelasticsearch або pyes.

1
дададзена
Я думаю, што мая больш агульная кропкай з'яўляецца тыпам пошуку я раблю гэта непрыдатна для тыпу функцыянальнасці пошуку Стагі абгортак. Магчыма, індэксаваная табліцы SQL ручкі левае вонкавае вельмі эфектыўна ўключаецца, і нават апрацоўваць паўнатэкставай пошук таксама ў некаторых выпадках. Я паспрабаваў Свіст (жудасны), Solr і ElasticSearch, і ніхто не апрацоўваць гэты канкрэтны выпадак вельмі добра.
дададзена аўтар Cerin, крыніца
@Cerin Ці вы чыталі мае каментары вышэй пра бацька/нашчадак дакументаў у elasticsearch?
дададзена аўтар James R, крыніца

Я ведаю, што гэтае пытанне старэй, але я правёў некаторы час расследавання гэтага нядаўна і адказаў на гэтае, а тут , але гэта на самай справе не так ужо цяжка ажыццявіць гэта самастойна, і хацеў бы падзяліцца.

Я знайшоў SearchVector/SearchQuery падыход фактычна не ловіць ва ўсіх выпадках, напрыклад, частковых слоў (гл https://www.fusionbox.com/blog/detail/partial-word-search-with-postgres-full-text-search-in-django/632/ для даведкі ). Вы можаце рэалізаваць свой уласны без асаблівых праблем, у залежнасці ад вашых абмежаванняў. Напрыклад, у рамках get_queryset метад а viewsets ':

    ...other params...

            search_terms = self.request.GET.get('q')
            if search_terms:
                # remove possible other delimiters and other chars
                # that could interfere
                cleaned_terms = re.sub(r'[!\'()|&,]', ' ', search_terms).strip()
                if cleaned_terms:
                    # Check against all the params we want
                    # apply to previous terms' filtered results
                    q = reduce(
                        lambda p, n: p & n,
                        map(
                            lambda word:
                                Q(your_property__icontains=word) | Q(
                                    second_property__icontains=word) | Q(
                                    third_property__icontains=word)
                            cleaned_terms.split()
                        )
                    )
                    qs = YourModel.objects.filter(q)
           return qs
1
дададзена

Я ведаю, што гэтае пытанне старэй, але я правёў некаторы час расследавання гэтага нядаўна і адказаў на гэтае, а тут , але гэта на самай справе не так ужо цяжка ажыццявіць гэта самастойна, і хацеў бы падзяліцца.

Я знайшоў SearchVector/SearchQuery падыход фактычна не ловіць ва ўсіх выпадках, напрыклад, частковых слоў (гл https://www.fusionbox.com/blog/detail/partial-word-search-with-postgres-full-text-search-in-django/632/ для даведкі ). Вы можаце рэалізаваць свой уласны без асаблівых праблем, у залежнасці ад вашых абмежаванняў. Напрыклад, у рамках get_queryset метад а viewsets ':

    ...other params...

            search_terms = self.request.GET.get('q')
            if search_terms:
                # remove possible other delimiters and other chars
                # that could interfere
                cleaned_terms = re.sub(r'[!\'()|&,]', ' ', search_terms).strip()
                if cleaned_terms:
                    # Check against all the params we want
                    # apply to previous terms' filtered results
                    q = reduce(
                        lambda p, n: p & n,
                        map(
                            lambda word:
                                Q(your_property__icontains=word) | Q(
                                    second_property__icontains=word) | Q(
                                    third_property__icontains=word)
                            cleaned_terms.split()
                        )
                    )
                    qs = YourModel.objects.filter(q)
           return qs
1
дададзена

Я скончыў з выкарыстаннем djorm-доб-pgfulltext , які прадастаўляе просты інтэрфейс Django для ўбудаваных поўнага набору функцый пошуку тэксту ў PostgreSQL.

0
дададзена

Я скончыў з выкарыстаннем djorm-доб-pgfulltext , які прадастаўляе просты інтэрфейс Django для ўбудаваных поўнага набору функцый пошуку тэксту ў PostgreSQL.

0
дададзена

Я выкарыстоўваю Стог + эластычны пошук і да гэтага часу яго працу даволі добра. Не думайце яго трывіяльным. Вы можаце лёгка рэалізаваць вашыя патрабаванні, калі Theres асацыяцыі паміж папяровым і чалавекам.

0
дададзена