---

robots : noindex , nofollow
tags : exist, atelier
---

# Atelier Exist db - Version Francaise - 24/09/20

[TOC]

:::info
**Video**
:movie_camera: https://minio.stable.innovation.insee.eu/fhddha/ExistDB/2020-09-25-AtelierExistDB.mp4 (accessible en interne Insee uniquement)
//TODO rendre accessible la video pour Exist Solutions => Done
:::

## Présentation de Monex
- Passage en revue des différentes fonctionnalités
- Accès aux infos JMX sur la base exist EXIST_URL/exist/status utile si Monex ne répond plus, nécessite un token ou un compte admin.

Monex peut être utilisé pour plusieurs bases de données mais ce n'est pas recommandé comme seul instrument de supervision. Surtout utile pour les travaux de développement.

### Data brokers
Permet de définir le nombre d'utilisateurs simultanés dans la même ms.
20 brokers est une bonne valeur par défaut.
En cas de problème, augmenter le nombre de data brokers n'est pas forcément la solution : le problème vient plus souvent des requêtes lentes car beaucoup de requêtes lentes = beaucoup de brokers occupés.

### Cache manager

Bon à savoir : dans le fonctionnement interne, les XML sont gérés comme des documents.

Des indexes sont créés à partir du parsing des documents.

Exist ne connaît pas la structure des données.

Dans Exist, il faut entraîner la base pour travailler sur nos données => c'est le rôle des index.

### Recent queries

Permet de tracer les requêtes au délà d'un certain seuil (100ms par défaut).

### Waiting threads

Normal qu'il y en ait pour des longues requêtes.
Sur des instances avec 20 à 50 utilisateurs, il est normal d'avoir des waiting threads.
Cocher "track request URI".

### Profiling

Utile mais ralentit le système, à n'utiliser qu'en phase de developpement. En activant le tracing, permet de voir les temps d'execution (au niveau requete/fonction) ainsi que l'usage des index

### Indexes

"Browses indexes" : permet de voir la configuration des indexes.

Dans le tableau, frequency : nombre total d'éléments // documents : nombre total de documents avec l'élément indexé.

### Remote console

Permet d'accéder à des logs qui ne seraient accessibles que par un accès SSH.
On peut également écrire dans la log.
Par contre il faut garder le browser avec Monex ouvert sinon on perd les affichages.

exemple :

let $test :=file:read(system:get-exist-home() || "/webapps/WEB-INF/log/sheduler.log")
return (console:log($test),$test)

Nécessite un compte admin (ou dba ?).

:question: @ExistSolutions : vous nous conseillez de disposer de comptes admin sur les bases de developpement / recette ?

## Requêtes lentes

### Etude de la recherche d'un contact

- Quelques remarques :
- "matches" : l'expression est coûteuse
- "eval " is evil !
- il y a des expressions avec lesquelles on ne peut pas utiliser d'index comme "contains"

:question: @ExistSolutions : on peut avoir la liste des expressions qui n'utilisent pas les index ?
:question: @ExistSolutions : "Cache makes my appli slow" => cache à revoir?

- Présence de log dans le code Xquery peut ralentir les requêtes même si ce n'est pas le point essentiel lié à la lenteur. A voir comment gérer proprement (pour pouvoir switcher facilement le niveau de log ?)

- Nouveauté dans ExistDB 5 : utilisation des facet (?) permettrait d'accéler la recherche. Nécessite paramétrage + réécrire la façon dont on fait la recherche.

#### Problème sur les collections de plus de 100 000 fichiers

- Le problème semble connu de faire des requêtes sur des collections importantes de plus de 100 000 fichiers.
- Pas sûr que ce soit réglé dans les dernières versions. Lars va regarder. De notre côté, on pourrait tester sur une nightly build (même localement).
- [voir](https://github.com/eXist-db/exist/issues/3466)

- Si on n'a pas de patch ou qu'on ne demande pas à Exist Solution de fixer le problème (quelques jours de développements ?), il y a des workaround.
Exemples :
1. Créer un fichier de contact unique (gros fichier !)
2. séparer les contacts des habilitations (habilitations = la plus grande partie des fichiers de contacts les plus gros)
3. organisation des contacts avec des sous-répertoires comportant les deux premières lettres du nom

- Avec la fourniture de Contact.xqm + fake data => Lars peut nous proposer une optimisation.

:::danger
Lars propose d'en discuter en interne (1h) et revenir vers nous pour nous proposer différentes options.
:::

:question: @Exist-Solutions Si on confirme qu'il y a bien un bug sur les collections de grande taille et que cela concerne certaines traitements en production pour Coltrane, ne pourrions nous pas faire appel au marché de support pour que Exist Solutions développe le "fix" nécessaire ?

Présentation du github : https://github.com/eXist-db/exist
Issues => https://github.com/eXist-db/exist/issues

## Indexes

- Les lenteurs à l'indexation peuvent également être liées à un nombre important de fichiers dans une même collection.

- Temps d'indexation : sur les indexations de 24h, une nouvelle session sera nécessaire pour investiguer plus dans les données et comprendre les lenteurs. Normalement elles devraient durer quelques minutes.

- A fournir : l'arborescence vide des collections avec le nombre de fichiers à l'intérieur pour qu eXistDb puisse se faire une idée de l'organisation de la base et du nombre de fichiers par collection.

## Bonnes pratiques pour copier les données de la production

eXistdb backup pas recommandé avec les grosses bases de données : pas assez rapide, bloque les utilisateurs.

Les solutions à base de Snapshot sont préférables.

Si on peut arrêter la base, on peut utiliser RSYNC pour synchroniser l'arborescence des fichiers de la base eXist. Toutes les données d eXist sont synchronisées lors de l'arrêt de la base, on n'a plus qu'à synchroniser les fichiers ensuite.

Import et export permettent de copier des données dans toutes les versions de la 1 à la 5. C'est lent mais ça marche. Sinon c'est périlleux de récupérer les fichiers binaires eXist qui ne sont pas compatibles d'une version (même mineure dans certaines cas) à l'autre.

Se pose la question des credential lors de la copie pour ne pas avoir les mêmes credential entre QF3 et production... Lars pourrait nous proposer un mode opératoire pour gérer cela.

## Prochaine session

- System structure, organisation des collections, étude de fichiers "systeme": dom.dbx, autres dbx , ...)
- besoin d'un accès SSH !

- Recommandations pour le problème des collections et les questions de sauvegarde.

- Tentative d explications sur les reindexations trop lentes >20 heures
- fourniture possible en amont des scripts de sauvegarde / restauration des bases (Jerem: Possible saturation de la ram lors de l'opération de réindexation, avec utilisation du swap, à verifier)

- Benjamin fournit des infos sur les machines, les configurations, le file system, ... en priorité pour les systèmes utilisés dans les ateliers.

Lars de retour de vacances le 13 mais vraiment dispo à partir du 19 octobre.

- proposition de dates
- 19.10 après midi
- 30.10 après midi
Finalement date retenue 5 novembre.

:::success
Vu
- [x] Guylène
- [X] Céline
- [x] Jérémie
- [x] Benjamin
- [x] Michael
:::

---

# Atelier Exist db - English version - 24/09/20

[TOC]

:::info
**Video**
:movie_camera: https://minio.stable.innovation.insee.eu/fhddha/ExistDB/2020-09-25-AtelierExistDB.mp4 (accessible inside INSEE only)
:::

## Presentation of Monex
- Review of the different functionalities
- Access JMX info on the existing EXIST_URL / exist / status database useful if Monex no longer responds, requires a token or an admin account.

Monex can be used for multiple databases but it is not recommended as the sole monitoring tool. Mostly useful for development work.

### Data brokers
Allows to define the number of simultaneous users in the same ms.
20 brokers is a good default.
In the event of a problem, increasing the number of data brokers is not necessarily the solution: the problem more often comes from slow requests because a lot of slow requests = a lot of busy brokers.

### Cache manager

Good to know: in existDB, XMLs are managed like documents.

Indexes are built from the parsing of documents.

Exist does not know the data structure.

In Exist, you have to train the database to work on our data => this is the role of indexes.

### Recent queries

Used to trace requests beyond a certain threshold (100ms by default).

### Waiting threads

Normal to have waiting threads for long requests.
On instances with 20 to 50 users, it is normal to have waiting threads.
Checkbox : "track request URI".

### Profiling

Useful but slows down the system, to be used only in the development phase. By activating tracing, allows you to see the execution times (at request / function level) as well as the use of indexes.

### Indexes

"Browses indexes" : allows you to see the configuration of the indexes.

In the table, frequency = total number of documents // documents = total number of documents with selected indexed.

### Remote console

Allows access to logs that would only be accessible with SSH.
You can also write in the log.
You have to keep the browser with Monex open otherwise you lose the displays.

example :

let $test :=file:read(system:get-exist-home() || "/webapps/WEB-INF/log/sheduler.log")
return (console:log($test),$test)

Requires an admin account (or dba?).

:question: @ExistSolutions : you advise us to have admin accounts on the development and staging bases?

## Slow queries

### Use Case : searching for a Contact

- Few observations :
- "matches" expression is expensive.
- "eval " is evil !
- there are few expressions with are not compatible with an index like "contains"

:question:
@ExistSolutions : can we have the list of expressions that do not use indexes ?
@ExistSolutions : you said "Cache makes my appli slow" => do we need to work on this topic in our case ?

- Use of logging in the Xquery code can slow down requests even if this is not the essential point linked to the slowness. We could see how to manage it properly (to be able to easily switch the log level?)

- New in ExistDB 5: using facets (?) Would speed up the search. Requires configuration + rewrite the way you search

#### Problem on collections of more than 100,000 files

- The problem appears to be known for requests on large collections of more than 100,000 files.
- Not sure if this is fixed in the latest versions. Lars will see. On our side, we could test on a nightly build (even locally).
- [see](https://github.com/eXist-db/exist/issues/3466)

If nobody has developed a patch or asked Exist Solutions to fix the problem (a few days of development?), there might be workarounds.

Examples :

1. Create a single Contact file (large file!)
2. separate the contacts from the authorizations (habilitations in french) because authorizations represent the majority of the largest contact files)
3. organize the contacts with sub-directories made of the first two letters of the names

- Given a Contact.xqm + fake data => Lars can suggest us an optimization.

:::danger
Lars offers to discuss about this bug internally (1 hour) and come back to us to offer us different options.
:::

:question: @Exist-Solutions If it is confirmed that there is indeed a bug on large collections and that this concerns some processing operations in production for Coltrane, could we use the support market between Exist Solutions and INSEE so that Exist Solutions develops the necessary "fix"?

Presentation of the Exist DB github website : https://github.com/eXist-db/exist

Issues => https://github.com/eXist-db/exist/issues

## Indexes

- Slow in indexing processes could also be linked to a large number of files in the same collection.

- Time to reduild the indexes : 24 hours to rebuild the index of an Exist DB seems far too long. Another session would be necessary to investigate and understand why it is so slow. Normally it should last a few minutes.

- Insee has to provide the (empty) folder structure of the collections with the number of files inside each folder so that eXist Solutions can get an idea of ​​the organization of the database and the number of files per collection.

## Best practices for copying production data

eXistdb backup not recommended with large databases: not fast enough, blocks users.

Snapshot-based solutions should be prefered.

If we can stop the database, we can use RSYNC to synchronize the filesystem of the eXist database. All eXist data is synchronized when the database is shut down, you just have to synchronize the files afterwards.

Import and export allow to copy data in all versions from 1 to 5. It's slow but it works. Otherwise, it is perilous to recover eXist binary files which are not compatible from one version (even minor in some cases) to another.

The question of the credentials arises when copying the database so as not to have the same credentials between QF3 and production ... Lars could suggest us an operating mode to manage this.

## Next workshop

- System structure, organization of collections, study of "system" files: dom.dbx, other dbx, ...)
- SSH access required !

- Solutions for the problem of the large collections and questions concerning backups.

- Attempts to explain the reindexing too slow > 20 hours
- Insee can supply of the script used by ops to backup and restore the database.
(Possible saturation of the ram while indexes are built ? , with use of swap ? to check)

- Benjamin provides information on the machines, the configurations, the file system, ... primarily for the systems used in the workshops.

Lars back from vacation on the 13th but really available from October 19th.

- Next workshop date 5th november afternoon