Мы должны денормализовать базу данных для улучшения производительности?

Не просто денормализуйте. Создавайте для результатов, используя полезные шаблоны проектирования. Иногда полезный шаблон проектирования для повышения производительности дает дизайн, отличный от того, который вы получаете, следуя правилам нормализации.

Я не думаю, что денормализация поможет вашей ситуации. Почти все люди, которые выступают за денормализацию, говорят, что прирост производительности не достигается при хранении новых данных. Они приходят, когда вы извлекаете данные. Вам нужно будет решить, как это применимо к вашему делу.

Я могу вам многое сказать. Если вы в конечном итоге сохраните данные через несколько параллельных процессов, ваш дизайн приведет к серьезным узким местам и вполне может работать медленнее, чем нормализованный дизайн.

Но не верьте мне на слово. Экспериментируйте. Анализируйте. Учиться. Проспер.

Вы должны спросить себя: «Почему мы нормализуем?»

Есть три основные причины:

1. Согласованность данных
2. Скорость обновления
3. Размер

Согласованность данных

Приятно иметь раскрывающиеся списки и все строки, которые означают одно и то же, с одинаковым FK, Правильно? Довольно очевидно. Это действительно важно для БД с несколькими «редакторами» данных. Но это ровно настолько, насколько хороши наши процессы. Допустим, это база данных полетов, и есть запись для национального аэропорта в Вашингтоне, округ Колумбия ... и некоторые добавляют НОВУЮ запись для национального аэропорта Рейгана в Вашингтоне, округ Колумбия ... FK будут там и будут использоваться в таблице детей, но выиграли не стоит многого ... Но это все равно хорошо ...

Скорость обновления

Что нам нужно было сделать, так это обновить строку для национального аэропорта с новым именем. Поскольку есть только одна родительская строка, это очень просто изменить. Если бы в моей полетной таблице был текст, я бы обновлял миллионы строк.

Размер

Если бы я сохранял «Национальный аэропорт Рейгана» на каждой записи, это заняло бы больше места, чем FK, скажем, 19. Раньше размер имел большое значение, но SAN делает его неактуальным.

Выводы

Итак, вы обеспокоены тем, что ваше приложение для сбора данных SOLO не может правильно хранить названия инструментов? Будет ли непротиворечивость данных проблемой?

Итак, как вы думаете, сколько раз вы будете менять название инструмента или точки данных? Я имею в виду, что растворенный O2 - это растворенный O2, а мутность - это мутность, верно? Но если вам действительно нужно было сделать массовое обновление, держу пари, у вас будет время простоя между запусками, чтобы сделать это. Так что это не проблема.

Хорошо, размер, конечно ... это много измерений; но, не делайте измерения «Растворенный кислород», DO2 в порядке ... насколько это больше, чем у некоторых FK, таких как «7»? Потратьте место, чтобы сэкономить время.

Не нормализируйте, потому что вы всегда мне сказали, что то, что делают хорошие дизайнеры баз данных. Знайте, зачем вы это делаете и почему вы выбираете то, что выбираете.

Используйте правильную СУБД и оборудование. Тестирование на другой платформе с другим оборудованием ничего не скажет о производительности.

Денормализация вряд ли повысит производительность записи, потому что по определению это означает, что вы создаете избыточные данные, и, следовательно, вы будете выполнять больше работы для каждой записи, а не меньше.

Приведенные вами цифры не являются исключительными для сценариев потоковой передачи данных и вполне достижимы при использовании подходящего оборудования, но я думаю, что nHibernate станет для вас основным ограничивающим фактором. Я думаю, что маловероятно, что nHib - разумный выбор для такого рода вещей.

Рассматривали ли вы использование некоторых технологий, которые обеспечивают специальную поддержку потоковых источников данных и CEP? Например: OSISoft PI, Microsoft StreamInsight и функция файлового потока SQL Server.

Ну, это зависит от того. Являются ли 8 значений вектора твердым и быстрым числом, которое никогда не изменится? Тогда денормализация в вашем случае может иметь смысл (но только тестирование на реальном оборудовании и базе данных, которые вы используете, покажет это). Если на следующей неделе может быть 9 измерений, не делайте этого.

Я бы сказал, что вам нужно сначала перейти на SQL сервер и оборудование, на котором вы будете работать, прежде чем пытаться решить, что делать.

После перехода запустите профилировщик. Вполне возможно, что nHibernate создает не самый лучший SQl для вашей вставки.

Тот факт, что у вас есть набор векторов, которые, вероятно, разделяются при вставке, может быть частью вашей проблемы производительности. Возможно, лучше иметь 8 отдельных переменных, чем набор, который приходится разделять.

Вы говорите о более чем 40 миллионах записей в день, это потребует серьезного оборудования и очень хорошо спроектированной базы данных. Также возможно, что реляционная база данных - не лучший выбор для этого (я не представляю, как вы хотите использовать такой объем данных). Как долго вы собираетесь хранить эти данные, размер здесь очень быстро выйдет из-под контроля.

Можно ли вместо этого выполнять массовую вставку записей в группе раз в минуту? Массовая вставка намного быстрее, чем вставка строка за строкой.

Ваш дизайн должен учитывать, как вы будете использовать данные, а также вставлять их. Как правило, то, что делается для ускорения вставки, может замедлить селекты и наоборот. Вам может понадобиться хранилище данных, которое загружается раз в день для анализа (и быстрого запроса, чтобы иметь возможность показать необработанные данные до секунды).

Да. Я бы подумал об уменьшении накладных расходов на вставки как за счет денормализации (выравнивание данных), так и за счет фрагментации данных по времени. Я бы спроектировал свою базу данных так, чтобы каждая запись хранила целую секунду данных на устройство:

public class Measurement 
{ 
    public Guid ID { get; private set; } 
    public Device Device { get; private set; }
    public Sample[] { get; private set; }

    public DateTime FirstTimestamp { get; private set; } 
    public DateTime LastTimestamp { get; private set; } 
} 

public class Sample
{ 
    public DateTime Timestamp { get; private set; } 
    public VectorValue[] Vectors { get; private set; } 
}

Существуют различные способы хранения сложных типов (таких как список списков в данном случае) в одной записи. XML-столбцы и Типы, определяемые пользователем CLR , являются двумя примерами.

Сначала перейдите к целевой базе данных; производительность на основе SqlLite может не указывать на производительность на основе MsSql

Во-вторых, измерьте, где находится узкое место производительности; Навскидку, рискну предположить, что это диск и база данных в памяти будут работать намного лучше.

Затем денормализуйте, если необходимо, с помощью процесса ETL, как предложено выше.

Обработка потока событий гласит: « если ударишься по диску, ты мертв. »; -)

Думали ли вы об использовании SqlBulkCopy? Работает очень быстро. Я использовал его в производственной среде и достиг 10.000+ вставок в одну таблицу менее чем за секунду с машиной sql server 2005. Вам просто нужно подготовить DataTable (ы) для массовой вставки в ваше приложение. Вот образец.

        public static void SQLBulkCopyInsert(DataTable dtInsertRows, string destinationTableName, string[] columnMappings)
    {
        using (SqlBulkCopy sbc = new SqlBulkCopy(DBHelper.Secim2009DB.ConnectionString, SqlBulkCopyOptions.UseInternalTransaction))
        {                
            sbc.DestinationTableName = destinationTableName;
            // Number of records to be processed in one go
            sbc.BatchSize = 30000;
            // Map the Source Column from DataTabel to the Destination Columns in SQL Server 2005 Person Table

            foreach (string columnMapping in columnMappings)
            {
                sbc.ColumnMappings.Add(columnMapping, columnMapping);
            }

            // Number of records after which client has to be notified about its status
            sbc.NotifyAfter = dtInsertRows.Rows.Count;
            // Event that gets fired when NotifyAfter number of records are processed.
            sbc.SqlRowsCopied += new SqlRowsCopiedEventHandler(sbc_SqlRowsCopied);
            // Finally write to server
            sbc.WriteToServer(dtInsertRows);
            sbc.Close();
        }
    }

    public static void sbc_SqlRowsCopied(object sender, SqlRowsCopiedEventArgs e)
    {            

    }

«У нас есть требование хранить 500 измерений в секунду, поступающих с нескольких устройств».

Не используйте СУБД для хранения таких данных.

По каким причинам люди используют СУБД?

(a) Они могут наложить на вас ограничения на данные, которые вы пытаетесь зарегистрировать. Но у тебя их нет. Данные измерений такие, какие они есть, и их необходимо принять. Никаких ограничений.

(b) Они могут гарантировать согласованность и целостность ваших ценных бизнес-данных в случае (1) нарушения ограничений и (2) серьезных сбоев системы, таких как ошибки дискового ввода-вывода. Но поскольку у вас нет ограничений, (1) не применяется. А что касается (2), что вы будете делать со своими измерениями, если ошибка ввода-вывода диска не позволяет их записать? Ваши измерения теряются несмотря ни на что.

Итак, imo, у вас нет никаких причин использовать СУБД. Сохраните свою загрузку измерений в плоский файл и обработайте его по мере необходимости.

Вы можете рассмотреть другие альтернативы Базы данных. MSSQL предоставляет много функциональных возможностей, но это добавляет некоторые накладные расходы.

Отличный ресурс по высокопроизводительной обработке данных (как то, что вы пытаетесь сделать) находится на http://highscalability.com/

Одно из тематических исследований, которое они проводили - хранение статистики тысяч устройств в базе данных. Решение заключалось в использовании нескольких баз данных MYSQL и маршрутизации запроса на основе идентификатора устройства. В целом - сайт может предоставить отличные примеры. Возможно, вы сможете найти там возможное решение.

TImur