1
votes

Our requirement is to perform MarkLogic search capabilities on multiple MarkLogic databases. We have two version of Marklogic 7 & 8. There are two scenario for this requirement:

  1. Databases are available on one MarkLogic server.

    In this case we want to implement xdmp:eval(), xdmp:spawn(), and MarkLogic's Super-Database and Sub-Database concept. But, we are not sure which one is the prefect one.

  2. Databases are available on different MarkLogic server.

    We are not sure in this scenario, what to implement. But, we are exploring Hadoop and Flexible Replication of MarkLogic.

Please look into these scenario and share your best ideas so that we can move to correct direction.

1
It could be worth stepping back a little, and talk about why you think you need to do things this way. Could you elaborate? - grtjn
I know what your want to discuss. But, this is the client's requirement and we are exploring the possibilities. - Navin Rawat
Requirements aren't always sacred. :) - grtjn
Keep in mind that you can't cleanly merge results from two different databases into one relevance-ranked result set. This is true for any search engine as relevance is relative to the entire index and indexes are per-database. To keep things in one relevance-ranked result set you would segment using collections, not databases. - Sam Mefford

1 Answers

1
votes

As commented above, it could be worthwhile to take a step back, and discuss whether this is necessary. MarkLogic can handle mixtures of content very well. Having multiple databases will likely just overcomplicate the architecture.

That said, from the top of my head some considerations about your questions:

  • MarkLogic databases are not constrained to single servers, but to clusters.
  • You can use DB replication or Flex-Rep to synchronize databases between clusters.
  • xdmp:eval/spawn take overhead, and are a potential security hole (e.g. use amps).
  • super/sub database takes less overhead, but keep in mind that a range query across a super database will require matching range indexes to be defined in all databases included.
  • Ensuring database uri uniqueness across a super database takes extra effort.

HTH!