Solr: Сандық өрістегі сүзгі сұрауының (белгілі бір мән үшін, ауқым сұрауы емес) өнімділігін қалай жақсартуға болады?

60-100 миллиондай құжат бар индекс бар. Біз бұл құжаттарды белгілі бір ата-аналық объектіге сұрауды шетелдік кілт идентификаторына (басқа сүзгі сұрауларына және өріс сұрауларына және т.б.) сұраймыз.

So, for example: /solr/q=*:*&fq=parent_id_s:42

Иә, бұл _s дегеніміз, бұл қазіргі уақытта solr.StrField өрісінің түрі болып табылады.

Менің сұрағым: TrieIntField дегенге өзгерту керек пе? Бұл өнімділікті жылдамдатады ма? Егер солай болса, мен әрдайым бір нақты мәнді сұрайтын болатынын білетінімді білетін болсам, precisionStep және positionIncrementGap мәндерінде қандай тамаша болады? parent_id 10,000-100,000 (максималды) шамасында?


Қосымша бөлшектер үшін түзету (төмендегі жауап туралы түсініктемеден): Біздің жүйемізді қалай пайдаланатынын білсек, көптеген сұраулар үшін сол fq-ды қолданамыз. Кэш толтырылған кезде жүйе тез өршіп кетеді. Кэш міндеттемеден бас тартқан кезде, бұл сұрау (тіпті бұл fq-мен бірге сынақ корпусы) 20 секундқа созылуы мүмкін. Сондықтан мен кэшті толтыратын бастапқы сұрауды жылдамдатуды анықтауға тырысамын.


Екінші түзету:

I apologize, after further testing it turns out that the above poor performance only happens when there are also facet fields being returned (e.g. stuff like &facet=true&facet.field=resolved_facet_facet). With a dozen or so of these fields, that's when the query takes up to 20-30 seconds sometimes, but only with a fresh searcher. It's instant when the cache is populated. So maybe my problem is the facet fields, not the parent_id field.

3
Көптеген идеялар. Өзіңіздің индексті SolrCloud-да сіңіре ме деп ойладыңыз ба? Бұл фильтр кэшін салу/сақтаудың ауыртпалығын кеңейтуге көмектеседі. Сіз жиі жасайсыз? Орындалғаннан кейін кэштеріңізді алдын ала орындайсыз ба? Сіз SirenDB секілді басқа иерархиялық іздеу шешімдерін қарастырдыңыз ба?
қосылды автор Doug T., көзі
Көптеген идеялар. Өзіңіздің индексті SolrCloud-да сіңіре ме деп ойладыңыз ба? Бұл фильтр кэшін салу/сақтаудың ауыртпалығын кеңейтуге көмектеседі. Сіз жиі жасайсыз? Орындалғаннан кейін кэштеріңізді алдын ала орындайсыз ба? Сіз SirenDB секілді басқа иерархиялық іздеу шешімдерін қарастырдыңыз ба?
қосылды автор Doug T., көзі
(1) Бізде епті бапкер болды, оның тәжірибесінен ол индексті ~ 10 миллион құжатқа шектеуге кеңес берді. Бұл көрсеткішінің сақталуын сіз индексті 10 шамға бөлуіңіз мүмкін. (2) басқа нәрсе, индексті сақтау үшін SSD деп ойладыңыз ба?
қосылды автор cheffe, көзі
(1) Бізде епті бапкер болды, оның тәжірибесінен ол индексті ~ 10 миллион құжатқа шектеуге кеңес берді. Бұл көрсеткішінің сақталуын сіз индексті 10 шамға бөлуіңіз мүмкін. (2) басқа нәрсе, индексті сақтау үшін SSD деп ойладыңыз ба?
қосылды автор cheffe, көзі
Екінші түзетуіңізге реакция жасау: Бұл өріс өрістерінің осы өріс түрлері қалай? Олар қарапайым жолдардан өзгеше ма? Егер солай болса, schema.xml файлынан өріс түрінің анықтамасын орналастыра аласыз ба?
қосылды автор cheffe, көзі
Екінші түзетуіңізге реакция жасау: Бұл өріс өрістерінің осы өріс түрлері қалай? Олар қарапайым жолдардан өзгеше ма? Егер солай болса, schema.xml файлынан өріс түрінің анықтамасын орналастыра аласыз ба?
қосылды автор cheffe, көзі
@cheffe Жақсы ой. Мен схеманы ғана тексеріп шығамын және олар тек анализаторларсыз қалыпты жолдар (олар бірнеше мәнге ие). Олардың кейбіреулері логикалық немесе «иә»/«жоқ» және материал болып табылады, сондықтан 2-4 ықтимал мәндер бар, олар үшін facet.method = enum қолданушыны әдепкі параметрлері . Мүмкіндігінше біршама жетілдірілген көрінеді, бірақ менің ойымша, автоматты түрде ауысып кетуді қалаймын, содан кейін менің қолымнан келгенше жақсы болуы мүмкін ...
қосылды автор Jeff Gran, көзі
@cheffe Жақсы ой. Мен схеманы ғана тексеріп шығамын және олар тек анализаторларсыз қалыпты жолдар (олар бірнеше мәнге ие). Олардың кейбіреулері логикалық немесе «иә»/«жоқ» және материал болып табылады, сондықтан 2-4 ықтимал мәндер бар, олар үшін facet.method = enum қолданушыны әдепкі параметрлері . Мүмкіндігінше біршама жетілдірілген көрінеді, бірақ менің ойымша, автоматты түрде ауысып кетуді қалаймын, содан кейін менің қолымнан келгенше жақсы болуы мүмкін ...
қосылды автор Jeff Gran, көзі
@cheffe Жақсы ой. Мен схеманы ғана тексеріп шығамын және олар тек анализаторларсыз қалыпты жолдар (олар бірнеше мәнге ие). Олардың кейбіреулері логикалық немесе «иә»/«жоқ» және материал болып табылады, сондықтан 2-4 ықтимал мәндер бар, олар үшін facet.method = enum қолданушыны әдепкі параметрлері . Мүмкіндігінше біршама жетілдірілген көрінеді, бірақ менің ойымша, автоматты түрде ауысып кетуді қалаймын, содан кейін менің қолымнан келгенше жақсы болуы мүмкін ...
қосылды автор Jeff Gran, көзі

8 жауаптар

TrieIntField with a precisionStep is optimized for range queries. As you're only searching for a specific value your field type is optimal.

Have you looked at autowarming queries? These run whenever a new IndexSearcher is being created (on startup, on an index commit for example), so that it becomes available with some cache already in place. Depending on your requirements, you can also set useColdSearcher flag to true, so that the new Searcher is only available when the cache has been warmed. For more details have a look here: https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig#QuerySettingsinSolrConfig-Query-RelatedListeners

4
қосылды
Сондай-ақ, менің екінші редакциямды сұраққа қойыңыз: бұл кэш кэшіне де қатысты бола ма? Сұраудың осы түрі үшін қандай кэшті маған автоматты түрде жылыту қажет?
қосылды автор Jeff Gran, көзі
Менің ойымша, сіз дұрыс жолда бола аласыз. Мен қазіргі уақытта кез-келген автокөлікті қолданбаймын. Менің талаптарымның бірі кез-келген құжаттарға кез-келген толықтырулар немесе жаңартулар бірден қолжетімді. Егер мен автожарғылықты пайдалансам және «суық іздестіргішті» қалдырсам, бұл маған қажет нәрсені істей ме? Жаңа ізденуші жылытылғанға дейін ескі зерттеуші әлі күнге дейін жаңартылған құжаттарды қолдана ма?
қосылды автор Jeff Gran, көзі
Мен суық іздестіргішті өшіргенде автожарғылықты енгізуді біраз кешіктіретініне сенемін, бірақ сіз екеуінің арасында жақсы тепе-теңдікті табу үшін эксперимент жасай аласыз. Бұған қоса, кэш автоматты түрде қосу мүмкіндігін қосу қажет болуы мүмкін, әсіресе. сүзгілер үшін: (толығырақ ақпаратты wiki.apache.org/solr/SolrCaching#autowarmCount қараңыз)
қосылды автор spyk, көзі
Сіздің екінші редакцияңызға қатысты сіздің ісіңіздің ұқсастығы бар деп ойлаймын: stackoverflow.com/questions/21565988/… , ол сондай-ақ автоматты түрде жылыну кезінде пайда болады.
қосылды автор spyk, көзі

TrieIntField with a precisionStep is optimized for range queries. As you're only searching for a specific value your field type is optimal.

Have you looked at autowarming queries? These run whenever a new IndexSearcher is being created (on startup, on an index commit for example), so that it becomes available with some cache already in place. Depending on your requirements, you can also set useColdSearcher flag to true, so that the new Searcher is only available when the cache has been warmed. For more details have a look here: https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig#QuerySettingsinSolrConfig-Query-RelatedListeners

4
қосылды
Сондай-ақ, менің екінші редакциямды сұраққа қойыңыз: бұл кэш кэшіне де қатысты бола ма? Сұраудың осы түрі үшін қандай кэшті маған автоматты түрде жылыту қажет?
қосылды автор Jeff Gran, көзі
Менің ойымша, сіз дұрыс жолда бола аласыз. Мен қазіргі уақытта кез-келген автокөлікті қолданбаймын. Менің талаптарымның бірі кез-келген құжаттарға кез-келген толықтырулар немесе жаңартулар бірден қолжетімді. Егер мен автожарғылықты пайдалансам және «суық іздестіргішті» қалдырсам, бұл маған қажет нәрсені істей ме? Жаңа ізденуші жылытылғанға дейін ескі зерттеуші әлі күнге дейін жаңартылған құжаттарды қолдана ма?
қосылды автор Jeff Gran, көзі
Мен суық іздестіргішті өшіргенде автожарғылықты енгізуді біраз кешіктіретініне сенемін, бірақ сіз екеуінің арасында жақсы тепе-теңдікті табу үшін эксперимент жасай аласыз. Бұған қоса, кэш автоматты түрде қосу мүмкіндігін қосу қажет болуы мүмкін, әсіресе. сүзгілер үшін: (толығырақ ақпаратты wiki.apache.org/solr/SolrCaching#autowarmCount қараңыз)
қосылды автор spyk, көзі
Сіздің екінші редакцияңызға қатысты сіздің ісіңіздің ұқсастығы бар деп ойлаймын: stackoverflow.com/questions/21565988/… , ол сондай-ақ автоматты түрде жылыну кезінде пайда болады.
қосылды автор spyk, көзі

TrieIntField with a precisionStep is optimized for range queries. As you're only searching for a specific value your field type is optimal.

Have you looked at autowarming queries? These run whenever a new IndexSearcher is being created (on startup, on an index commit for example), so that it becomes available with some cache already in place. Depending on your requirements, you can also set useColdSearcher flag to true, so that the new Searcher is only available when the cache has been warmed. For more details have a look here: https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig#QuerySettingsinSolrConfig-Query-RelatedListeners

4
қосылды
Сондай-ақ, менің екінші редакциямды сұраққа қойыңыз: бұл кэш кэшіне де қатысты бола ма? Сұраудың осы түрі үшін қандай кэшті маған автоматты түрде жылыту қажет?
қосылды автор Jeff Gran, көзі
Менің ойымша, сіз дұрыс жолда бола аласыз. Мен қазіргі уақытта кез-келген автокөлікті қолданбаймын. Менің талаптарымның бірі кез-келген құжаттарға кез-келген толықтырулар немесе жаңартулар бірден қолжетімді. Егер мен автожарғылықты пайдалансам және «суық іздестіргішті» қалдырсам, бұл маған қажет нәрсені істей ме? Жаңа ізденуші жылытылғанға дейін ескі зерттеуші әлі күнге дейін жаңартылған құжаттарды қолдана ма?
қосылды автор Jeff Gran, көзі
Мен суық іздестіргішті өшіргенде автожарғылықты енгізуді біраз кешіктіретініне сенемін, бірақ сіз екеуінің арасында жақсы тепе-теңдікті табу үшін эксперимент жасай аласыз. Бұған қоса, кэш автоматты түрде қосу мүмкіндігін қосу қажет болуы мүмкін, әсіресе. сүзгілер үшін: (толығырақ ақпаратты wiki.apache.org/solr/SolrCaching#autowarmCount қараңыз)
қосылды автор spyk, көзі
Сіздің екінші редакцияңызға қатысты сіздің ісіңіздің ұқсастығы бар деп ойлаймын: stackoverflow.com/questions/21565988/… , ол сондай-ақ автоматты түрде жылыну кезінде пайда болады.
қосылды автор spyk, көзі

Сүзгіден нәтиже жинақтарын кэштеуден көп пайда көрмейтін сияқты көрінеді. Сүзгілердің маңызды ерекшеліктерінің бірі - олардың нәтиже жиынын кэштеу. Бұл кэш салынған кезде белгілі бір сүзгінің бірінші іске қосылуын ұзағырақ етеді, бірақ сол фильтрді кейінгі пайдалану әлдеқайда жылдамырақ болады.

Сіз сипаттаған түбегейлі түрде, сіз циклдарды жұмсап, сүзгілерді кэшті ластауға, оларсыз кэштарды жасай аласыз. Сүзгі сұрауының кэштеуді өшіру мүмкін:

/solr/q=*:*&fq={!cache=false}parent_id_s:42
2
қосылды
егер мен дұрыс түсінсем, онда бұл бірегей ата-аналар_идінің жоқтығы деп ойлаймын? егер солай болса, оны кэштеу жалпы мағына береді. Индекс өлшемін ескере отырып, менің ойымша, ол қол жетімді жады бар. Қалай болғанда да, @Jeff Gran, жай ғана сізде бар хит коэффициентін (және қазіргі уақытта кэштегі сүзгілердің саны) жақсы ақпарат алу үшін беріңіз.
қосылды автор Persimmonium, көзі
@femtoRgon Бұл жақсы ой, бірақ бұл менің ісім үшін қолданылмайды. Біздің жүйемізді қалай пайдаланатынын білсек, көптеген сұраулар үшін сол fq-ды қолданамыз. Кэш толтырылған кезде жүйе тез өршіп кетеді. Кэш міндеттемеден бас тартқан кезде, бұл сұрау (тіпті бұл fq-мен бірге сынақ корпусы) 20 секундқа созылуы мүмкін. Сондықтан мен кэшті толтыратын бастапқы сұрауды жылдамдатуды анықтауға тырысамын.
қосылды автор Jeff Gran, көзі

Сүзгіден нәтиже жинақтарын кэштеуден көп пайда көрмейтін сияқты көрінеді. Сүзгілердің маңызды ерекшеліктерінің бірі - олардың нәтиже жиынын кэштеу. Бұл кэш салынған кезде белгілі бір сүзгінің бірінші іске қосылуын ұзағырақ етеді, бірақ сол фильтрді кейінгі пайдалану әлдеқайда жылдамырақ болады.

Сіз сипаттаған түбегейлі түрде, сіз циклдарды жұмсап, сүзгілерді кэшті ластауға, оларсыз кэштарды жасай аласыз. Сүзгі сұрауының кэштеуді өшіру мүмкін:

/solr/q=*:*&fq={!cache=false}parent_id_s:42
2
қосылды
егер мен дұрыс түсінсем, онда бұл бірегей ата-аналар_идінің жоқтығы деп ойлаймын? егер солай болса, оны кэштеу жалпы мағына береді. Индекс өлшемін ескере отырып, менің ойымша, ол қол жетімді жады бар. Қалай болғанда да, @Jeff Gran, жай ғана сізде бар хит коэффициентін (және қазіргі уақытта кэштегі сүзгілердің саны) жақсы ақпарат алу үшін беріңіз.
қосылды автор Persimmonium, көзі
@femtoRgon Бұл жақсы ой, бірақ бұл менің ісім үшін қолданылмайды. Біздің жүйемізді қалай пайдаланатынын білсек, көптеген сұраулар үшін сол fq-ды қолданамыз. Кэш толтырылған кезде жүйе тез өршіп кетеді. Кэш міндеттемеден бас тартқан кезде, бұл сұрау (тіпті бұл fq-мен бірге сынақ корпусы) 20 секундқа созылуы мүмкін. Сондықтан мен кэшті толтыратын бастапқы сұрауды жылдамдатуды анықтауға тырысамын.
қосылды автор Jeff Gran, көзі

Сүзгіден нәтиже жинақтарын кэштеуден көп пайда көрмейтін сияқты көрінеді. Сүзгілердің маңызды ерекшеліктерінің бірі - олардың нәтиже жиынын кэштеу. Бұл кэш салынған кезде белгілі бір сүзгінің бірінші іске қосылуын ұзағырақ етеді, бірақ сол фильтрді кейінгі пайдалану әлдеқайда жылдамырақ болады.

Сіз сипаттаған түбегейлі түрде, сіз циклдарды жұмсап, сүзгілерді кэшті ластауға, оларсыз кэштарды жасай аласыз. Сүзгі сұрауының кэштеуді өшіру мүмкін:

/solr/q=*:*&fq={!cache=false}parent_id_s:42
2
қосылды
егер мен дұрыс түсінсем, онда бұл бірегей ата-аналар_идінің жоқтығы деп ойлаймын? егер солай болса, оны кэштеу жалпы мағына береді. Индекс өлшемін ескере отырып, менің ойымша, ол қол жетімді жады бар. Қалай болғанда да, @Jeff Gran, жай ғана сізде бар хит коэффициентін (және қазіргі уақытта кэштегі сүзгілердің саны) жақсы ақпарат алу үшін беріңіз.
қосылды автор Persimmonium, көзі
@femtoRgon Бұл жақсы ой, бірақ бұл менің ісім үшін қолданылмайды. Біздің жүйемізді қалай пайдаланатынын білсек, көптеген сұраулар үшін сол fq-ды қолданамыз. Кэш толтырылған кезде жүйе тез өршіп кетеді. Кэш міндеттемеден бас тартқан кезде, бұл сұрау (тіпті бұл fq-мен бірге сынақ корпусы) 20 секундқа созылуы мүмкін. Сондықтан мен кэшті толтыратын бастапқы сұрауды жылдамдатуды анықтауға тырысамын.
қосылды автор Jeff Gran, көзі

Сондай-ақ, бұл жағдайда сүзгі сұрауы көмектеспейді деп ойлаймын. q = parent_id_s: 42 индексті «parent_id_s: 42» терминімен сұрау және оның идентификаторларын алу. Хабарламалар (құжат идентификаторлары) мерзіммен индекстелетіндіктен және сіз оны (JVM немесе ОЖ кэшінде) ұстап қалу үшін жеткілікті жадыңыз болғандықтан, бұл іздеу жылдам болуы керек.

Сүзгі кэшінің әлдеқашан қызғандығын және төмендегілердің бірі тезірек 100 пайыздық соқтығысу коэффициентін көресіз бе?

q=parent_id_s:42
fq=parent_id_s:42

Менің ойымша, олар өте жақын. Бірақ мен дұрыс болмас едім. Кез-келген адам біледі ме? Бұл үшін кез-келген білу өнімділігі сыналды ме?

0
қосылды

Сондай-ақ, бұл жағдайда сүзгі сұрауы көмектеспейді деп ойлаймын. q = parent_id_s: 42 индексті «parent_id_s: 42» терминімен сұрау және оның идентификаторларын алу. Хабарламалар (құжат идентификаторлары) мерзіммен индекстелетіндіктен және сіз оны (JVM немесе ОЖ кэшінде) ұстап қалу үшін жеткілікті жадыңыз болғандықтан, бұл іздеу жылдам болуы керек.

Сүзгі кэшінің әлдеқашан қызғандығын және төмендегілердің бірі тезірек 100 пайыздық соқтығысу коэффициентін көресіз бе?

q=parent_id_s:42
fq=parent_id_s:42

Менің ойымша, олар өте жақын. Бірақ мен дұрыс болмас едім. Кез-келген адам біледі ме? Бұл үшін кез-келген білу өнімділігі сыналды ме?

0
қосылды