структурированные и неструктурированные данные в дБ

Question

вопрос один из дизайна. Я собираю большой кусок данных о производительности с большим количеством пар ключ-значение. почти все в / proc / cpuinfo, / proc / meminfo /, / proc / loadavg, а также куча других вещей с нескольких сотен хостов. сейчас мне просто нужно отобразить последние данные в моем интерфейсе. Я, вероятно, в конечном итоге проведу некоторый анализ собранных данных, чтобы выяснить проблемы с производительностью в будущем, но это новое приложение, поэтому я пока не уверен, что именно я ищу в плане производительности.

я мог бы структурировать данные в БД - иметь столбец для каждого ключа, который я собираю. таблица будет иметь ширину O (100) столбцов, было бы сложно поместить ее в БД, мне пришлось бы добавлять новые столбцы, если бы я начал собирать новую статистику. но было бы легко сортировать / анализировать данные, просто используя SQL.

или я мог бы просто выбросить мой неструктурированный большой двоичный объект в таблицу. возможно три столбца - идентификатор хоста, временная метка и сериализованная версия моего массива, возможно, с использованием JSON в поле TEXT.

что мне делать? я буду сожалеть, если я пойду с неструктурированным подходом? при анализе я должен просто преобразовать интересующие меня поля и создать новую, более структурированную таблицу? какие компромиссы мне здесь не хватает?

Answer 1

Я говорю, что если вам нужно выполнить SQL-запросы для вычисления таких вещей, как min / max / avg или для выполнения сортировки, ограничений или объединений на основе значений, то вам нужно создать более 100 столбцов.Это то, что я бы сделал.

Вы не указываете, какую марку базы данных вы используете, но большинство должно поддерживать более 100 столбцов в таблице без риска неэффективности.

Пожалуйста не используйте антипаттерн Entity-Attribute-Value - ключ / значение, предложенный некоторыми людьми.Хорошо и легко вставить любую произвольную коллекцию пар ключ / значение в такой дизайн, но любые запросы, которые было бы просто выполнить в обычной таблице с одним столбцом на атрибут, становятся безумно трудными и неэффективными с дизайном EAV.Вы также потеряете много преимуществ использования базы данных SQL, таких как типы данных и ограничения.

Answer 2

Спасибо за ваши предложения.

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

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

Исходя из моего опыта работы с EAV, я не думаю, что это хорошая идея. Это не облегчает проведение долгосрочного анализа (проблема 40-полосного соединения или разворота), а также из-за того, что мои данные не плоские, будет намного проще хранить необработанные данные.

Answer 3

http://blogs.technet.com/fort_sql/archive/2010/03/26/the-myth-of-unstructured-data.aspx

http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

Answer 4

Вот альтернативное решение: использовать более одной таблицы.

Очевидным дизайном схемы будет таблица для каждой cpuinfo, meminfo, loadavg и т. Д. Вы можете получить таблицу miscellaneous_stats, в зависимости от того, что вы включаете в «кучу другие вещи ".

У этого подхода есть несколько привлекательных особенностей:

• Упрощенное именование столбцов.
• легко сообщать о связанных подмножествах статистики, например все meminfo. Вероятно, лучшая производительность тоже.
• Менее проблематично добавить столбец. Если вы начнете собирать новую статистику cpuinfo, все они будут сгруппированы вместе, тогда как в One Big Yable у вас получатся столбцы 1-15 и столбец 94.
• детализация записи. Например, вы можете не захотеть регистрировать cpuinfo так часто, как meminfo.

У вас должна быть основная таблица stats_runs для хранения таких вещей, как HOST, TIMESTAMP и т. Д., А не для дублирования этих деталей в каждой таблице.

У меня есть два рабочих предположения, лежащих в основе этого предложения:

1. Вы собираетесь провести некоторый анализ этих данных (потому что, если вы не собираетесь их анализировать во время сбора?).
2. SQL остается лучшим механизмом обработки данных, хотя инструменты для работы с плоскими файлами постоянно совершенствуются.

Answer 5

я думаю

performance_data

        host_id
        key
        value
        timestamp

- правильная структура. вы сможете запрашивать определенные подмножества от определенных хостов в определенное время для генерации вашего анализа.