Proper Partitioning for a table

Question

Dear Netters,
We have a table that is defined as follows:
CREATE TABLE RECORDSINGLECHOICEVALUE
  RECORDFK        RAW(16)                        NOT   NULL,
  CHOICEFK        RAW(16)                         NOT   NULL,
  FIELDFK         RAW(16)                           NOT  NULL,
  SOURCEENTITYFK  RAW(16)                   NOT   NULL
CONSTRAINT RDSINGLECHOICEVAL_PK PRIMARY KEY (RECORDFK, FIELDFK)In it, we store GUIDs that reference other tables in the application.
There are generally the following types of queries that use the table:
SELECT COUNT(DISTINCT t1.SourceEntityFk)
FROM RECORDSINGLECHOICEVALUE t1
    INNER JOIN RECORDSINGLECHOICEVALUE t2 ON (
           t1.SourceEntityFk = t2.SourceEntityFk                    ---- they belong to the same Entity
           t1.RecordFk = t2.RecordFk                                    ---- .... AND to the same Record
           AND t2.FieldFk = {some other guid value}
WHERE t1.FieldFk = {some guid value}                  -- always a single
   AND t1.ChoiceFk in {some list of guid values}      -- this part is optionalor
SELECT COUNT(DISTINCT t1.SourceEntityFk)
FROM RECORDSINGLECHOICEVALUE t1
    INNER JOIN RECORDSINGLECHOICEVALUE t2 ON (
           t1.SourceEntityFk = t2.SourceEntityFk                    ---- they belong to the same Entity
           AND t2.FieldFk = {some other guid value}
WHERE t1.FieldFk = {some guid value}                  -- always a single
   AND t1.ChoiceFk in {some list of guid values}      -- this part is optionalThe table could be joined to itself multiple times.
For partitioning, we used HASH partition on FieldFk (128 partitions were created), since this is a scalar that participates in 99% of the queries against the table. However, due to the nature of the data, some of the partitions are heavily skewed (one field is more prevalent than others), resulting in some partitions having < 10k rows, and others having > 200M rows.
Would you recommend an alternative partitioning schema? Sub-partitions?
Thank you in advance.
--Alex                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Answer 1

>
The table in question (and we have a few other ones very similarly defined), participates in many queries against the database. Queries can be formed in such a way that the user can pick the Field (FieldFk) and (optionally) ChoiceFks at will. This is a highly flexible user-driven query engine. Table(s) can be joined many times within the same query, resulting in sub-optimal performance.
The goal is to come up with the schema (partitioning/indexing/any other) that will support positive user experience. The 200M rows in a single partition was an example of when things start breaking lose. In the near future, this number can grow at least 10x.
To clear up a business case, imagine human subjects, which have genetic variants. Say, there are 100 million people in the database (EntityFk). They all have 23 chromosomes, about 20,000 protein producing genes of interest (460000 combinations), and these have genetic variations (say, 10000) of different types (types are defined as ChoiceFk).
The query would then try to identify subjects that have a specific type of gene variation (Field = "Gene variation", Choice = "Fusion"), and are males (Field = "Gender", Choice = "Male"), and have been diagnosed with a specific disorder (Field = "Diagnosis", Choice = "Specific Disorder"), and that have a recording of treatment (Field = "Treatment", choice is NOT specified) in the database. So, the table is getting joined onto itself in a few different ways, any many times (sometimes as many as 10).
With stats in place, with index covering on Entity + Field + Choice (in all possible combinations thereof), with hash partitioning on Field alone (keys are GUIDs, so range partitioning, while possible, is kind of counter-intuitive), performance is suffering with increasing volume.
We are evaluating other options, for different partition keys, indexing, and anything else in between.
Any suggestions are much appreciated.
>
Thanks for the additional information. From what you describe it sounds like a classic use case for more of a star-schema architecture or am I still missing something?
To see what I am talking about take a look at my extensive reply in this thread from a year ago
Re: How to design a fact table to keep track of active dimensions?
Re: How to design a fact table to keep track of active dimensions?
Posted: Mar 18, 2012 7:13 PM
I provided example code that should give you the idea of what I mean.
For use cases like this bitmap indexes are VERY efficient. And since you said this:
>
The problem is performance. Maintenance side of the house is minimal - data is loaded from an external source, once every X days, via ETL, and so that is not a concern.
>
you should only have to rebuild/update the bitmap indexes every X days also. The main drawback of bitmap indexes is the performance when they are updated. They are NOT appropriate for OLTP systems but for OLAP where the index updates can be done offline in batch mode (or rebuilt) that is an ideal use case.
You can easily conduct some tests using the example code I provide in that thread link as a template.
In my example the attributes I used were: age, beer, marital_status, softdrink, state, summer_sport.
You would use attributes like: Gene variation, Gender, Diagnosis, Treatment.
Bitmap indexes store a bit for NULL values also so you could use NULL to indicate NO TREATMENT.
Your goal would be to construct a query that uses a logical combination of your attributes to specify what you are interested in. Then, as you can see by the plans I posted, Oracle will take it from there and perform bitmap index operations using ONLY the indexes. This is one sample query I provided:
SQL> select rowid from star_fact where
  2   (state = 'CA') or (state = 'CO')
  3  and (age = 'young') and (marital_status = 'divorced')
  4  and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
  5  or ((summer_sport = 'golf') and (beer = 'coors')));Your query would use your attribute names and values. Notice also that there are no multiple joins to the same table, although there can be if necessary without preventing Oracle from using the bitmap indexes efficiently.