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

Added explanation for how tweaking segment size works.
m (Added more detail about native database support for segmentation.)
(Added explanation for how tweaking segment size works.)
Line 20: Line 20:


[[File:TableSegmentOptimization.png|720px]]
[[File:TableSegmentOptimization.png|720px]]
=== How does optimizing segment size work? ===
Let's say you're a large Content Manager OnDemand customer.  You have 40 million customers, and about 25 million receive an invoice every month.  When you load those invoices into 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.  Most of the tables that the databases searches won't find anything.  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.
In the same situation, when Content Manager OnDemand is configured with an optimized segment size, one search hits 12 tables, and each table returns a result -- a much better work-to-result ratio, which requires less disk-related I/O and less CPU time.  It's better in almost every way.