Я оцениваю ряд реализаций NoSQL (на данный момент RavenDB и MongoDB) как средство решения определенного набора требований, которые включают хранение / поиск данных, которые не требуют схем.Я хочу получить некоторую обратную связь о том, является ли NoSQL направлением, в котором я должен искать, или есть ли другие (потенциально более простые) варианты.
По сути, у нас есть программный продукт, который (среди прочего) определяет основныеМодель предметной области, состоящая из нескольких связанных объектов, каждый из которых имеет ряд атрибутов (ключ / значение).Когда мы предоставляем заказчику, мы работаем с ним, чтобы настроить атрибуты и значения, которые, по сути, являются конфигурацией системы.Это довольно просто, и поскольку дизайн известен заранее, нам не нужно ничего динамичного, чтобы достичь этого и заставить его работать (мы будем использовать СУБД).Атрибуты не известны заранее, но, опять же, это не проблема, так как эта часть системы вращается вокруг модели атрибутов.
Проблема в том, что для разных клиентов, и ПОСЛЕ того, как мы выпускаем и находимся вВ процессе производства мы обнаруживаем, что нам нужно запросить определенные наборы данных атрибутов, о которых мы ничего не знали, когда мы компилировали и выпускали код (и до того, как мы настроили атрибуты для клиента).В основном нам нужно получить данные из карт атрибутов, которые мы можем сохранить (мы не будем знать структуру заранее), а затем запросить эти данные позже, что мы не можем предвидеть.Сейчас мы думаем о том, что мы можем создать хуки, которые получают удар во время обработки, и позволяют нам подключать библиотеки (вероятно, через MEF), которые создают данные для их сохранения, а затем запрашивают их позже, когда это необходимо (не для отчетов -обычно для создания дополнительных данных / атрибутов.).
(Обратите внимание, что создание библиотек подключений и подключаемых модулей - это отдельная проблема, и она не предназначена для этого вопроса.)
AРаспространенным сценарием может быть: «Я хочу знать, сколько раз ххх происходило за последние 10 дней».Поэтому я бы создал плагин, который распознал бы, что произошел ххх, и записал бы его в хранилище данных с датой / временем.Затем я создал бы другой плагин (вероятно, в той же DLL), который выполнял бы запрос, и добавил бы в модель атрибут с именем «CountOfxxxInLast10Days».Другой сценарий может заключаться в создании настраиваемых поисков.Поэтому у меня может быть плагин, который запускается при запуске для создания / обновления таблицы данных поиска, которая может преобразовывать одно значение атрибута в другое, или (более вероятно) диапазон значений, который будет преобразован в значения поиска.Таким образом, плагин преобразования может добавить таблицу со столбцами: bottom_value, top_value, множитель, а плагин запроса будет запрашивать таблицу, используя значение атрибута, например «Множитель SELECT ИЗ таблицы WHERE [attribute_value] BETWEEN bottom_value AND top_value».Результат может добавить результат к атрибуту с именем «Множитель».
В некоторых случаях старые данные могут быть удалены после определенного периода времени.В первом сценарии, описанном выше, может быть желательно удалить данные из хранилища / кэша, которые были старше десяти дней.
В других случаях данные должны были бы сохраняться постоянно, как во втором сценарии выше.Возможно, эти данные могут быть просто воссозданы при запуске, а не храниться в постоянном хранилище.
Дополнительные требования:
- Хранилище данных / кэш можно создать резервную копию и восстановитьв режиме онлайн
- Может быть заменен / восстановлен из последней резервной копии в случае сбоя
- Данные выживают при таких событиях, как перезагрузка компьютера
- Проверенная / протестированная на производстве технология
На данный момент мы довольно привержены платформе .Net, поэтому для любого варианта необходим надежный клиент / API .Net.