Monitoring MarkLogic History

by Eric Bloch

In MarkLogic 7, we introduced a new History Monitoring APIs and a dashboard to help you visualize the performance over time. These features are described nicely in our docs.

But, if you're still running MarkLogic 6, we've also made available a tool we've used in house called mlstat

mlstat is a command line tool that monitors various aspects of MarkLogic Server performance on Linux. It runs on the MarkLogic node itself and is modeled on the classic Unix tools like vmstat and mpstat. It is designed to be always on, running in the background redirecting it's output to a file. It has the ability to tag each line of output with an Epoch or timestamp so the data can be correlated with an event.


Range Index Scoring

by Adam Fowler

A new feature of MarkLogic 7′s search API is range index scoring – affecting relevancy based on a value within a document. Here I detail a couple of use cases

Range index scoring allows you to determine relevancy by values in a document, rather than matching values against a term exactly.

A good use case of this is for ratings. A higher rating should show nearer the top of search results.

A second use case of that of distance from the centre point of a geospatial query. Just like you get on hotel search websites.

We can now do these directly in MarkLogic without any special voodoo from a developer. Just set up the search options and perform a query. Easy!

Show me!

Below is the feature in action:


This uses MLJS for rendering results, but the functionality is in core MarkLogic, not MLJS. MarkLogic also calculates a heatmap on the fly. This calculated data is passed to heatmap-openlayers.js. Much more efficient than just sending lots of data to heatmap.js, especially for thousands of visible points.

Note that the MLJS widgets interact with each other – hovering over a marker on the map highlights it in the search results list with a different background colour.

Isn’t this like sorting?

In a word, no.

Sorting is based purely on a value in a document. By changing relevancy scores you can combine different search terms. For example, you could have rating and distance and a word query all contributing to the relevancy score. A result which is a little further but a much higher rating may trump one that’s dead centre on the map, but with a low rating.

How does it work?

Under the hood you provide a set of options and a query. I’ve documented the REST search options I’m using, and the search query I’m sending, and the results I’m getting back raw within a Gist. Go have a read, it’s pretty straight forward. (I tend to go overkill in setting search options though!)

In Summary

Ever wanted to tweak relevancy by values in a document? Now you can! Go have a read of this new V7 feature, download MarkLogic today too, and have a play!

This post original appeared on Adam's blog and we thank him for his permission to re-post here. The post is related to several other of his posts:

Partial Document Updates with the REST API

by David Cassel

I just got my first taste of one of the new features in MarkLogic 7: the ability to do partial document updates through the built-in REST API. It made me happy.

You may be aware that the REST API was introduced in MarkLogic 6. That version handles search and full-document CRUD operations. However, if you wanted to supplement a document with a little piece of information, you had two choices:

  1. maintain the entire document on the client side, update it there, then PUT the entire document to /v1/documents, replacing the entire document
  2. write an extension to the REST API that could do a more surgical update on the server side

I tended to do the second. MarkLogic 7 includes an new feature that provides a third choice, that will largely replace the second one:

  1. send a PATCH command to /v1/documents, specifying what the update should be

There is now a chapter in the REST API developers guide dedicated to this rich feature.

Deleting a comment

I’ve been working on a demo that has event data. When you click on an event, you can record a comment on it. My next task was to let the user delete a comment, which I can specify within an event by an id on the comment. The site is implemented using AngularJS, so here’s the code:

That’s it. Not a line of XQuery needed, just out-of-the-box functionality. Cool.

This article first appeared as a post on David's blog.

blogroll Blogroll