DICOM store files in the database

[Marcelo Ribeiro]

Hello,

Using the two plugins PostgreSQL, DICOM files are stored in the database, but it is recommended?

If I want to store in the database only the pointers to the files and keep files ".dcm" in the file system, it is possible?

What is safe?

Thank you!
Marcelo

[Sébastien Jodogne]

Hello,

Using the two plugins PostgreSQL, DICOM files are stored in the database, but it is recommended?

This really depends upon your use case.

Using the PostgreSQL storage has the advantage of storing all the information at the same place, and of benefiting from all the advantages of an enterprise database (security, backup, clustering, scalability, redundancy...).

Using a filesystem storage has the advantage of the lightness, and of putting less load on the database server.

 

If I want to store in the database only the pointers to the files and keep files ".dcm" in the file system, it is possible?

Yes, of course, you just have to set the configuration option "EnableStorage" to "false" in the "PostgreSQL" section of your configuration file. In this case, the DICOM files will be stored in the folder referred to by the "OrthancStorage" configuration option, as in the core version of Orthanc.

This is explained on the following Web page:

http://www.orthanc-server.com/static.php?page=postgresql

 

What is safe?

If your "OrthancStorage" folder is properly backup, the two options should be safe.

HTH,

Sébastien-

[ss...@zoomcare.com]

Hello,

Can I confirm?

With the configuration mentioned set, the functionality of the web viewer and any retrieve will remain the same?

That is to say, Orthanc will not have trouble locating the dicom image on the file system associated with the metadata in the database?

Additionally, the dicom stored to file system is not in any propriety format, but is dicom format just as it was received? 

Thanks!

Srey Seng

[Sébastien Jodogne]

Hello,

With the configuration mentioned set, the functionality of the web viewer and any retrieve will remain the same?

Yes. The layered architecture of Orthanc allows to swap the index back-end and/or the file storage back-end the without altering any higher-level functionality (including the Web viewer).

 

That is to say, Orthanc will not have trouble locating the dicom image on the file system associated with the metadata in the database?

Yes, Orthanc will have no trouble.

 

Additionally, the dicom stored to file system is not in any propriety format, but is dicom format just as it was received? 

Yes, there is nothing proprietary in Orthanc. This is actually guaranteed by our free and open-source development methodology. Any DICOM file Orthanc receives is stored as such on the filesystem.

The only exception is when the "StorageCompression" configuration option is set to "true" in the configuration file, which makes Orthanc transparently compress the DICOM files using zlib before writing them to the disk. Even in this case, the command-line tool "OrthancRecoverCompressedFile" (that is part of the official distribution) will allow you to manually uncompress the file.

HTH,

Sébastien-

[ss...@zoomcare.com]

Thanks for expanding!

In short, my take away at this time is that I should safely be able to use PostgreSQL for indexing, and file system for storage of the dicom.

Another question:
Can the index and the storage go out of sync, that is to say, successful write/delete to one, and fail in the other? Can this lead to corruption?

Is there some mechanism to ensure consistency?

Thanks!

[Sébastien Jodogne]

In short, my take away at this time is that I should safely be able to use PostgreSQL for indexing, and file system for storage of the dicom.

Yes, that's it.

 

Another question:
Can the index and the storage go out of sync, that is to say, successful write/delete to one, and fail in the other? Can this lead to corruption?

Is there some mechanism to ensure consistency?

Whenever Orthanc receives a DICOM instance (may it come from the DICOM protocol or from the REST API), the "ServerContext::Store()" function is invoked. You can review its behavior at the following location:
https://goo.gl/9pfVct

In a nutshell, the function:

1. Writes the DICOM file on the disk.
2. Writes the JSON summary on the disk.
3. Updates the database, inside a database transaction.

As a consequence, if Orthanc cannot write one of the two files to the disk, no modification is done to the DB, which ensures consistency. The use of a database transaction makes the database engine take care of possible corruption.