Difference between revisions of "Table Segmentation in Content Manager OnDemand"

In order to keep database queries fast, OnDemand uses a concept called "database table segmentation".    The term 'table segmentation' refers to splitting extremely large tables into 'segments' of smaller tables for performance and/or ease of maintenance.  Although the latest versions of database engines can do this natively, at the time Content Manager OnDemand was created, there was no built-in support for this functionality, so it still uses the old style segmentation to achieve the scalability and speed that customers require.

When an end user performs a search, IBM CMOD performs the search on one or more tables, based on the date range contained in individual tables.  This 'date range' is called the 'segment date'.

Let's say you're a large IBM Content Manager OnDemand user.  You have 40 million customers, and about 25 million receive an invoice every month.  When you load those invoices into IBM CMOD with a default 'Max Rows' value of 10 million, you probably create two or three tables a month.  But you've been in business for 5 years already.  It's not unreasonable that you might have more than 100 tables full of customer invoice data.  If an employee searches for a customer's invoices over a range of the last 12 months by default, the database must search between 24 and 36 individual tables to satisfy a single request.  Somewhere between 16 and 24 tables that are searched won't find anything at all! When you multiply the work required to satisfy ONE request across an entire company, the default 'Max Rows' parameter can cause an OnDemand server to quickly become overloaded.