Как хранить данные при отсутствии схемы?

Question

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

Я хочу сохранить данные, которые являются результатом работы сценариев powershell. Это означает, что администратор моего приложения сможет написать сценарий powershell, который будет выполняться на нескольких хостах, и отправит результаты обратно в хранилище данных. Затем я хочу гибко запросить это хранилище.

Позвольте мне уточнить. Данные, возвращаемые из задания powershell, - это не правильный объект, а набор ключей / значений свойств объектов. Таким образом, нет реального объекта для сериализации.

Допустим, я говорю 100 хостам через службу WCF выполнить две команды powershell Get-Service и Get-Process, и они затем отправят результаты обратно в мое хранилище данных. Я не знаю схемы этих данных заранее.

Дело не в PowerShell и не в WCF, а в том, как вы будете хранить данные, которые на момент сохранения схемы неизвестны. И запросы будут создаваться вручную через некоторый графический интерфейс впоследствии на основе данных, которые были сохранены.

После этого я хотел бы иметь возможность выполнить запрос типа «Получить список всех хостов, на которых запущена служба X и запущен процесс Y»?

Я рассматриваю базы данных nosql как альтернативу реляционным БД, но не уверен, что лучше.

Благодарен за любой вклад. / Линус

Answer 1

Если хранение данных в виде XML в СУБД не имеет смысла для вас (кстати, почему бы и нет?), То есть несколько БД NoSQL, которые, вероятно, были бы хорошими вариантами, поскольку они не содержат схем.

Те, которые я могу порекомендовать вам посмотреть (исходя из личного опыта, есть много других, которые могут иметь отношение к делу), это CouchDB и Riak. Оба предоставляют привязанное к диску хранилище данных ключа-значения, в котором вы храните свои значения как JSON, без предварительного определения схемы. В обоих случаях можно запрашивать данные через интерфейс RESTful, используя Javascript.

Выбор должен зависеть от объема ожидаемых данных:

• Riak предназначен для работы на нескольких узлах, а запросы обрабатываются с помощью MapReduce, так что обработка распределяется между этими узлами, что позволяет относительно быстро получать данные для специальных запросов. Если у вас есть много данных - миллионы записей, которые вы должны выполнить специальные запросы, выберите это. Вы будете «платить» дополнительной сложностью управления кластером, хотя я могу засвидетельствовать, что Riak делает его относительно безболезненным.
• CouchDB предназначен для работы на одном узле. Репликация возможна (и проста), но запросы выполняются на одном сервере. Он материализовал индексы, поэтому запросы к существующим индексам выполняются быстро. Специальные запросы требуют полного «сканирования таблицы» и могут занимать минуты для больших наборов данных. ОТО, у него есть преимущество приятного пользовательского интерфейса на основе браузера, которого у Riak нет в бесплатной версии.

Я бы рекомендовал сначала попробовать Couch - очень легко настроить и начать играть - и посмотреть, решит ли это вашу проблему. Если это не так, то иди к Риаку.

Answer 2

Если вы хотите хранить данные, структуру которых вы не знаете во время разработки, у вас есть несколько вариантов.

Среди опций:

Сохранить данные в формате xml (вБД или файлы).

Создание схемы динамически в соответствии со структурой динамических данных.

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

Например (общая структура класса)

GenericClass
{
    GenericProperty[] SimpleProperties;
    Dictionary[string, GenericClass] ComplexProperties;
}

GenericProperty
{
    String Name;
}

StringProperty: GenericProperty
{
    String Value;
}

IntegerProperty: GenericProperty
{
    Integer Value;
}

Использование таблиц для каждого типа в этих классах должно дать вам общие таблицы.