шаблон обновления azure cosmos db

<p>недавно я начал использовать cosmos db для проекта, и у меня возникли некоторые проблемы с дизайном. исходя из фона sql, я понимаю, что связанные данные должны быть вложены в документы в базе данных nosql. это означает, что документы могут стать довольно большими, хотя. </p><p>поскольку частичные обновления не поддерживаются, какой шаблон проектирования лучше всего реализовать, если вы хотите обновить одно свойство документа? </p><p>должен ли я читать всю сторону сервера документов, обновлять значение и записывать документ обратно для немедленного обновления? это кажется проблематичным, если документы большие, что неизбежно будет, если все ваши данные будут вложенными.</p><p>если я использую подход, заключающийся в создании множества документов меньшего размера и выводим отношения на основе идентификаторов, я думаю, что это немедленно решит проблему чтения/записи для обновления, но мне кажется, что я иду против концепции nosql и, по сути, я строю реляционные db.</p><p>спасибо</p>

<p><strong> блокировка и фиксация. </strong>вот что должно произойти, если возможны частичные обновления. сложно с инженерной проблемой сохранить задержку записи <15 мс sla с блокировкой.</p><blockquote> <p>это кажется проблематичным, если документы большие, что неизбежно будет, если все ваши данные будут вложенными.</p> </blockquote><p>определите свой страх - сожженные блоки запросов, память хоста приложения, входящий/исходящий сетевой трафик? вы верите, что это проблема, но не указываете конкретные результаты. я не говорю, что вы не правы или сомневаетесь в эффективности подхода частичного обновления, я просто говорю, что аргумент невелик.</p><p>обычно вы хотите, чтобы <code>join</code> ничего в nosql, поэтому я полностью с вами в последнем абзаце.</p>

<p>всякий раз, когда вы пытаетесь создать документ, постарайтесь учесть это:</p><ul> <li><p>нужна ли отдельная часть доступа к части документа? если да, то создайте ссылочный документ, а если нет, то создайте внедренный документ.</p> <p>и если вы хотите знать, что выбрать, я думаю, вам следует взглянуть на этот вопрос для mongodb, но он вам поможет <a href="https://stackoverflow.com/questions/5373198/mongodb-relationships-embed-or-reference">embedded vs referenced document</a> </p></li> </ul>

<p><strong> внедрение или ссылка </strong>- самая распространенная проблема, с которой я сталкиваюсь при разработке структуры документа в мире nosql.</p><p>во встроенных отношениях дочерние объекты были встроены в родительский документ. в ссылочных отношениях дочерние объекты в отдельных документах и их родительские объекты в другом документе, в основном имеющие два (или более) типа документов.</p><p>не существует единой модели отношений, подходящей для всех. подход, который вы должны предпринять, зависит от того, какие извлечения и обновления должны быть выполнены для разрабатываемых данных.</p><p>1. вам нужно получить все дочерние объекты вместе с родительскими объектами? если да, используйте встроенные отношения.</p><p>2. ваш вариант использования позволяет получать объекты по отдельности? в этом случае использовать шаблон отношений.</p><p>в большинстве случаев, когда я работал, я использовал паттерн отношений. например: социальный график (профили с деревом отношений), точки приближения (поиск близости на основе geojson), классифицированный листинг и т.д.</p><p>шаблон отношений также легче обновлять и поддерживать, поскольку объекты хранятся в отдельных документах.</p>