Какой формат данных выбрать для хранения сущностей (sql\nosql(json))?
Привет!
Возникла задача создать базу, которые бы описывали некие объекты. У объектов может быть некоторое количество свойств, которые в будущем могут добавляться. Например, свойство, описывающее состояние, некоторые свойства могут быть в виде списка. Например, цена для разных категорий покупателей. Сейчас количество вот таких свойств около 8, с деталями (поля) - на 3 листа А4.
Количество объектов изначально не очень большое - около 1000. Но запланировать нужно вменяемую работу как минимум 10к, а еще лучше - миллион (но там уже будет возможность секционирования\группировки по областям).
Должна быть возможность фильтрации по параметрам объектов.
Итак.
1. Сделать это обычным SQL решением.
Из минусов - необходимость набивания этих таблиц, миграции (буду делать естественно с помощью EF),
Из плюсов - простота выборки данных.
2. Комбинированное решение, SQL табличка и Key-Value таблица (либо использовать функционал MongoDB)
В sql хранятся заголовки, например артикул, название и еще какая-то мелочь (несколько столбцов) и ID, по ID связывается с JSON документом.
Плюсы - относительная простота работы с данными, как с объектами.
Минусы - отсутсвие миграции как таковой при переименовании полей или изменении типов (в т.ч. был просто объект, стал массив) - с миграцией хуже.
Фильтрация - либо выборка всей БД, либо использование инструментов в MongoDB по фильтрации в JSONе.
Да, хотелось бы еще в случае дальнейшего развития проекта прикрутить CQRS-ES. Пока не знаю к чему его легче будет прикрутить.
Для миллиона записей совершенно неважно, какое именно решение вы используете.
Если начать с чистого реляционного SQL, то данные, где реляционность не нужна, потом можно сериализовать и хранить в бинарных полях реляционных таблиц.
Используя NoSQL, вы в некотором роде усложните себе работу, так как появится необходимость придумывать и накладывать на коллекции индексы, чтобы быстро делать выборки и считать агрегаты.
Однако, у NoSQL есть заметное преимущество — эти хранилища "из коробки" могут довольно неплохо объединяться в отказоустойчивые кластеры. Правда, отсутствие транзакций и eventually consistence не позволят вам гарантированно читать только что записанные в кластер данные.
Соответственно, комбинированное решение объединит достоинства и недостатки обоих миров.
На Хабре было много статей про документные БД, надо заранее прочитать про их все ограничение и родовые травмы. MongoDB активно развивается, но сама концепция документных БД сильно отличается от реляционных и надо ее понимать, желательно сначала потренироваться на домашнем проекте.
Все то что написано в реляционном виде легко реализуется.
Простой
Простой
