Making Relativity relatively faster... Partition it baby, (sometimes)

Thursday, February 27, 2014

Making Relativity relatively faster... Partition it baby, (sometimes)

Brent Ozar - How to Use Partitioning to Make kCura Relativity Faster

kCura Relativity is an e-discovery program used by law firms to find evidence quickly. I’ve blogged about performance tuning Relativity, and today I’m going to go a little deeper to explain why DBAs have to be aware of Relativity database contents.

In Relativity, every workspace (case) lives in its own SQL Server database. That one database houses:

Document metadata – where the document was found, what type of document it is

Extracted text from each document – the content of emails, spreadsheets, files

Document tagging and highlighting – things the lawyers discovered about the documents and noted for later review

Workspace configuration – permissions data about who’s allowed to see what documents

Auditing trails – who’s searched for what terms, what documents they’ve looked at, and what changes they made

For performance tuners like me, that last one is kinda interesting. I totally understand that we have to capture every activity in Relativity and log it to a table, but log-sourced data has different performance and recoverability requirements than other e-discovery data.

...

However, I don’t recommend doing this by default across all your databases. This technique is going to instantly double the number of databases you have and make your management much more complex. However, I do recommend reviewing your largest workspaces to see if AuditRecord is consuming half or more of the database space. If so, consider partitioning their AuditRecord tables to get faster backups, database maintenance jobs, and restores.

At the risk of sounding like a fanboy, this is one of the reasons I love working with the kCura folks. They really care about database performance, they take suggestions like this, and they implement it in a way that makes a real difference for customers.

This is also why database administrators need to:

Understand the real business purpose of the biggest tables in their databases

Build working, productive relationships with their software vendors

Come up with creative approaches to ease SQL Server pains

Help the vendors implement these approaches in software

..."