2016-03-24 4 views
0

Использование MongoDB 2.4 с драйвером mongoDB .NET 3.2MongoDB Количество миллионов строк очень медленно

У меня есть коллекция с 30 миллионами записей.

var visits = new MongoHelper<CampaignVisitLog>() 
     .GetCollection().AsQueryable().Count(t => t.campaignId == campaignId); 

campaignId индексируется. В зависимости от многих кампаний в кампаниях, для возврата счетчика потребуется от 30 секунд до нескольких минут.

Каков правильный способ подсчета этой коллекции?

+1

Как быстро, если вы запрашиваете коллекцию монго напрямую, без водителя? – Liam

+0

Граф с предсказанием в nosql является уродливым. Попробуйте обновить mongodb, также я не видел обновления, связанные с производительностью счетчика, но это может помочь. –

+0

@liam: запрос в коллекции mongo напрямую очень медленный, и я ждал очень долгое время. и, наконец, когда результат пришел, я даже не получил счет. Он только что вернулся «true» (mongo studio management) запрос, которым я бежал, был: db.campaignvisitlog.count ({campaignid: 5}) – Joakim

ответ

1

У меня есть коллекция с 30 миллионами записей.

Независимо от оптимизации всего запроса, вы не можете думать, что получите быстрые ответы с миллионами предметов.

Если вы выполняете другие запросы, чтобы получить статистику, может быть, это время, чтобы запланировать эти расчеты и сделать их с некоторой асинхронной службой (т.е. службой Windows,, Windows, запланированные задачи, Quartz.NET. ..), и получить их результаты также асинхронно.

Вы можете использовать MongoDB для хранения результатов обслуживания вашего расчета или перейти на более конкретное решение: в службы шины (т.е. RabbitMQ, Azure Service Bus, NServiceBus ...).

+0

У меня есть те же данные в MSSQL, и я очень быстро их подсчитываю. Я просто проверяю, является ли mongoDb хорошим вариантом для хранения больших наборов данных с такими данными журнала, но похоже, что это не так? – Joakim

+0

@Joakim Счет в SQL оптимизирован совершенно по-другому.Mongo не обязательно быстрее, чем SQL, это неструктурированное хранилище данных документов, а не реляционная база данных. Если основной причиной использования монго является * «потому что это быстрее» *, вы можете обнаружить, что разочарованы. Это может быть быстрее, а это не так, это зависит от того, что вы делаете с ним и как вы храните данные. ** TL; DR Mongo - это не SQL, но быстрее ** – Liam

+0

По моему опыту в отношении финансов вы должны придерживаться, но кроме этого монго это хорошо, особенно для ведения журнала. Если вам нужна сумма, считайте stick с sql. Но если вы хотите, чтобы db для loggin придерживался nosql. –

0

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

https://docs.mongodb.org/manual/tutorial/ensure-indexes-fit-ram/

+0

Это комментарий, а не ответ –

+0

Что случилось с короткими ответами, если они правы? – MementoMori

+0

Увидимся, вы сказали * обеспечить *, и вы просто предоставляете ссылку. Это может быть комментарий, и позже OP может обсудить с вами, если это проблема или нет. –

0

MongoDB C# водитель болен.

Запросы LINQ всегда переводятся в конвейерные схемы агрегации.

var pipeline = [ { "$group" : { "_id" : 1, "__result" : { "$sum" : 1 } } }] 
db.test.aggregate(pipeline) 

Это приводит к полной проверке коллекции на сервере, поскольку в запросе LINQ не указаны какие-либо ограничения.

Смежные вопросы