2016-07-25 3 views
0

У меня есть те же данные из около 30 миллионов записей, сохраненных в таблице SQL Server и коллекции MongoDB. Ниже приведен пример записи, я также установил те же индексы. Ниже приведены запросы для возврата одних и тех же данных, один в SQL, другой в mongo. SQL-запрос занимает 2 секунды для вычисления и возврата, mongo с другой стороны занимает 50. Любые идеи, почему mongo намного медленнее, чем SQL?MongoDB медленнее, чем SQL Server

SQL

SELECT 
    COUNT(DISTINCT IP) AS Count, 
    DATEPART(dy, datetime) 
FROM 
    collection 
GROUP BY 
    DATEPART(dy, datetime) 

MONGO

db.collection.aggregate([{$group:{ "_id": { $dayOfYear:"$datetime" }, IP: { $addToSet: "$IP"} }},{$unwind:"$IP"},{$group:{ _id: "$_id", count: { $sum:1} }}]) 

Образец документа, существует около 30 миллионов точно такие же данные в обоих

{ 
    "_id" : ObjectId("57968ebc7391bb1f7c2f4801"), 
    "IP" : "127.0.0.1", 
    "userAgent" : "Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+LCTE;+rv:11.0)+like+Gecko", 
    "Country" : null, 
    "datetime" : ISODate("2016-07-25T16:50:18-05:00"), 
    "proxy" : null, 
    "url" : "/records/archives/archivesdb/deathcertificates/", 
    "HTTPStatus" : "302", 
    "HTTPResponseTime" : "218" 
} 

EDIT: добавлено объяснение как запросы

MONGO

{ 
    "waitedMS" : NumberLong(0), 
    "stages" : [ 
     { 
      "$cursor" : { 
       "query" : { 

       }, 
       "fields" : { 
        "IP" : 1, 
        "datetime" : 1, 
        "_id" : 0 
       }, 
       "queryPlanner" : { 
        "plannerVersion" : 1, 
        "namespace" : "IISLogs.pubprdweb01", 
        "indexFilterSet" : false, 
        "parsedQuery" : { 
         "$and" : [ ] 
        }, 
        "winningPlan" : { 
         "stage" : "COLLSCAN", 
         "filter" : { 
          "$and" : [ ] 
         }, 
         "direction" : "forward" 
        }, 
        "rejectedPlans" : [ ] 
       } 
      } 
     }, 
     { 
      "$group" : { 
       "_id" : { 
        "$dayOfYear" : [ 
         "$datetime" 
        ] 
       }, 
       "IP" : { 
        "$addToSet" : "$IP" 
       } 
      } 
     }, 
     { 
      "$unwind" : { 
       "path" : "$IP" 
      } 
     }, 
     { 
      "$group" : { 
       "_id" : "$_id", 
       "count" : { 
        "$sum" : { 
         "$const" : 1 
        } 
       } 
      } 
     } 
    ], 
    "ok" : 1 
} 

SQL Server не имеют права доступа к ней, так как я не DBA или что-нибудь, но она работает достаточно быстро, что я не слишком заботится о своем плане выполнения хлопотно вещь для меня является то, что монго использует FETCH

+1

Не могли бы вы опубликовать планы выполнения для mysql и mongo? – mszymborski

+0

AFAIK, MongoDB - это NoSQL, и эти механизмы базы данных предназначены для баз данных BigData и Non-Relational. Это может быть результатом. Мне интересно узнать, что ответ тоже :) – FLICKER

+0

Я обновил вопрос, чтобы включить план выполнения для монго, я согласен, что если Mongo делает это долго, чтобы что-то делать, что SQL не занимало времени, должно быть, должно быть что-то настроено неправильно, потому что, как вы сказали, он предназначен для обработки больших данных больше по SQL –

ответ

2

MongoDB версия медленно, потому что $groupcan't use an index (о чем свидетельствует "COLLSCAN" в плане запроса), так что все 30 миллионов документы должны быть считаны в память и запустить через трубопровод.

Этот тип запроса в реальном времени (вычисление итоговых данных из всех документов) просто не подходит для MongoDB. Было бы лучше периодически запускать ваш aggregate с помощью этапа $out (или использовать сокращение карты), чтобы генерировать сводные данные из основной коллекции, а затем запрашивать итоговую итоговую коллекцию.

+0

Так вот в чем ошибка монго? Так как он не может использовать индекс в группе? Но все же sql занял всего пару секунд, а также пришлось сканировать всю таблицу, так что в чем смысл использовать монго? –

+0

@BrandonTomblinson Смотрите мое обновление. – JohnnyHK

+0

Это не обязательно должно быть сокращение карты. Добавление простой стадии «$ out» вполне может служить той же цели лучше. –

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