Revision as of 23:02, 31 March 2009

Chapitre 5. Problèmes liés au déploiement

(Deployment Issues)

Fred Toussi

HSQLDB Development Group

<ft@cluedup.com>

Copyright 2005 Fred Toussi. Permission is granted to distribute this document without any alteration under the terms of the HSQLDB license. Additional permission is granted to the HSQLDB Development Group to distribute this document with or without alterations under the terms of the HSQLDB license.

$Date: 2005/07/02 09:11:39 $

But de ce document

Beaucoup de questions fréquemment posées dans les forums et mailing-lists trouvent leurs réponses dans ce guide. Si vous voulez utiliser HSQLDB avec votre application, vous devez lire ce guide. Ce document couvre les problèmes relatifs au système. Pour les problèmes relatifs au SQL voyez le chapitre : Problèmes liés au SQL.

Mode opératoire et tables

(Mode of Operation and Tables)

HSQLDB possède des modes opératoires et des fonctionnalités qui lui permette d'être utilisé dans des scénarios très différents. Les niveaux de l'utilisation de la mémoire, la vitesse et l'accessibilité sont influencés par la manière dont HSQLDB est déployé.

Mode opératoire

(Mode of Operation)

La décision d'exécuter HSQLDB comme un processus de serveur à part ou comme une base de données "in-process" doit être basée sur les faits suivants

• Quand HSQLDB est exécuté comme un serveur sur une machine séparée, il est isolé des pannes matérielles et plantages de l'hôte qui exécute l'application.
• Quand HSQLDB est exécuté comme un serveur sur la même machine, il est isolé des plantages de l'application et des fuites (leaks) de mémoire.
• Les connexions au serveur sont plus lentes que les connexions "in-process" à cause de la surcharge du flux de données pour chaque appel JDBC.

Tables

Les tables texte sont désignées pour des applications spéciales où les données doivent être dans un format interchangeable, tel le format CSV. Les tables texte ne devraient pas être utilisées pour un stockage routinier des données.

Les tables mémoire et en cache sont généralement utilisées pour le stockage des données. Les différences entre ces deux types sont énumérées ci-dessous :

• Pour les tables mémoire, les données sont lues depuis le fichier .script quand la base de données est démarrée et chargée en mémoire. Au contraire des tables en cache pour lesquelles les données ne sont chargées en mémoire qu'après un accès à la table. De plus pour les tables en cache seulement une partie des données est chargée en mémoire, ce qui permet aux tables de dépasser la mémoire totale allouée.
• Quand la base de données est normalement fermée, toutes les données des tables mémoire sont écrites sur disque. Par comparaison, seules les données modifiées seront écrites dans les tables en cache à la fermeture, plus une sauvegarde compressée de l'intégralité des données pour toutes les tables en cache.
• La taille et la capacité du cache des données est configurable pour toutes les tables en cache. Ceci permet d'allouer au cache mémoire toutes les données des tables en cache. Dans ce cas, la vitesse d'accès est bonne, bien que légèrement plus lente qu'avec les tables mémoire.
• Pour la plupart des applications il est recommandé d'utiliser les tables mémoire pour les petites quantités de données, en réservant les tables en cache pour les grands jeux de données. Pour certaines applications spéciales dans laquelle la vitesse joue un rôle de première importance et si une grande quantité de mémoire libre est disponible, on peut utiliser aussi bien les tables mémoire pour de grandes tables.

Les grands objets

(Large Objects)

• Voir aussi CLOB (en)
• Voir aussi BLOB (en)

Les "types" CLOB (fr) JDBC sont pris en charge par les colonnes de type LONGVARCHAR. Les "types" BLOB (fr) JDBC sont eux supportés par les colonnes de type LONGVARBINARY. Si de grands objets (LONGVARCHAR, LONGVARBINARY, OBJECT) sont stockées dans des définitions d'une table qui contient plusieurs autres champs normaux, il serait en fait préférable de scinder cette table en deux. La première table contenant les champs normaux et la seconde contenant les grands objets plus un champ clé primaire. Utiliser cette méthode a deux avantages. (a) La première table peut être généralement créée comme une table mémoire alors que seulement la seconde est de type CACHED. (b) Les grands objets peuvent être retrouvés individuellement par l'utilisation de leur clé primaire, plutôt que d'avoir à charger les données en mémoire pour trouver les lignes durant l'exécution de la requête. Un exemple de deux tables et une requête sélection qui exploite la séparation entre les deux :

CREATE MEMORY TABLE MAINTABLE(MAINID INTEGER, ......);

CREATE CACHED TABLE LOBTABLE(LOBID INTEGER, LOBDATA LONGVARBINARY);

SELECT * FROM (SELECT * FROM MAINTABLE <join any other table> WHERE <various conditions apply>) JOIN LOBTABLE ON MAINID=LOBID;

La commande SELECT trouve les lignes demandées sans faire référence à LOBTABLE, et lorsque toutes les lignes sont trouvées, récupère les grands objets associés de LOBTABLE.

Contexte de déploiement

(Deployment context)

Les fichiers nécessaires pour stocker les données de bases de données HSQLDB sont tous situés dans le même répertoire. Les nouveaux fichiers sont toujours créés et supprimés par le moteur de la base de données. Deux principes simples doivent être observés :

• Le processus Java exécutant HSQLDB doit avoir les pleins privilèges sur le dossier ou les fichiers sont enregistrés. Y compris les droits de création et de suppression.
• Le système de fichiers doit avoir assez de place disponible à la fois pour les fichiers permanents et temporaires. La taille par défaut maximum du fichier .log est de 200 Mo. Le fichier .data peut quant à lui occuper jusqu'à 8 Go. Le fichier .backup peut atteindre jusqu'à 50% du fichier .data. Le fichier temporaire créé au moment d'un SHUTDOWN COMPACT peut être égal en taille au fichier .data.

Utilisation de la mémoire et du disque

(Memory and Disk Use)

La mémoire utilisée par le programme peut être vue comme deux groupes distincts : La mémoire utilisée pour les données de tables, et la mémoire utilisée pour construire les jeux de résultats et autres opérations internes. De plus, lors de l'exécution de transactions, la mémoire est utilisée pour stocker l'information nécessaire à une annulation (rollback).

Depuis la version 1.7.1, l'utilisation de la mémoire a été sensiblement amélioré comparativement aux versions précédentes. La mémoire utilisée pour une table mémoire est la somme de la mémoire utilisée par chaque ligne. Chaque ligne de table MEMORY est un objet Java comprenant 2 int ou variables de référence. Il contient un tableau d'objets pour les champs de la ligne. Chaque champ est un objet tel que Integer, Long, String, etc. De plus chaque index de la table ajoute un objet nœud à la ligne. Chaque objet nœud a 6 int ou variables de référence. Finalement, une table d'une colonne de type INTEGER aura quatre objets par ligne, pour un total de dix variables de quatre octets chacune - occupant donc couramment jusqu'à quatre-vingt octets par ligne. Bien sur, chaque colonne supplémentaire ajoute au moins quelques octets à la taille de chaque ligne.

La mémoire utilisée pour renvoyer un jeu de lignes (result set row) est moins gourmande (moins de variables et pas de nœuds d'index) mais utilise toujours beaucoup de mémoire. Toutes les lignes du jeu de résultat sont construites en mémoire, et donc de très grands jeux de résultats peuvent ne pas être possible. Dans les bases de données en mode serveur, le jeu de résultats en mémoire est envoyé par le serveur une fois que le serveur de la base de données a lui-même renvoyé le jeu de résultats. Les bases de données "in-process" libèrent la mémoire quand l'application renvoie l'objet java.sql.ResultSet. Les modes serveur requièrent de la mémoire additionnelle pour retourner les jeux de résultats, puisqu'ils convertissent l'intégralité du jeu de résultats en un tableau d'octets qui est ensuite transmit au client.

Quand des requêtes UPDATE et DELETE sont exécutées sur des tables CACHED, tout le jeu de lignes affectées, incluant celles affectées suite aux actions ON UPDATE, est retenu en mémoire pour la durée de l'opération. Ce qui signifie qu'il peut être impossible d'exécuter des suppressions ou mises à jour invoquant de très grands nombres de lignes pour les tables CACHED. De telles opérations devront être effectuées en plusieurs plus petits jeux de lignes.

Quand la prise en charge des transactions est disponible avec SET AUTOCOMMIT OFF, des listes de toutes les insertions, opérations de suppressions ou de mises à jour sont stockées en mémoire de façon a pouvoir être annulées lors de l'envoi d'une commande ROLLBACK. Des transactions englobant des centaines de modifications des données prendront beaucoup de mémoire jusqu'à ce qu'un prochain COMMIT ou ROLLBACK nettoie ces listes.

La plupart des implémentations de machines virtuelles Java allouent un maximum de mémoire (généralement 64 Mo par défaut). Cette quantité n'est généralement pas suffisante lors de l'utilisation de grandes tables mémoire, ou quand la taille moyenne des lignes des tables en cache dépasse quelques centaines d'octets. La quantité maximum de mémoire allouée peut être définie sur la ligne de commande Java utiliser pour exécuter HSQLDB. Par exemple, avec une JVM Sun version 1.3.0 le paramètre -Xmx256m augmente la quantité de mémoire allouée à 256 Mo.

La version 1.8.0 utilise un cache rapide pour des objets tels que Integer ou String qui sont stockés dans la base de données. Dans la plupart des cas, ceci réduit encore plus la quantité de mémoire non rafraichie puisque moins de copies des objets les plus fréquemment utilisés sont conservées en mémoire.(In most circumstances, this reduces the memory footprint still further as fewer copies of the most frequently-used objects are kept in memory.)

Allocation du cache mémoire

(Cache Memory Allocation)

With CACHED tables, the data is stored on disk and only up to a maximum number of rows are held in memory at any time. The default is up to 3*16384 rows. The hsqldb.cache_scale database property can be set to alter this amount. As any random subset of the rows in any of the CACHED tables can be held in the cache, the amount of memory needed by cached rows can reach the sum of the rows containing the largest field data. For example if a table with 100,000 rows contains 40,000 rows with 1,000 bytes of data in each row and 60,000 rows with 100 bytes in each, the cache can grow to contain nearly 50,000 rows, including all the 40,000 larger rows.

An additional property, hsqldb.cache_size_scale can be used in conjunction with the hsqldb.cache_scale property. This puts a limit in bytes on the total size of rows that are cached. When the default values is used for both properties, the limit on the total size of rows is approximately 50MB. (This is the size of binary images of the rows and indexes. It translates to more actual memory, typically 2-4 times, used for the cache because the data is represented by Java objects.)

If memory is limited, the hsqldb.cache_scale or hsqldb.cache_size_scale database properties can be reduced. In the example above, if the hsqldb.cache_size_scale is reduced from 10 to 8, then the total binary size limit is reduced from 50MB to 12.5 MB. This will allow the number of cached rows to reach 50,000 small rows, but only 12,500 of the larger rows. Managing Database Connections

In all running modes (server or in-process) multiple connections to the database engine are supported. In-process (standalone) mode supports connections from the client in the same Java Virtual Machine, while server modes support connections over the network from several different clients.

Connection pooling software can be used to connect to the database but it is not generally necessary. With other database engines, connection pools are used for reasons that may not apply to HSQLDB.

   *

     To allow new queries to be performed while a time-consuming query is being performed in the background. This is not possible with HSQLDB 1.8.0 as it blocks while performing the first query and deals with the next query once it has finished it. This capability is under development and will be introduced in a future version.
   *

     To limit the maximum number of simultaneous connections to the database for performance reasons. With HSQLDB this can be useful only if your application is designed in a way that opens and closes connections for each small task.
   *

     To control transactions in a multi-threaded application. This can be useful with HSQLDB as well. For example, in a web application, a transaction may involve some processing between the queries or user action across web pages. A separate connection should be used for each HTTP session so that the work can be committed when completed or rolled back otherwise. Although this usage cannot be applied to most other database engines, HSQLDB is perfectly capable of handling over 100 simultaneous HTTP sessions as individual JDBC connections.

An application that is not both multi-threaded and transactional, such as an application for recording user login and logout actions, does not need more than one connection. The connection can stay open indefinitely and reopened only when it is dropped due to network problems.

When using an in-process database with versions prior to 1.7.2 the application program had to keep at least one connection to the database open, otherwise the database would have been closed and further attempts to create connections could fail. This is not necessary since 1.7.2, which does not automatically close an in-process database that is opened by establishing a connection. An explicit SHUTDOWN command, with or without an argument, is required to close the database. In version 1.8.0 a connection property can be used to revert to the old behaviour.

When using a server database (and to some extent, an in-process database), care must be taken to avoid creating and dropping JDBC Connections too frequently. Failure to observe this will result in unsuccessful connection attempts when the application is under heavy load. Upgrading Databases

Any database not produced with the release version of HSQLDB 1.8.0 must be upgraded to this version. This includes databases created with the RC versions of 1.8.0. The instructions under the Upgrading Using the SCRIPT Command section should be followed in all cases.

Once a database is upgraded to 1.8.0, it can no longer be used with Hypersonic or previous versions of HSQLDB.

There may be some potential legacy issues in the upgrade which should be resolved by editing the .script file:

   *

     Version 1.8.0 does not accept duplicate names for indexes that were allowed before 1.7.2.
   *

     Version 1.8.0 does not accept duplicate names for table columns that were allowed before 1.7.0.
   *

     Version 1.8.0 does not create the same type of index for foreign keys as versions before 1.7.2.
   *

     Version 1.8.0 does not accept table or column names that are SQL identifiers without double quoting.

Upgrading Using the SCRIPT Command

To upgrade from 1.7.2 or 1.7.3 to 1.8.0, simply issue the SET SCRIPTFORMAT TEXT and SHUTDOWN SCRIPT commands with the old version, then open with the new version of the engine. The upgrade is then complete.

To upgrade from older version database files (1.7.1 and older) that do not contain CACHED tables, simple SHUTDOWN with the older version and open with the new version. If there is any error in the .script file, try again after editing the .script file.

To upgrade from older version database files (1.7.1 and older) that contain CACHED tables, use the SCRIPT procedure below. In all versions of HSQLDB and Hypersonic 1.43, the SCRIPT 'filename' command (used as an SQL query) allows you to save a full record of your database, including database object definitions and data, to a file of your choice. You can export a script file using the old version of the database engine and open the script as a database with 1.8.0.

Procedure 5.1. Upgrade Using SCRIPT procedure

  1.

     Open the original database in the old version of DatabaseManager
  2.

     Issue the SCRIPT command, for example SCRIPT 'newversion.script' to create a script file containing a copy of the database.
  3.

     Use the 1.8.0 version of DatabaseManager to create a new database, in this example 'newversion' in a different directory.
  4.

     SHUTDOWN this database.
  5.

     Copy the newversion.script file from step 2 over the file of the same name for the new database created in 4.
  6.

     Try to open the new database using DatabaseManager.
  7.

     If there is any inconsistency in the data, the script line number is reported on the console and the opening process is aborted. Edit and correct any problems in the newversion.script before attempting to open again. Use the guidelines in the next section (Manual Changes to the .script File). Use a programming editor that is capable of handling very large files and does not wrap long lines of text.

Manual Changes to the .script File

In 1.8.0 the full range of ALTER TABLE commands is available to change the data structures and their names. However, if an old database cannot be opened due to data inconsistencies, or the use of index or column names that are not compatible with 1.8.0, manual editing of the SCRIPT file can be performed.

The following changes can be applied so long as they do not affect the integrity of existing data.

   *

     Names of tables, columns and indexes can be changed.
   *

     CREATE UNIQUE INDEX ... to CREATE INDEX ... and vice versa

     A unique index can always be converted into a normal index. A non-unique index can only be converted into a unique index if the table data for the column(s) is unique in each row.
   *

     NOT NULL

     A not-null constraint can always be removed. It can only be added if the table data for the column has no null values.
   *

     PRIMARY KEY

     A primary key constraint can be removed or added. It cannot be removed if there is a foreign key referencing the column(s).
   *

     COLUMN TYPES

     Some changes to column types are possible. For example an INTEGER column can be changed to BIGINT, or DATE, TIME and TIMESTAMP columns can be changed to VARCHAR.

After completing the changes and saving the modified *.script file, you can open the database as normal. Backing Up Databases

The data for each database consists of up to 5 files in the same directory. The endings are *.properties, *.script, *.data, *.backup and *.log (a file with the *.lck ending is used for controlling access to the database and should not be backed up). These should be backed up together. The files can be backed up while the engine is running but care should be taken that a CHECKPOINT or SHUTDOWN operation does not take place during the backup. It is more efficient to perform the backup immediately after a CHECKPOINT. The *.data file can be excluded from the backup. In this case, when restoring, a dummy *.data file is needed which can be an empty, 0 length file. The engine will expand the *.backup file to replace this dummy file if the backup is restored. If the *.data file is not backed up, the *.properties file may have to be modified to ensure it contain modified=yes instead of modified=no prior to restoration. If a backup immediately follows a checkpoint, then the *.log file can also be excluded, reducing the significant files to *.properties, *.script and *.backup. Normal backup methods, such as archiving the files in a compressed bundle can be used.