Как смоделировать данные с помощью MongoDB

Question

У нас есть относительное крупномасштабное приложение, использующее реляционную БД (MSSQL). После большого чтения я решил, что хочу изучить с помощью MongoDB, а не MSSQL, главным образом из-за проблем производительности и масштаба.

я читать и изучать о Монго и не мог понять, ответ на следующие вопросы:

1. Должны ли мы сделать это? Говорим, что у нас есть время инвестировать, единственный вопрос: «Это хорошо для нас?»
2. Как смоделировать наши данные?

Моя проблема с монго заключается в том, что у нас в нашей БД есть много отношений. После прочтения this great post (и second part, а), я понял, хорошая практика будет разделить решение на 3 сценария:

1. 1 до нескольких
2. 1 ко многим
3. 1 до squillions ,

В нашем db, в большинстве случаев мы используем один-ко-многим, но проблема в том, что в большинстве случаев это один и тот же «один».

Например, у нас есть таблицы пользователей и транзакций. Каждый пользователь может выполнить транзакцию, поэтому в основном то, что я должен сделать, чтобы моделировать пользователя следующим образом:

{ «имя»: «Джон», ... «Сделки»: [ObjectId (» ... "), ObjectId (" ... "), ...] }

До сих пор все в порядке, проблема в том, что у нас есть намного больше, чем просто транзакции, например, у нас могут быть: сообщения , запросы и многие другие функции, такие как транзакции, а затем моя коллекция пользователей становится огромной (более 25 "столбцов"). А также, когда я хочу получить набор данных, мне нужно сделать несколько запросов, в отличие от MSSQL, в которых я просто использую оператор Join.

Еще одна проблема заключается в том, что мне придется сэкономить много дополнительных данных, например, для каждой транзакции я должен сохранить идентификатор терминала, а в отчете мне нужно будет показать имя терминала, case (как для моего понимания) У меня есть 2 варианта, один - сделать 2 запроса, а другой - сохранить имя терминала. В реляционной БД это простое соединение.

Так что, возможно, для таких схем, как ours, Mongo (или любая другая база данных на базе DB) - не лучший выбор?

• Я знаю тех, кто новичок вопросы :)
• Мы используем C# для нашей стороны сервера (ASP.Net Web API)

Спасибо заранее!

Answer 1

Вы можете столкнуться с некоторыми серьезными проблемами при моделировании данных с помощью 2-х и 3-х подходов:

1. Для Один ко многим вы можете столкнуться с несогласованностью данных или/и в конечном итоге последовательности. Здесь вы храните внутри документа индекс (массив ссылок) для внешних документов. Итак, для вашего примера, чтобы добавить новую транзакцию, вам нужно два запроса: создать транзакцию и добавить ссылку на пользователя (обновить документ). Mongo DB имеет транзакции ACID только на уровне документа, поэтому для вашего случая приложение по какой-либо причине может создать транзакцию, но не добавляет ее ссылку на пользователя. Это могут быть сбои приложений, сетевые проблемы, ошибки и т. Д. Конечно, вы можете имитировать транзакцию db в приложении с блоком try/catch, делающим очистку данных при возникновении ошибки. Это поможет, но не полностью, потому что приложение может упасть между запросами. Итак, если ваше приложение загружено через некоторое время, вы можете получить некоторое количество транзакций «папа», которые не связаны с каким-либо пользователем. Это не может быть большой проблемой, если ваше приложение не запрашивает транзакции напрямую - только через пользователей, у вас будут только бесполезные данные в db. В противном случае у вас будет несогласованность данных. Чтобы исправить это, вам нужно создать фоновое задание, которое сделает правильную очистку. Таким образом, некоторый период времени ваши данные могут быть непоследовательными - возможная согласованность. Для некоторых приложений это может быть хорошо, а для другого - нет. Та же проблема, с которой вы можете столкнуться при удалении транзакций. Согласен, что документ с 25 массивами ссылок (столбцов) выглядит не очень хорошо. Работа с такими объектами вручную будет сложнее (тестирование, ручные исправления данных и так далее.

2. Один к squillions не влияет на это, но вам нужны индексы эффективны запросы. Для большого и общей БД вы можете иметь плохая производительность.

в общем, я хотел бы сказать, д.б.н. документа довольно хорошо, если ваше приложение работает в основном с одним документом (агрегатной) и не имеет много ссылок на другую документацию, и вы дон Не требуется транзакций между документами. Денормализация также может быть источником несогласованности.

Данные с ключом очень просты в масштабировании. Документ dbs - это на один шаг ближе к хранилищу данных с ключом. Столбцы, ориентированные на столбцы, еще более закрыты для ключевого значения, и поэтому их можно масштабировать еще лучше.

Кроме того, я рекомендую Вам рассмотреть следующие меры для улучшения вашей производительности SQL сервер БД:

1. Caching - возможно, вы можете кэшировать некоторое приложение агрегатов вместо сбора (создание объединений) их в SQL дб все время. Например, Stack Overflow uses SQL Server db and Redis для кэширования агрегатов (вопросы с ответами, комментариями и т. Д.).

2. Настроить выполнение запросов в индексах, структуре db, деморализации и т. Д.

3. Если ваш db размещен в помещении SQL Server, то дополнительная память, SSD-диск, разбиение на таблицы, сжатие данных, репликация могут помочь. Как правило, SQL Server дает хорошую производительность с этими подходами для dbs до 1 ТБ.

4. CQRS approach.

5. Рассмотрите возможность хранения данных приложения в разных базах данных. Каждый тип dbs имеет свои сильные и слабые стороны. Документ DB хорош для хранения агрегатов, SQL db - для реляционных данных и т. Д.В сложных приложениях, как правило, используется несколько типов db.