TECHNICAL STUFF
Under the hood of
Ne<t® Large Volume Partitioning
Learn why LVP (Large Volume Partitioning) makes a huge difference for some companies. And why it is not for everyone.
The IFS option
Next® for IBM i has always exploited the IBM i strengths to its maximum. All the transaction data is managed in DB2 (the build-in database) and all documents are kept in IFS (Integrated File System).
The IFS itself is very flexible and allows us to build folder structures for the physical documents that suites anyone's need for structure with regards to security and backup. With extra modules we are even able to place selected groups of documents on SAN, tape robots, optical libraries, and PC or Linux servers.
Flexibility at a price
Each IFS file (for example a scanned contract) has a lot of technical oriented metadata describing the physical file. Relevant to the file system, but less relevant to the business user. It still takes up space, and takes time to manage.
Also on each file or document you have authorities (read, write, update, delete). For some customers this system-level authority is very relevant. For others it’s just wasted resources, and may even result in a risk of losing documents if not managed correctly.
Because each document is managed on its own, may be placed anywhere, and has its own system security defined, backing up and restoring IFS takes a long time. If the IFS is big, it may be unacceptably long time.
Add to this that many HA (high availability) or mirroring solutions are less than efficient in handling IFS documents. Especially in huge volumes.
The LVP alternative
LVP is based on features in the DB2 database from IBM. No file system is involved, for the documents you choose to put into LVP. You automatically get the scalability, reliability and speed of DB2. Also for save/restore. And almost all mirror/replication solutions handle DB2 transactions faster and more reliable than IFS files.
As the illustration show you may still partition your document data into logical “chunks” – per day, per week, per month, or per year in order to make backup even faster and more efficient. But simply getting individual documents out of the file system and into a database container does wonders when it comes to speed.
What's the catch?
What is then the draw back? Less flexibility. Nothing more, nothing less.
LVP data resides in DB2 for IBM i – nowhere else. The documents you designate to LVP will be stored in DB2, and if you want them on a SAN, then you will have to configure your IBM server to do so. Also, the documents you designate to LVP are stored inside DB2, and hence you cannot manage them as individual files any more. Most users will see this as a advantage, but you still need to be aware of the fact.
Implementation as easy as 1-2-3
Implementing LVP is as simple as 1-2-3. Once LVP is installed all you need to do is to configure each item type you want to go into LVP. Simply change its "Storage type" from "external" to "internal". As simple as that. Every new document will now go into LVP instead of IFS. No changes to the end-user, and no changes to any of your system integrations.
Next® automatically handles that the new documents are in LVP and the old ones in IFS.
In order to take immidiate advatage of the faster backup you need to migrate all you old documents from IFS to LVP.
Migrate Item Content does exactly this, and in a totally unintrusive way. You will allow the migration process to run as a background process for days or weeks in order not to interfere with our every day operations. Slowly but surely all documents end up in LVP, without an single end-user noticing anything.
Customers deploying Next® Large Volume Partitioning have reported amazing results. The figures to the right are from DT group, one of the bigger Next® sites with more than 60 million documents in their archives. Read more about the DT findings.
It doesn't take an archive with millions of documents to benefit from LVP, but you should be able to answer yes to at least one of the following:
- Running Next® for IBM i (1)
- Many documents in IFS
- Limited backup window
- High Availability / replication solution in place
- Need for safer handling of documents
At the same time you must be willing to give-up on some of the former flexibility
- No more storing on SAN, NAS or Optical storage, unless you configure your IBM i server for that
- No more manual handling of archived documents
(1) Large Volume Partitioning only applies to Next® for IBM i where we are able to utilize build-in features like DB2 and IFS. In Next® (not for IBM i) we have solved the issue of large volumes with our Haystack based storage engine. Learn more about our Haystack storage engine.
