Brent Ozar - Performance Tuning kCura Relativity
In the e-discovery business, kCura Relativity is the big gorilla, and I’ve been working with kCura and their clients since 2011. I think it’s one of the most interesting businesses I’ve ever worked with – up there with StackOverflow – and like Stack, they’re really open with their customers.
Today marks my second year being at Relativity Fest, the conference for Relativity users, and I’m presenting two sessions on performance tuning Relativity’s SQL Servers.
First, A Quick Introduction to Electronic Discovery
...
kCura Relativity is a popular hub for this whole process, and it uses Microsoft SQL Server as a database back end. I first started working with kCura when Andrew Sieja approached me in 2011, and we’ve had a great relationship ever since. I really like this industry because it’s facing and solving so many cool technical, logistical, and legal challenges.
How Relativity Uses SQL Server
How Relativity Challenges SQL Server
The Easy, Expensive Way to Tune Relativity’s SQL Server
The Hard but Cheaper Way to Performance Tune
The Bottom Line on Scaling kCura Relativity
It’s really just like performance tuning any other database: when you blow past a terabyte of data, and you’re doing a combination of OLTP and reporting-style access, you’re going to have to roll up your sleeves.
It doesn’t matter whether the app is homegrown or from an ISV – the DBA needs to:
- Know the database schema well
- Know the queries well
- Know how hardware can offset query and schema challenges
- Know when to turn SQL Server’s knobs (and when not to)
...
This is another sort of work/day job related kind of post. We're a very very very heavy user of kCura's Relativity (i.e.vendor record setting kind of heavy) so when I saw this article (and given Brent's name has come up in a few meetings, "We should get...") I had to capture this post.
One thing to note, that much of the advice works for nearly any system using SQL Server as it's data store.
0 comments:
Post a Comment