Picturepark Upgrade To Version 8.6 With NoSQL Search Support
One of our featured DAM vendors, Picturepark, have released version 8.6 of their DAM system. The key upgrade is the use of NoSQL to augment their indexing and searching features. They have also included these enhancements:
- Video cue points and bookmarks to allow users to access specific sections of a clip
- Asset sharing modified to dynamically link to assets (so they are live rather than static pre-defined lists)
- Drag and drop rights management controls and integration with search features to enable filtering by permissions
- Active Directory Federation Services (ADFS) support
- Automated metadata import from external applications
The NoSQL support allows Picturepark to make use of a non-relational database search facility in addition to SQL Server (which is their database of choice). They have a quote from Director of R&D, Thomas Wackersreuther:
“DAM software that relies on only one of these technologies limits itself. There is no better enterprise database than SQL Server and there is currently no faster option for DAM search than NoSQL. It is too difficult to choose the better of these two technologies because each offers compelling strengths, so we chose both.”
For less technically-minded readers, if you want to store metadata about assets, there are two major techniques. The first is to use a relational database where everything is stored in related tables that use index numbers to relate one item of data to another. In Picturepark’s case, this is SQL Server. The second technique is to employ a large-scale search which mass indexes everything and is optimised to create ad-hoc links between data – this is where NoSQL comes in. NoSQL is a pejorative term used by the inventors of this technology to distinguish their approach from older relational techniques. Despite being ideologically opposed (in a technical sense) the two are not necessarily mutually exclusive and can be combined to improve search performance and deliver more relevant results.
As indicated by Thomas, the relational method is fast at handling well-defined linear metadata (e.g. categories of assets) but text indexes can become unwieldy and slow at higher volumes. The large-scale index offered by NoSQL will assemble ad-hoc indexes where no pre-existing relationship was defined, but the trade off is reduced performance with simpler and more linear collections of data. The reason more DAM vendors now must consider multiple search and indexing methods which can integrate results from both sources is that DAM repositories are growing exponentially to reflect the increasing numbers of digital assets they now hold but they also need to still be able to work with highly specific sets of assets for a given task.
A few more recent DAM systems completely eschew the relational method and just use pure indexing. They work well enough when the users operate the DAM system like a giant search engine, but where users have highly specific queries, or they want to run some batch operation (e.g. “render the front page of every PDF sales proposal from region x in quarter 2 of 2010 as a JPEG file and export it here”) then the performance can decline. As Thomas implies, if you want to scale, you need access to both techniques (and a system that can leverage either method in a context-sensitive fashion).
It should be pointed out that SQL Server and NoSQL are not the only technologies that fulfil both these roles and while I don’t doubt the technical sophistication required to get this to work reliably by the Picturepark developers, it is the case that other DAM vendors are also pursuing a similar technical strategy. As well as SQL Server, there will be other relational databases which you have probably heard of, like Oracle or MySQL. Apache Solr (part of the Lucene project) is a further alternative – and is arguably more popular for Content Management oriented solutions such as DAM (whether or not it is better is a different question, however). There are a number of choices for vendors who plan to use this dual method and various integration techniques to combine results.
No doubt some of our more implementation-focussed readers will be able to pick a variety of holes and generalisations in the explanations I have given above. However, if you are contemplating acquiring a DAM system (or evaluating if your current one is up to the job), the key point to understand is that if your Digital Asset Management requirements are likely to grow significantly and you will also need to carry out searches for and tasks relating to a small and highly defined group of assets, you will need a DAM that is able to use multiple search technologies and aggregate them together into a single set of results or switch according to context.
If you are starting DAM from scratch or maybe just not migrating lots of assets initially, you may not necessarily find out that your DAM of choice doesn’t scale searching and indexing very well until there are lots of assets stored in it and the system performance has fallen off the proverbial cliff. For that reason, it is worthwhile getting acquainted (at a basic level) with how the vendor has tackled this issue and what their long-term plans are to deal with it. A glib one sentence answer isn’t really enough, they should have more detailed product road-maps and indications of how they will scale up in a graceful and non-disruptive manner. Effective search and index is probably the number one function of DAM systems above all others and therefore, it must be the feature that vendors need to ensure is always fully operational and relevant to user’s requirements.
Share this Article: