Поскольку (а) информация, с которой вы работаете, сама по себе является очень ценным организационным ресурсом, и (б) объем данных будет значительным, я бы решительно (в) построил реляционную базу данных на одном из основные платформы SQL.
Это, конечно, с очень общей точки зрения, требует трех существенных факторов:
Четко определенная концептуальная схема, в которой необходимо точно идентифицировать и разметить прототипы вещей, то есть типы сущностей (включая их свойства и взаимосвязи ), имеющие отношение к бизнес-среде, с которой вы работаете (например, башни и Датчики ты упоминаешь).
Как известно, этот момент влечет за собой налаживание постоянного и продуктивного общения с бизнес-экспертами.
Логическая разметка , которая отражает концептуальный уровень с точностью, с помощью таблиц (то есть, математические отношений) , имеющих хорошо разделенных столбцов с соответствующими столбцами именами и типами (например, соотношение атрибутов) и все соответствующие ограничениями , чтобы гарантировать , что удовлетворяет данные с все правила определены на предыдущем уровне.
Следовательно, именно здесь вступает в действие огромная сила реляционной модели (хотя ее преимущества имеют положительные последствия на других уровнях абстракции).
Физическое расположение , что, например, повышает скорость выполнения -dynamic- логических операций манипулирования данных и гарантии логических ограничения.
Поскольку реляционная модель обеспечивает физическую независимость данных, система управления базами данных (для краткости, СУБД) может обеспечить любую структуру на этом уровне, не только индексы, для поддержки логических определений. В случае с ведущими платформами SQL, да, это обычно подразумевает, в частности, настройку стратегии индексирования на основе тенденций запросов к базе данных, и вы выдвинули очень интересные соображения относительно некоторых возможных конфигураций, но, не зная конкретных информационные потребности с точностью, предлагая конкретные советы в этом отношении не будет подходящим.
Другими элементами, которые заслуживают оценки, являются, например, модернизация сетевой инфраструктуры для увеличения пропускной способности, обеспечение надлежащих конфигураций сервера (аппаратно и программно) и т. Д. И, если и только если практикующий специалист достаточно квалифицирован, он или она может даже изменить исходный код выбранной СУБД (естественно, более выполнимо в средах с открытым исходным кодом).
Таким образом, следующие аспекты, которые вы выделяете
- Управляйте и извлекайте конфигурации колонны / сенсора для анализа данных.
- Визуализация данных с помощью датчика или временных интервалов для метеорологических наблюдений.
- Предоставить клиентам надежные и постоянные ресурсы данных / наборы данных для сравнения производительности модели и датчика (может потребоваться некоторая постобработка для доставки в требуемом формате?).
будет хорошо решен, потому что вы легко сможете объявить запросы, например, чтобы получить информацию в очень значимых формах. Например, вы можете получить данные, связанные с
- Датчик, идентифицируемый SensorNumber
1750, установленный в Башне, идентифицируемой TowerNumber 31, между датой 1 June 2017и датой27 June 2017 .
Кроме того, поскольку (1) данные в реляционной базе данных логически управляются в терминах множеств с помощью операций, основанных на реляционной алгебре , и (2) различные механизмы SQL физически оптимизированы (некоторые больше, чем другие) для множества обработки , вы можете, например,
- сравнить множество А с множеством Ь ;
- соединить множество c с множеством d ;
- получить суб множество п через ограничение на множество е ;
- произвести n подмножеств из n пересечений множества;
- Проект N атрибутов из набора F
- извлечь информацию из множества z, которая является результатом объединения множества x с множеством y ;
- и так далее.
Возможности манипулирования данными на самом деле огромны - демонстрируя непревзойденную универсальность реляционной парадигмы - поскольку вы можете работать не только с базовыми таблицами (объявленными с помощью CREATE TABLE … ( … );операторов), но и с производными (те, которые выражаются с помощью SELECT …;операций, иногда фиксируемых как VIEWs) , Другими словами, вы можете (i) выразить новые структуры данных на основе (ii) предыдущих, работающих на (iii) единственной базовой реляционной конструкции, то есть математическом отношении.
Очевидно, что расположение базовых таблиц и столбцов реляционной базы данных может развиваться, и (а) новые базовые таблицы или столбцы могут быть включены в него, когда (b) отслеживание новых типов объектов или свойств типов объектов считается целесообразным в соответствующий бизнес-контекст. Другими словами, ни исходная структура, ни ограничения открытия реляционной базы данных не должны быть статическими или неизменными. Кроме того, база данных, которая должным образом организована с самого начала, имеет тенденцию быть намного легче изменить, когда возникают новые информационные требования.
В соответствии с вышеизложенными соображениями логический формат применимых наборов должен создаваться декларативно на логическом уровне базы данных. Графическое или презентационное форматирование множеств (например, окраска или шрифты лиц используется) должны в своей очереди, обрабатываются посредством кода одного или несколько прикладных программ (да, в основном , в процедурном порядке, возможно , с помощью объекта -ориентированные рамки, HTML и т. д.), чтобы сделать доступ к таким наборам удобным для пользователей. Конечно, вы могли бы также использовать программное обеспечение для отчетности, которое подключается к вашей базе данных.
Моделирование базы данных актуальности
Учитывая, что вы будете работать с данными датчиков (которые, помимо прочих функций, обычно включают информацию в виде временных рядов ), вы можете найти помощь в проектировании нескольких баз данных и общих принципах администрирования, содержащихся в двух исключительных ответах @PerformanceDBA , на вопросы, озаглавленные:
Реляционный подход, плоский файл и NoSQL
Реляционная модель от доктора Эдгара Франка Кодда , хотя опубликованная в 1970 году, по- прежнему действительно самый современный и элегантный метод (основанный на логике и теории множеств) , чтобы справиться с проблемой управления данными. Отдельные СУБД SQL, в свою очередь, являются наиболее популярными приближениями (которые, хотя и не полностью совместимы, тем не менее действительно мощны) с системами, предложенными в теории отношений, и некоторые из них были сильно оптимизированы (например, в отношении их механизмы уровня) в течение даже десятилетий. Кроме того, основные платформы SQL, конечно, могут (и будут способны) работать с самыми современными технологиями хранения (например, жесткие диски) и обработки (например, процессоры) достаточно эффективно.
При построении на мощной СУБД реляционная база данных, которая должным образом разработана на концептуальном, логическом и физическом уровнях, определенно станет автономным, информативным и самозащитным активом, который (1) заслуживает доверия, а (2) предлагает быстрый ответ, два аспекта, которые, как вы знаете, имеют большое значение.
Плоские файлы
Таким образом, утверждение, которое следует
Мне сказали, что обоснование использования плоских файлов заключается в том, что они полагали, что реляционная база данных потребует слишком много времени.
легко отбрасывается, потому что подход плоского файла будет:
- донаучный;
- далеко не оптимально для больших объемов данных;
- слишком громоздко;
- зависит от прикладной программы (и вам придется вручную реализовать большинство функций, которые изначально предлагаются в соответствующих СУБД);
- его производительность будет легко подорвана;
- и т.п.
Принимая во внимание то, что «гораздо более удобный» способ отношений, если не сказать больше:
- будет предлагать большую масштабируемость (она не зависит от физического уровня, поэтому вы можете при необходимости улучшить базовые физические механизмы);
- принес бы простой стиль для манипулирования данными (с помощью абстрактных операций) и
- может работать с несколькими прикладными программами одновременно (например, с одним или несколькими мобильными приложениями и / или одним или несколькими веб-приложениями, и / или одним или несколькими приложениями для настольных компьютеров и т. д.).
Однако, если вы решили использовать плоские файлы, вам следует оценить использование надежной утилиты, такой как Awk, которая, хотя и не является СУБД (и не была разработана как таковая), предоставляет удобные ресурсы для работы с файлами , записями , полями и т. Д. См . Руководство пользователя GNU Awk для получения дополнительной информации по этому вопросу.
NoSQL
«Неструктурированные данные» и связанные с ними термины
Согласно их пропаганде, первоначальное обоснование использования СУБД NoSQL заключается в том, что они предназначены для использования в бизнес-доменах, которые включают обработку «неструктурированных данных», поэтому возникает вопрос:
- Что должно означать выражение «неструктурированные данные»?
В этой связи следует сказать , что данные, по самой своей природе, является структурированным; если бы он не имел структуры, то это было бы чем-то бессмысленным, следовательно, такую вещь (i) нельзя было бы считать данными и (ii) не стоило бы управлять. Следовательно, «неструктурированные данные» являются противоречивым и неудачным выражением.
Другая фраза этих контекстов - «полуструктурированные данные». Эта фраза предполагает, что существуют данные, которые структурированы «частично» или «пополам», поэтому, в соответствии с предыдущим параграфом, только «часть» или «половина», которые структурированы, могут быть фактическими данными, оставшаяся «часть» или «половина» - это просто бесформенная вещь, потому что она не имеет структуры и не может называться данными.
Еще один, увы, типичный термин, встречающийся в маркетинге NoSQL, - это «полиморфные данные». Если упомянутый термин означает что-то вроде «данных, которые имеют много разных форм», то на самом деле это обычные данные, они, как всегда, встречаются в разных формах. А поскольку он имеет много разных форм, он представляет много различных структур , поэтому в этом «виде» данных нет ничего особенного.
Излишне говорить, что данные и структуры данных всегда были подвержены изменениям , и в этом нет ничего необычного.
Рост объема данных
Очевидно, что объемы информации, управляемой с помощью компьютеризированных систем, безусловно, выросли за эти годы - и будут расти экспоненциально с течением времени, потому что новые системы строятся каждый день - но это факт, который не имеет отношения к структура информации как таковая .
Отсутствие округлой теоретической основы
Критическое ограничение систем NoSQL (существуют различные классы, например, на основе документов и графиков ), заключается в том, что ни один из текущих продуктов, хотя и широко продаваемых и помеченных как «современные», не имеет надежной теоретической основы (если вообще существует) который поддерживает каждый из трех наиболее важных элементов надлежащей СУБД, т. е. инструменты для определения данных (а), (б) манипуляции и (в) сжатие. Таким образом, подход NoSQL фактически предлагает регресс в древнюю эпоху, когда обработка данных осуществлялась нерегулярным и необоснованным образом, со всей ненужной сложностью, которую это влечет за собой.
В настоящее время графовые системы включены в спектр «NoSQL». Эти программные продукты предлагают управлять данными посредством операций на двух различных структурах: узлах и взаимосвязях - что опять-таки противоречит термину «неструктурированные данные» - и они выделяются в группе «NoSQL», потому что они иметь математическое обоснование. Тем не менее, графические продукты довольно похожи на сетевые платформы, которые считаются устаревшими десятки лет назад (очевидный недостаток заключается в том, что, как указывалось выше, им нужны две структуры для представления данных, в то время как реляционные СУБД - в соответствии с информационным принципом - нужен только один).
Даже если создание различных систем NoSQL является хронологически более новым по сравнению с происхождением большинства СУБД SQL, большинство концепций, на которых основаны продукты NoSQL, фактически являются примитивными .
Программа NoSQL должна использоваться, в основном, в сценариях, где, например,
- ИТ-персоналу не хватает технических навыков, необходимых для определения (или своевременного определения) структуры данных, представляющих интерес, например, из-за их сложности; и / или
- организация не может позволить себе подходящее образование и подготовку для нынешнего персонала или не может нанять новых сотрудников, обладающих необходимым образованием и подготовкой; и / или
- когда целостность и согласованность данных не особенно важны; и / или
- при объединении соответствующих данных с данными критически важных систем, требующих высокой точности, не ожидается.
Но даже если структура данных, о которых идет речь, не была определена до создания соответствующих систем, одному или нескольким людям обязательно придется
- обнаружить вышеупомянутую структуру,
- отбросить все окружающие «помехи» и
- собрать и связать правильные данные
после того, как база данных и приложения вошли в производственную стадию, чтобы иметь возможность получить максимальную отдачу от всех ресурсов, вложенных в проект, разграничение структуры данных - это задача, которую невозможно обойти, это нужно сделать раньше или позже.
Таким образом, хотя путь NoSQL возможен, все упомянутые выше факторы должны быть обязательно приняты во внимание.
Самый надежный метод
Напротив, подход к информационным требованиям бизнес-среды реляционным образом, то есть с общей парадигмой, предлагает возможности (1) управления данными в их естественной структуре с самого начала, что облегчает интеграцию с другими источниками данных - а также (2) создание новых заслуживающих доверия структур путем манипулирования одним инструментом - как объяснялось в предыдущих разделах - который имеет прочную научную основу.
Согласно вашему описанию рассматриваемого сценария, вы уже определили конкретную структуру с точки зрения соответствующих организационных потребностей, поэтому я предлагаю запросить ее у экспертов в области бизнеса. Затем я рекомендую использовать (i) конструкции - отношения, ограничения и операции - предоставляемые реляционной моделью для обработки указанной структуры и соответствующих данных, и (ii) выбранную вами СУБД SQL, которая с большой вероятностью предлагают очень эффективные физические инструменты, которые могут удовлетворить существующие требования и обеспечат будущую масштабируемость.