Я работаю с базой данных SQL Server 2008, которая имеет сходные характеристики; тяжело на вставку и выделение, свет на обновление / удаление. Около 100 000 «узлов» всех выборок, по крайней мере, один раз в час. И есть поворот; все входящие данные для каждого «узла» должны быть сопоставлены с историей и использованы для проверки, прогнозирования и т. д. О, есть еще один поворот; данные должны быть представлены четырьмя различными способами, поэтому, по сути, существует 4 различных копии этих данных, ни одна из которых не может быть получена из каких-либо других данных с разумной точностью и в разумные сроки. 23 мегабайта были бы легкой прогулкой; мы говорим здесь сотни гигабайт с терабайтами.
Вы узнаете много нового о масштабах процесса, о том, какие методы работают, а какие нет, но современные базы данных SQL, безусловно, соответствуют этой задаче. Эта система, которую я только что описал? Он работает на 5-летнем IBM xSeries с 2 ГБ ОЗУ и массивом RAID 5 и работает превосходно: никто не должен ждать больше нескольких секунд даже для самых сложных запросов.
Вам нужно оптимизировать, конечно. Вам придется часто денормализовать и поддерживать предварительно вычисленные агрегаты (или хранилище данных), если это является частью ваших требований к отчетности. Возможно, вам придется немного поразмыслить: например, мы используем ряд пользовательских типов CLR для хранения необработанных данных и агрегаты / функции CLR для некоторых из более необычных отчетов о транзакциях. SQL Server и другие механизмы БД могут не предлагать всего , необходимого вам заранее, но вы можете обойти их ограничения.
Вы также захотите кешировать - сильно. Поддерживать ежечасные, ежедневные, еженедельные сводки. Инвестируйте в интерфейсный сервер с достаточным объемом памяти и кэшируйте как можно больше отчетов. Это в дополнение к любому решению хранилища данных, которое вы придумали, если применимо.
Одна из вещей, от которой вы, вероятно, захотите избавиться, - это ключ "Id" в вашей гипотетической таблице Data. Я предполагаю, что Data является листовой таблицей - обычно это происходит в этих сценариях - и это делает его одной из немногих ситуаций, где я рекомендую использовать естественный ключ вместо суррогата. Тот же variable, вероятно, не может генерировать повторяющиеся строки для одной и той же временной метки, поэтому все, что вам действительно нужно, это переменная и временная метка в качестве первичного ключа. По мере того, как таблица становится все больше и больше, наличие отдельного индекса для variable и timestamp (что, конечно, необходимо охватить) приведет к потере огромного количества места - 20, 50, 100 ГБ, легко. И, конечно же, теперь каждый INSERT должен обновить два или более индексов.
Я действительно считаю, что СУБД (или база данных SQL, если вы предпочитаете) способна к этой задаче так же, как и любая другая, если вы проявляете достаточную осторожность и планирование в своем проекте. Если вы просто начнете объединять таблицы без учета производительности или масштаба, то, конечно, у вас возникнут проблемы позже, и когда база данных будет иметь несколько сотен ГБ, вам будет трудно выкопать себя из этой дыры.
Но возможно ли это? Абсолютно. Постоянно следите за производительностью, и со временем вы узнаете, какие оптимизации вам нужно сделать.