Mongodb Проблема с производительностью

Question

Я использую mongodb, и мне нужно обновить свои документы, скажем, всего 1000. Мой документ имеет базовую структуру, как:

{ 
People:[1,2,3,4], 
Place:"Auckland" 
Event:"Music Show" 
} 

У меня есть 10 000 потоков, работающих одновременно в другой виртуальной машине. Каждый поток ищет эти документы (1000), посмотрите, соответствуют ли эти 1000 документов запросу и нажимают число в массиве People. Предположим, что если поток 100 нашел, что 500 из этих 1000 документов имеют отношение к делу, то он подталкивает число 100 в массиве People из всех 500 документов. Для этого

Я использую для каждого потока (10000) команд

update.append("$push",new BasicDBObject("People",serial_number)); 
updateMulti(query,update); 

Я наблюдаю плохую производительность этих обновлений в месте (мульти-запрос). Это проблема из-за блокировки записи? Каждый поток (10000) обновляет документ, относящийся к запросу? - так кажется, есть много «ожидания» Есть ли более эффективный способ выполнения этих «push» операций? Действительно ли «UpdateMulti» подходит для этого?

Th AnK за большой ответ - редактирование и добавление больше информации

Некоторого дизайн:

Да ваше чтение нашей проблемы является правильным. У нас есть 10000 потоков, каждый из которых представляет один «актер», обновляющий до 1000 объектов (на основе соответствующего запроса) за один раз с помощью $ push.

Инвертирование модели приводит нас к нескольким сломанным пользователям (с точки зрения нашего домена), что приводит нас к объединению «состояний» первичной сущности (которая теперь будет распространена во многих коллекциях) - ex: каждое из этих действий изменение состояния для этого объекта - E имеет состояния (e1, e2, e3, e4, e5). Таким образом, e1-e5 представляется как совокупный массив, который обновляется 10 000 потоков/процессов, которые представляют действия внешних приложений.

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

Что должно быть «идеальной» стратегией дизайна в таком случае - ускорить запись. Будет ли ошпаривать помощь - есть ли эвристика «величины» для этого - при какой блокировке% мы должны осколки и т. Д.

Answer 1

Это проблема из-за конструкции схемы.

Это крайне неэффективно для $push нескольких значений для нескольких документов, особенно из нескольких потоков. Это не так, что проблема блокировки записи - это то, что ваш дизайн стал проблемой. Кроме того, вы постоянно расширяете документы, что означает, что обновления не «на месте», и ваша коллекция быстро становится фрагментированной.

Кажется, что ваша схема «перевернута». У вас есть 10 000 потоков, которые хотят добавить числа, представляющие людей (я предполагаю, что очень много людей) к небольшому числу документов (1000), которые будут расти огромными. Мне кажется, что если вы хотите что-то внедрить во что-то еще, вы можете рассмотреть коллекции, представляющие людей, а затем встраивать события, в которые эти люди находятся, по крайней мере, тогда вы ограничиваете размер массива для каждого человека до 1000 максимум , а обновления будут распространяться на гораздо большее количество документов, что значительно сократит количество конфликтов.

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