EMC World 2008: Documentum Performance, Scalability, and Sizing – Part 2

Way too busy. Not enough time. Too much to learn. More thoughts on that later. For now, back to Ed Bueche to finish yesterday’s topic. I had to miss his Birds of a Feather session, so this is even more important.

  • More on Lightweight sysobjects, but much better graphics to explain the concept.
  • Default sysobject covers 6 tables before hitting any custom type tables.
  • Lightweight sysobjects lose 3 of the tables, including both dm_sysobject tables, and any custom parent object types
  • Seeing 25-50% size improvement on the database. It depends on the application design. (Use these numbers over others I may have elsewhere)
  • Shared features characteristics include
    • Security
    • Retention
    • Folder Linking
    • Lifecycle
  • Lightweight sysobjects cannot be versioned or replicated
  • Will need to change folder structures in model as they all share (Keep low in the hierarchy to prevent accidental browsing)
  • Can re-parent a lightweight object to change to a parent with different shared characteristics.
  • Providing a migration script call MIGRATE_TO_LITE
    • Options to perform bulk of migration offline (via the oracle redefinition package) to minimize the application impact
    • Can selectively pull from object attributes to light object
    • Object id’s are reused
    • Initial tests show 1 million to 10 minutes
    • Will be more painful in SQL Server as it has less of the cool packages for redefining data models
    • Provide utility to remove orphaned parents once they have been move to Lightweight (slower than the migration)
  • Adding range partitioning to database tables in D6.5
    • Can group objects by date as older tables are typically accessed less often
    • Partition Id will control what partition the data sits
    • When mixed with tablespace management, is basically Content Storage Services for the metadata
    • Parent objects and child objects, from lightweight model, don’t have to be in the same partition
  • Adding high-speed insert (Use for migration or super high-volume processes…)
    • Ingest into off-line partition with no index
    • Once complete, index is applied and partition is placed online via a partition swap
    • Requires a content server bounce
    • Doesn’t work with business objects applied
    • went from 324K/hour to 20mil/hour
    • This is a database feature revealed through Documentum
    • Not good for 24 hour processes or quick availability
    • Meant for massive amounts in short time periods
    • Not into Centera
    • Should only use Lightweight objects
    • FileNet migrations as an example
  • D7 things coming forward
    • Content transfer improvements: parallel uploads of large files
    • Scaling the XML Store up higher
    • Lucene indexing (More offline questions for that)

Off to learn more about Magellen. Everything that I hear is very good so far.

Disclaimer

All information in this post was gathered from the presenters and presentation. It does not reflect my opinion unless clearly indicated (Italics in parenthesis). Any errors are most likely from my misunderstanding a statement or imperfectly recording the information. Updates to correct information are reflected in red, but will not be otherwise indicated.

All statements about the future of EMC products and strategy are subject to change due to a large variety of factors.

2 thoughts on “EMC World 2008: Documentum Performance, Scalability, and Sizing – Part 2”

  1. Security isn’t a feature! Security has another dimension such as whether they are embracing secure coding practices to ensure that basic OWASP attacks do not occur in the ECM product.

    Like

  2. “Feature” was a poor choice of words on my part. “Characteristic”, now used above, is more accurate. The point was that the Security of the Parent object and the Child objects will all be the same.

    If you are referring to another note, let me know.

    -Pie

    Like

Comments are closed.