В связи с тем, что использование NoSQL ширится, возникает много вопросов.
Существует RDBMS, и для проектирования хранилищ в нём есть Entity-Relation и реляционная логика, есть понятие нормальных форм, и наоборт, денормализации, и критериев его использования. Есть SQL, позволяющий выполнять запросы.
А с NoSQL как быть? Есть ли теория, best-practices etc? Как научиться?
Задача приложения состоит в том, чтобы получать большой объем данных от внешнего источника в режиме soft-realtime, на основании его строить сложную доменную модель, выполнять расчёты над этой моделью, иногда повторные, с изменившимися параметрами, и сохранять полученные результаты — результаты получаются тоже в виде модели (попроще)
NoSQL дает вам возможность вытянуть максимум информации об объекте одним запросом. Имеено это, насколько я могу судь из своего чуть более чем годового опыта, и является основнопологаеющей концепцией.
Конечно это неизбежно приводит к повсеместному размазыванию и копированию информации, но ведь правда приятно вытянуть контент статьи с комментариями одним запросом (стандартный пример из документации)
Понимаете, проблема в том, что везде в качестве первого и последнего примера приводят модельную доменку «статья + комментарии». Помимо того, что это текстовые данные (т.е. хорошо подходят для document-oriented, что, в общем случае != NoSQL), приведенная доменная модель — простая, с малой глубиной и отсутствием перекрёстных связей и такое прочее
Я работал не только с документацией и объекты получались действительно достаточно объемными и сложно структурироваными, здесь всегда нужно искать золотую середину, поэтому для меня переписать несколько раз некоторые моменты взаимодействия с бд при разработке — нормальная практика, РСУБД как избавляет от таких мытарств, но не дает гибкости
NoSQL — слишком широкое понятие, и различные NoSQL DBMS слишком сильно отличаются, чтобы говорить об универсальных best-practices.
Если модели надо хранить в виде простых blob'ов без особо сложных межобъектных связей, для soft-realtime системы может быть удобен Riak.
Не не не, тот же Riak мне не подходит, потому что он нацелен на избыточность и отказоустойчивость, а мне нужны транзакции. Но предположим, что я уже определился и юзаю BerkeleyDB.
Вопрос не в том, какой конкретно провайдер хранилища юзать, а как проектировать хранилище данных в отсутствие реляционной парадигмы
Простой
