This project from the State of Goiás Justice Prosecutor's Office, Brazil was shortlisted for this year’s inaugural Elastic Cause Awards.

<html><head></head><body>This project was shortlisted for this year&#x2019;s inaugural <a href="/causeawards">Elastic Cause Awards</a>, which recognizes organizations using the Elastic Stack to do great good in the world.
In 2010, we deployed in production the first version of a system that would change the way documents were managed in the State of Goi&#xE1;s Justice Prosecutor&apos;s Office, Brazil. It was an Electronic Document Manager named Atena (Athens), the &quot;Goddess of Wisdom&quot;, which was responsible for registering all the Citizen Claims as well as the Judicial, Extrajudicial, and Administrative processes, and their procedural steps, engaging them in workflows, among many other functionalities related to the management of documents within a judicial government institution.
Each process has an average of 7 related documents, which totalized, in the end of 2015, an amount of 15,626,816 processes. The global search functionality that was developed was unable to retrieve data in a satisfied manner. It used a PostgreSQL Full Text Search, which enabled phonetic matching, fuzzy search, ranking etc. However, the results weren&apos;t effective and also contributing to resource overhead, as the text search indexes (Gin) were much larger than the other PostgreSQL indexes. We defined some denormalized tables to store data redundantly and use them for search purpose. Although it improves performance, it was taking up more than 25% of disk space, in comparison to the other database tables. Besides all these issues, there wasn&#x2019;t enough available documentation for setting and tuning the PostgreSQL searches.
The users then began to face an annoying situation: the processes (and their documents) simply couldn&apos;t be found using it: precision, relevance, and performance issues were far from ideal. Slowly, the functionality became useless and, in the meantime, the complaints increased exponentially!
<h2>Getting to work</h2>Something needed to be done. How could we search among all this data in such a way that the users could find exactly (or at least, very close to) the information they wanted? It was like &quot;searching for needle in haystack&quot;. That&apos;s when Elasticsearch came on the scene!
It was set with 4 nodes, being all master and data, having 32GB RAM, 16 CPUs, 3 SSD disks (30GB for data and 150GB for log), each.
Due to technology issues, we needed to build a fresh new system. It was named Delfos and the first step was to design the index structure: which metadata would be relevant? Which filters should be applied? Which fields should be analyzed?
After a couple of meetings among users and team members, we decided for just one type, the process. The index mapping was defined with 56 fields that included objects (and their inner fields), strings, integers, longs, boolean and dates. We defined a single analyzer containing the filters: lowercase, asciifolding (our vocabulary had a lot of accent marks) and a customized stopword filter to the brazilian language. This analyzer was applied to 23 fields, which would be the searchable ones.
<h3>The Search</h3>The search phase design was the most painful. We defined two types of queries: a should term query and a query string. Just one of them is executed according to the user search term:
(1) <code>should term</code> query: defined for the exact processes&apos; number, documents&apos; number and some other numerical fields (a simple regular expression would verify the search term length and its type), which is shown below;
<pre class="prettyprint"> bool:{
 should: [
 {
 term: {
 process_number:
 {
 value: query,
 boost: 2.0
 }
 }
 },
 {
 term: {
 reference_number:
 {
 value: query
 }
 }
 },
 {
 term: {
 &apos;document.number&apos;:
 {
 value: query
 }
 }
 },
 {
 term: {
 &apos;court_hearing.number&apos;:
 {
 value: query
 }
 }
 },
 {
 term: {
 &apos;session_of_jury.number&apos;:
 {
 value: query
 }
 }
 }
 ],
 minimum_should_match: 1
 }
</pre>(2) a <code>query_string</code>: defined for the full-text search. Boost levels were specified for each searchable field. This feature was extremely important for our use case, as we had 23 searchable fields and some of them were much more used for querying than others, i.e., the name of a person involved in a specific process and the process&apos;s subject were much more required than the name of the process&apos;s creator department. We also set the following parameters:
<ul>
	<li>
	&apos;analyze_wildcard&apos;: true, our users often searched for part of the processes&apos; or documents&apos; numbers, i.e., &apos;*765993&apos;;
	</li>
	<li>
	default_operator: &apos;AND&apos;, we prioritized the precision rather than the volume.
	</li>
</ul>The <code>query_string</code> clause was almost done, but there was one more thing we needed to deal with: the most recent processes should have more relevance than the older ones. The sort clause couldn&apos;t be an option, as it would override the Elasticsearch relevance algorithm. We then inserted our <code>query_string</code> inside a <code>function_score</code> and defined a <code>gauss_function</code> to analyze the process date. The <code>function_score</code> was declared as follows:
<pre class="prettyprint">function_score:{
 query: {
 bool: {
 must: [
 {
 query_string: {
 query: &lt;em&gt;query&lt;/em&gt;,
 fields: %w( 
 process_number^12
 involved.name^11
 involved.type^11
 subjects^10
 court_hearing.number^7
 documents.number^7
 session_of_jury.number^7
 reference_number^7
 original_department^6
 court_hearing.verdict^5
 documents.type^5
 session_of_jury.verdict^5
 category.description^5
 process_type^4
 current_department_owner.name^4
 court_hearing.document.description^3
 court_hearing.document.files.content^3
 documents.description^3
 documents.files.content^3
 session_of_jury.document.description^3
 session_of_jury.document.files.content^3
 department_creator^2
 current_owner.name^1
 police_inquiry_number^1
 notes^1
 ),
 analyze_wildcard: true
 default_operator: &apos;AND&apos;
 }
 }
 ]
 }
},
functions: [
 {
 gauss: {
 process_date: {
 origin: &quot;now&quot;,
 scale: &quot;30d&quot;,
 decay: &quot;0.8&quot;
 }
 },
 weight: 20
 }
 ]
}
</pre>The gauss function balanced the final results exactly the way we were looking for! The group work <code>query_string</code>, boost levels and gauss function did a great job! Together, they put our global search in the next level!
A comparison among the legacy&apos;s global search and the new one shows how elasticsearch has improved it. Figure 1 shows the search result for &apos;guilherme ferias&apos; (&apos;F&#xE9;rias&apos; means &apos;vacation&apos; in Portuguese). It&apos;s expected that the first retrieved processes were related to the subject &apos;ferias&apos; and also contains the term &apos;guilherme&apos; in it, maybe as an involved person. It&apos;s possible to verify through figure 1 that the two first retrieved processes are not exactly what we needed, as their subjects were not &apos;ferias&apos;: the first one&apos;s subject is &quot;Solicita&#xE7;&#xE3;o de permuta&quot;, which means &quot;Exchange Request&quot; in English, and the second one&apos;s subject is &quot;Of&#xED;cio&quot;, which means &quot;Letter&quot; in English. Besides, the processes were not so recent as expected, as both dated from 2012. Searching for multiple terms on distinct fields were a problem that the previous application didn&apos;t deal with very well.
<figure>
<img src="https://api.contentstack.io/v2/uploads/58d2db849e59796f4ca6a05f/download?uid=blt2d30677c24db04da" data-sys-asset-uid="blt2d30677c24db04da" alt="1.gif">
<figcaption>Figure 1 - The previous search&apos;s poor retrieval</figcaption>
</figure>On the other hand, the same search resulted in a much more relevant retrieval in the new application. According to figure 2, it is possible to check that the processes returned on the first positions were very recent and were also related to &apos;Guilherme&apos; and &apos;ferias&apos;.
<figure>
<img src="https://api.contentstack.io/v2/uploads/58d2dcaaa7f26bbd47b47033/download?uid=bltd13839f5c0ae457f" data-sys-asset-uid="bltd13839f5c0ae457f" alt="2.gif">
<figcaption>Figure 2 - The new search&apos;s excellent retrieval</figcaption>
</figure><h3>Aggregations</h3>Our index structure was very complex, with lots of lists, objects, strings, dates, and numerical fields. The full-text search would help incredibly, but it wasn&apos;t enough. The next step was to ease (even more) the user&#x2019;s life! There were millions of documents and an aggregation display would be very useful: we then mapped 13 new raw fields in our index! It was almost impossible not to find what you wanted! Now, with just a few clicks, the users could get the single document they were searching for! Figure 2 shows some of these aggregation items.
The aggregation clause nested to our search definition was defined with the following terms: process type, current owner, current department owner, original department, creator department, document type, court hearing verdict, session of jury verdict, subject, involved ones, category, archived and process creation date.
Each selected term aggregation was inserted as a term clause inside the <code>function_score</code>&#xA0;-&gt; query -&gt; must clause array.
The process creation date was implemented to retrieve the following 5 range options, depending on the search result:
&#xA0;
<ol>
	<li>
	Earlier than a year
	</li>
	<li>
	Last 90 days
	</li>
	<li>
	Last 60 days
	</li>
	<li>
	Last 30 days
	</li>
	<li>
	Range date (one year maximum)
	</li>
</ol>When selected, this date field term aggregation is included as a date filter in our search body.
Our search body was complemented with highlight, sort and source features. In the moment this post was being written, our index consisted of 2,920,960 documents stored in 65 GB, which resulted in a document average size of 22kb! These numbers show how large in average our documents are. Because of that, we then decided to use highlight to help users finding the terms they are searching for among the thousands of words the retrieved documents possibly have. Figure 2 shows the highlighted terms in yellow.
Although the default sort was based on the score, we also specified two others possibilities: ordering by the last process and ordering by the last process&apos;s document.
<h3>Technology stack - A brief history</h3>When we decided to upgrade our Electronic Document Manager, besides the search engine solution, the front-end and the back-end layers should also urgently be upgraded. The current Flex layer wouldn&apos;t be supported by the most popular browsers within the next years, as well as the Rails version we were using, 2.3.8, didn&apos;t support many features we would like to develop.
Concerning the front-end issue, the team chose the AngularJS framework to replace it. It was a very good decision. One of its best contribution was the ui-sref parameter set to the &lt;a&gt; tag. It eases the developer&apos;s job while building the aggregation requests. We used the mergeMultipleValuesIntoParam and the pullValueFromParam methods to insert and remove, respectively, the aggregation terms selected and deselected by the user in a transparent way.
As we had to build a fresh new system, we couldn&apos;t simply stop the current one. The diagram in figure 3 shows how both applications communicate with each other.
<figure><img src="https://api.contentstack.io/v2/uploads/58d2dcc9fe63474847f4336f/download?uid=blt19a1d36287d269cb" data-sys-asset-uid="blt19a1d36287d269cb" alt="3.png" style="display: block; margin: auto;">
<figcaption>
Figure 3 - Application architecture</figcaption></figure> We decided for using the Resque service to call elasticsearch to index the data produced in the legacy system: (1) After any change occurred in a process registered in the legacy system, (2) (3) it immediately enqueued a job in a Redis server. This job is then executed by the Delfos&apos; workers: (4) they call a Postgres function which retrieves the process data in the JSON format and then (5) call the elasticsearch to index it.
If a new file was uploaded to a process in the legacy system (6), a specific job was enqueued (7) so that its content could be extracted by a tika server (8) (9). An ingenious solution grouping both tika lib and tesseract was developed so that if a document had embedded both text and image, the server could extract the content transparently. After the extraction, a resque job was enqueued so that the process could be indexed with the recent uploaded file (2).
<h3>What comes next?</h3>There is still a lot of work to do: from simple adjustments to complex features. These are some of them:
<ol>
	<li>
	Suggesters: as there are some complicated terms related to the judicial vocabulary, this feature would help users searching for the correct terms;
	</li>
	<li>
	Forcing highlight fields to be returned in the <code>_source</code>
	clause. This would enable us to highlight the fields, after the document selection, allowing users, for instance, to check which file (one of our fields) contains the highlighted term. Due to data traffic restrictions, we can&apos;t simply include the file content in the&#xA0;<code>_source</code> clause, as it may be too large. So, it would be interesting to include it only if it occurs a match on it</li>
	<li>Context: often, users from different areas or functions have distinct interests in terms of document relevance. For instance, it would be most relevant for users from some specific areas, the prioritization of processes created in by them or by their own department. On the other hand, for users from others areas, the most relevant are the processes which are on their ownership, regardless they were created by them. After defining these areas and their specific interests, a possible solution would be applying, dynamically, specific function score clauses associated to relevant fields which would set the appropriate weight according to the user&apos;s context</li>
	<li>Indexing the search terms: We consider creating an index to map: the user&#x2019;s search terms, the index of the document selected by the user on the page and the highlighted fields related to that selection. The purpose of this index is to help us figuring out which are the most common fields searched by the users so that we can update the boost levels of our query string fields. With respect to the selected document index, we aim to check the relevance of the search result to the users&apos; majority;</li>
	<li>Auto-complete: Everybody enjoys the feeling that the system guesses what we are thinking of!</li>
</ol><h3> Conclusion</h3>We are one of the first public institutions in Brazil with a real case of Elasticsearch delivering value in seconds for our customers with a massive volume of data. Today, we have approximately 2.9 million indexed processes having 21 million documents associated, resulting in approximately 65 GB in size. These numbers comprise processes beginning in 2010 and continuing to the present. As the population grows and so the number of processes for each prosecutor, the elasticsearch scalability will enable us to always deliver a great search solution to our users.
As there are some complex business rules to deal with and there is a lot of fields to be queried over, with distinct boosts and weights, it leads us to explore some real nice search capabilities Elasticsearch offers. The aggregations and the highlights features were the frosting on the cake.
Elasticsearch has exceeded our expectations. Arranged with services, third party products and libraries, and mainly, the team, it has enabled us to deliver the search product the institution was looking for. At least in the State of Goi&#xE1;s Justice Prosecutor&apos;s Office, searching for a needle in haystack is no longer so painful.
<hr>
	
<img src="https://api.contentstack.io/v2/uploads/58d55575899625a24c5d3709/download?uid=bltc995e5da50d5872f" data-sys-asset-uid="bltc995e5da50d5872f" alt="guilherme_maranhao_headshot.jpg" width="233" height="155" style="width: 233px; height: 155px; float: left; margin: 10px;">
Guilherme Melo e Maranh&#xE3;o is a software engineer at State of Goi&#xE1;s Justice Prosecutor&apos;s Office (<a href="http://www.mpgo.mp.br">MP-GO</a>) and responsible for the Delfos project. He has experience in web development, especifically with Ruby on Rails, and since 2016, he has been involved with the Elastic world.&#xA0;For further information on this project, please contact <a href="mailto:MAILTO:guilhermemaranhao@mpgo.mp.br">guilhermemaranhao@mpgo.mp.br</a>.
</body></html>

blog-haystack-fb.jpg

blog-haystack-thumb.jpg

Searching for needle in haystack

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Guilherme Melo e Maranhão

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

送信することにより、Elasticの<a href="/jp/legal/elastic-cloud-account-terms" target="_self">利用規約</a>を読み、同意したものと見なされます。また、上記で提供された連絡先に<a href="/jp/legal/privacy-statement#how-we-use-the-information" target="_self">特定の通知</a>が送信されることを認めたことになります。詳細については、<a href="/jp/legal/privacy-statement/" target="_self">Elasticのプライバシーポリシー</a>をご覧ください。これらの同意についてはいつでもオプトアウトすることが可能です。

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.

GDPR Text + Google Cloud

送信することにより、Elasticの<a href="/jp/legal/elastic-cloud-account-terms" target="_self">利用規約</a>を読み、同意したものと見なされます。また、関連する製品やサービスについて、上記で提供された情報を使用してElasticから<a href="/jp/legal/privacy-statement#how-we-use-the-information" target="_self">連絡する</a>場合があることを認めたことになります。詳細については、<a href="/jp/legal/privacy-statement/" target="_self">Elasticのプライバシー</a>ポリシーをご覧ください。これらの同意についてはいつでもオプトアウトすることが可能です。このフォームを送信することにより、Elasticが私の連絡先情報をGoogle Cloudに共有することに同意します。また、Elasticが私に食材パッケージを発送する目的で私の情報をベンダーに提供することにも同意します。

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

送信することにより、Elasticの<a href="/jp/legal/serverless-preview-terms" target="_self">利用規約</a>を読み、同意したものと見なされます。また、関連する製品やサービスについて、上記で提供された情報を使用してElasticから<a href="/jp/legal/privacy-statement#how-we-use-the-information" target="_self">連絡する</a>場合があることを認めたことになります。詳細については、<a href="/jp/legal/privacy-statement/" target="_self">Elasticのプライバシー</a>ポリシーをご覧ください。これらの同意についてはいつでもオプトアウトすることが可能です。

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

送信することにより、<a href="/jp/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud利用規約</a>に同意したものとみなされます。個人情報は<a href="/jp/legal/privacy-statement">Elasticのプライバシーポリシー</a>に基づいて取り扱われます。

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

送信することにより、Elasticの<a href="/jp/legal/terms-of-use" target="_self">利用規約</a>を読み、同意したものと見なされます。また、関連する製品やサービスについて、上記で提供された情報を使用してElasticから<a href="/jp/legal/privacy-statement#how-we-use-the-information" target="_self">連絡する</a>場合があることを認めたことになります。詳細については、<a href="/jp/legal/privacy-statement/" target="_self">Elasticのプライバシー</a>ポリシーをご覧ください。これらの同意についてはいつでもオプトアウトすることが可能です。

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

このページのコンテンツは、選択された言語ではご利用いただけません。Elasticでは現在、コンテンツをさまざまな言語でご利用いただけるよう取り組んでいます。お使いの言語が準備されるまでお待ちくださるようお願いいたします。

Author

Articles by

Watch now (no PT)

Watch now

See all top stories

すべてのトップストーリーを見る

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Search Integrations

All Solutions

Video for

See when this webinar starts in my time zone

現在のタイムゾーンでこのウェビナー開始時間を見る

Register to Watch

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

他の予定と重なってしまった…という場合も、問題ありません。参加登録されると、録画配信をご利用いただけます。関連コンテンツのご案内もメールでお届けします。

Author

Articles by Guilherme Melo e Maranhão Melo e Maranhão

Searching for needle in haystack

Sign up for Elastic Cloud free trial