Механизм обновления NoSql для сценариев CRUD - PullRequest
Новая
       13

Механизм обновления NoSql для сценариев CRUD

3 голосов
/ 21 октября 2011

У меня есть опыт работы с Orm Frameworks, и я начинаю понимать структуру решений для баз данных NoSql. Я продолжу некоторые примеры, основанные на объектных моделях.

У меня есть модель документа ниже, и я хочу подумать о нескольких сценариях обработки.

  1. Сохранить сообщение с несколькими тегами
  2. Показать список тегов с количеством сообщений
  3. Обновить тег 
public class Post
{
    public string Title { get; set; }
    public List<Tag> Tags { get; set; }
}

public class Tag
{
    public string Name { get; set; }
}

И у меня возникает несколько вопросов о моих сценариях.

Класс записи - это документ, который будет сохранен с тегами. В СУБД Tag и Post имеют отношения многие ко многим, но я понимаю, что они не имеют никаких отношений в NoSql, поэтому объект post сохраняется с целыми членами. Так что показ списка тегов со сценарием подсчета сообщений приведет к интенсивному запросу во всех элементах записи с некоторыми усилиями в каждом запросе, поэтому я не теряю всех преимуществ NoSql в этом сценарии?

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

Я не пытаюсь показать минусы NoSql по сравнению с системами RDBMS (Sql). Я просто пытаюсь понять, что мое мышление правильно в отношении этого сценария или нет, может быть что-то, что я пропустил, или вещи выглядят плохо не так плохо, как я думал. Мне нужна масштабируемость, поэтому я заинтересован в решениях NoSql.

1 Ответ

0 голосов
/ 20 июля 2013

Во-первых, NoSQL - это просто модное слово, которое охватывает множество различных типов баз данных, таких как хранилища значений ключей, хранилища документов, графовые базы данных, ... См. http://nosql -database.org / для список разных типов и реализаций. Некоторые из этих систем также имеют транзакционные гарантии, например, для вашего случая, что сообщение полностью записано в базу данных.

Теперь я сосредоточусь на хранилищах значений ключей, поскольку они кажутся очень заметным экземпляром NoSQL.

Относительно вашего первого вопроса: вы правы, вы бы не использовали строгие отношения, как внешний ключ в СУБД, но вы бы просто сохранили список тегов, связанных с экземпляром записи: 

| pid | title | tags
|  1  | foo   | sql, rdbms
|  2  | bar   | sql, acid
...

Для запроса по тегу у вас есть так называемый Инвертированный индекс (http://en.wikipedia.org/wiki/Inverted_index), который дает вам все идентификаторы документов для одного тега: 

| tag   | pids
| sql   | 1, 2
| rdbms | 1
| acid  | 2

Это позволяет довольно легко вести подсчет сообщений.

Обновление имен тегов на самом деле не так сложно, если у вас есть доступ к вашим данным на основе сокращения карты, то вы можете, например, обновите тег 'Sql' до 'SQL' с помощью простого задания (псевдокод): 

map:    IF post.tag contains('Sql') THEN emit(post)

reduce: in post.tag: replace('Sql' by 'SQL')
        write(post)

Но я не думаю, что переименование тегов - обычное дело. Проблема с длительным временем обработки и несогласованностью сформулирована Брюером в CAP-теореме (http://en.wikipedia.org/wiki/CAP_theorem), которая в основном говорит о том, что вы не можете иметь согласованность, доступность и допуск на разделы одновременно, и вам приходится торговать по крайней мере, один для двух других. В вашем случае: если вы хотите иметь постоянное обновление тега (например, нельзя прочитать два документа, где у одного есть тег 'Sql', а у другого уже есть 'SQL), вам пришлось заблокировать таблицу для других читатели, и, следовательно, у вас не будет доступности.

Заключительная мысль: если вы хотите создать высокодоступную, хорошую платформу для масштабирования, вам не нужно слишком много думать о взаимоотношениях.

...