Custom Fields vs Separate Table

I have a client who wants to be able to upload Posts using information stored in a CSV file. I’ve already got this portion working.

Just recently, I changed the CSV File Uploader from pure PHP to an AJAX Uploader in an effort to eliminate server timeouts as well as provide a nice interface to keep track of each new post’s progress.

The Problem:

Each custom post contains about 130 Custom Fields total. Each one of my CSV Upload Tests contained roughly 20 new Posts. Even with async left on, it still takes a bit for each new Post to be processed.

All of the Custom Fields are broken up into 5 separate Meta Boxes. Originally, I had it set up to store each Meta Box as a JSON Encoded string, and save that as part of the post’s metadata. This brought the total number of Custom Fields from 130 to 5, and write time was increased dramatically.

The drawback to this, however, is that each individual Custom Field is no longer searchable by WordPress’ standards.

Proposed Solutions:

I can do one of a few things:

1. I can leave it as-is and take the slower write times while retaining both
   searchable and queryable Metadata, but perhaps run into issues with CSV files that contain a few hundred or – God forbid – a few thousand Posts.
2. I can store each Meta Box as a single Custom Field and modify WordPress’ search functionality to find Metadata via custom SQL, but lose the ability to retrieve Posts via meta_query.
3. I can overhaul the existing structure and write all Custom Post
   Metadata to a separate table. This means losing the built-in search functionality, as well as the ability to use meta_query.

The Question:

What would be the best approach to handling this? Theoretically, there are going to be hundreds of thousands of these Custom Posts. Giving users the ability to search for these posts both by title, taxonomy, and metadata is required.

Personally, I try to avoid writing any new tables to a WordPress Installation at all costs. But would this be considered a situation that demands it? Or would I lose too much functionality by using my own less-sophisticated queries to fix a problem that might not even necessarily BE a problem?

Most of all, is there any other way that I might be missing that can solve this issue?

UPDATE:
In an effort to clarify what the data entails without violating my NDA, each Custom Post is a Guitar.

Each Meta Box signifies a Section of a Guitar (Neck, Body, etc.), with each Custom Field being a fixed piece of information attributed to that particular section (Wood, Manufacturer, etc.).

class Guitar
{
    public $ID;
    public $Year;
    public $Make;
    public $Model;

    public $Section1;
    public $Section2;
    public $Section3;
    public $Section4;
    public $Section5;
    public $Section6;
    public $Section7;
    public $General;

    private $_data;
    private static $_dataFlags = array('Section1', 'Section2', 'Section3', 'Section4', 'Section5', 'Section6', 'Section7', 'General');
    public function __construct($args)
    {
        $this->ID = $this->_query_existing();
        foreach(self::$_dataFlags as $sec)
            $this->$sec = new $sec($args[$sec]);
    }
}
abstract class Guitar_Section
{
    public function __construct($arr=array())
    {
            if(!empty($arr))
            $this->_set_props($arr); //Set Properties
    }
    public function update_meta($id, $useprops=false)
    {
        foreach(get_object_vars($this) as $k=>$v)
        {
            $this->$k = !$useprops ? $_POST['guitar_'.$this->_get_section_name().'_'.$k] : $v;
            update_post_meta($id, '_guitar_'.$this->_get_section_name().'_'.$k, $this->$k);
        }
    }
}
class Section1 extends Guitar_Section
{
    public $Wood;
    public $Attachment;
    public $etc;

    protected function _get_section_name()
    {
        return 'Section1';
    }
}

This displays how each Class works in tandem with each other. I have it so that each Guitar Section is encapsulated by the Guitar Class, with each section extending the abstract class. Each property is a Custom Field, and is set utilizing the Methods within the Abstract Class, while the Guitar Class essentially queries WordPress and sets any available ID, Year, Make, and Model.

Most of this requires a LOT of string manipulation due to the fact that CSV files are used to set the class and its properties.