Thanks Geert !
The discussion is on the right track . As per Query profiling If I go for
the option 2 , no doubt I am getting performance improvement. But in this
scenario it is hard to trace out If I need to create element-value-query
or element-range-query .
option 2
To implement this consider application is sending criteria as follow
<criteria>
<criterion>
<element name="[element name]" type="[Value Query OR Word Query OR
Range Query]">
<values>
<value>californa</value>
<value>californa</value>
</values>
</element>
<field name="[field name]" type="[ Word Query]">
<values>
<value>USACA</value>
<value>USAFA</value>
</values>
</field>
</criterion>
</criteria>
Based on the above XML I can trace out if the query is required to be
element-value / field-word-query. But the drawback with this approach is
that application required the knowledge this constraint definition which
is improper in terms of architecture.
option 1
On the other hand if I use search:parse irrespective of constraint type
application will simply send "constr1:value1 AND constr2:value2" .
Application do not need to bother about constr1 and constr2 definitions
(element-value, element-range, field-word).
Can I use the constraint definition concept (option 1) for option 2. If
so my cts:query (kind of constraint-query) which will be more performance
efficient & generalized.
Thanks in advance !
Abhishek Srivastav
Systems Engineer
Tata Consultancy Services
Cell:- +91-9883389968
Mailto: [email protected]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
From:
Geert Josten <[email protected]>
To:
General MarkLogic Developer Discussion <[email protected]>
Date:
06/28/2011 12:28 PM
Subject:
Re: [MarkLogic Dev General] Query Parsing
Sent by:
[email protected]
Hi Abhishek,
One of the features of search:search is that it can parse the search
query. That requires string parsing, which usually gets exponentially
slower with the length of the string that needs to be parsed. Also,
search:search translates to something expressed in cts on the backend. So,
if you know really well what needs to be done, scenario 2 is likely to be
faster.
But you have to construct your query somehow, so that will take
performance anyhow. If you end up doing string parsing yourself, don?t
bother and use search:search. It also comes with additional goodies, you
probably don?t want to reinvent if you need them..
Kind regards,
Geert
Van: [email protected] [
mailto:[email protected]] Namens Abhishek53 S
Verzonden: dinsdag 28 juni 2011 7:28
Aan: General MarkLogic Developer Discussion
Onderwerp: Re: [MarkLogic Dev General] Query Parsing
Danny
Thanks for your reply . My question is more inclined to the performance of
parsing the query text using search:parse API OR creating the
element-value-query with the values.Query profiling suggest that the
process of parsing the query text using search:parse is taking more time
than creating the element-value-query.
Below is my testing scenario
Scenario 1
Using search:parse
import module namespace search = "http://marklogic.com/appservices/search";
at "/MarkLogic/appservices/search/search.xqy";
let $options := <options xmlns="http://marklogic.com/appservices/search";>
<constraint name="suggest" facet="true">
<range type="xs:string">
<element name="suggest"/>
</range>
</constraint>
</options>
return search:parse('suggest:"kolkata" OR
suggest:"kolkata.......to 10000 times"',$options)
(: Taking more time to parse the query :)
Scenario 2
cts:element-value-query(xs:QName("suggest"),("kolkata", "kolkata".......to
10000 times))
(: More efficient :)
Let me know your idea !
Thanks & Regards
Abhishek Srivastav
Systems Engineer
Tata Consultancy Services
Cell:- +91-9883389968
Mailto: [email protected]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
From:
Danny Sokolsky <[email protected]>
To:
General MarkLogic Developer Discussion <[email protected]>
Date:
06/28/2011 12:15 AM
Subject:
Re: [MarkLogic Dev General] Query Parsing
Sent by:
[email protected]
I am not sure I understand your question, but I?ll take a stab.
I would guess that using search:parse would be more efficient, but more
importantly, it will get you the query you want. Otherwise you will have
to reimplement it to parse the constraints. Is it taking a long time?
Have you tried profiling it to see where it is spending time?
-Danny
From: [email protected] [
mailto:[email protected]] On Behalf Of Abhishek53 S
Sent: Monday, June 27, 2011 11:05 AM
To: General MarkLogic Developer Discussion
Cc: [email protected]
Subject: [MarkLogic Dev General] Query Parsing
Hi Folks
(1) Currently my search application input is query text. eg
"constr1:value1 OR constr2:value2".This requires to be parsed separately
using search:parse API. The output query xml is converted to cts:query and
then passed to the additional query (required to be excluded for
highlighting). The query text can be very large and complex.
(2) In spite of sending the query text if the application send the
constraint values then the cts:query can be created and directly send to
the additional query. This can save the additional step of parsing the
query.
e.g. additional-query = cts:or-query(($some-xml//values))
My area of concern is which would be more efficient term of performance
1. Creating cts query (2) from the values sent from application
2. Parsing the query using search:parse (1) and then casting to cts:query
Thanks in advance !
Abhishek Srivastav
Systems Engineer
Tata Consultancy Services
Cell:- +91-9883389968
Mailto: [email protected]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
