Создание таблицы с большим количеством запросов в MongoDB динамически (из кода) в Python Django или SubDocuments, какой из них?

Я собираюсь создать службу GPS-слежения, используя Django, Python и MongoDB. Таблицы/документы транспортных средств будут создаваться динамически при активации, в них будут храниться данные GPS, поступающие с устройств через TCP-соединение (приблизительно мы сохраним емкость для 10000~100000 устройств, отправляющих данные в минуту) с использованием Twisted Framework. Поэтому в сложившихся обстоятельствах я хотел знать, стоит ли динамически создавать этот документ. Если можно, подскажите схему. Я предлагаю один здесь:

class Device_<id>(Document):
  time_of_data = DateTimeField()
  location = GeoPointField()
  speed = DecimalField()
  bearing = DecimalField()
  sensor = StringField()

class DeviceOwner(Document):
  user = ReferenceField(User)
  device = StringField() #This will store the name of the Device_<id>

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

class Device(Document):
  user = ReferenceField(User)
  name = StringField()

class DeviceData(Document):
  time_of_data = DateTimeField()
  location = GeoPointField()
  speed = DecimalField()
  bearing = DecimalField()
  sensor = StringField()
  device = ReferenceField(Device)

*Новое изменение* от 4 февраля:

Другой возможный дизайн таблицы, который я рассматриваю, заключается в том, что loc в основном представляет собой данные BSON.SON(), содержащие значения «x» и «y»:

    device_locations = {"device":device[0]["_id"], 
      "locations":{
      "time":datetime.now(),
      "loc":loc,
      "status":"A",
      "engine_sensor":True,
      "ac_sensor":True,
      "temperature_sensor":0.0,
      "door1_sensor":False,
      "door2_sensor":False,
      "door3_sensor":False,
      "door4_sensor":False,
       },
      "active":True, 
      "created_on":datetime.datetime.now(),
      "modified_on":datetime.datetime.now(),
      "created_by":user,
      "modified_by":user
     }

Другой вариант - иметь отдельную коллекцию для каждого устройства (кстати, если приведенный ниже код является представлением этого или нет):

    device_locations = {
      "%s"%device[0]["_id"]:{
         "time":datetime.now(),
         "loc":loc,
          "status":"A",
          "engine_sensor":True,
         "ac_sensor":True,
         "temperature_sensor":0.0,
         "door1_sensor":False,
         "door2_sensor":False,
         "door3_sensor":False,
         "door4_sensor":False,
       },
      "active":True, 
      "created_on":datetime.datetime.now(),
      "modified_on":datetime.datetime.now(),
      "created_by":user,
      "modified_by":user
     }

person tor9ado    schedule 28.01.2014    source источник
comment
Я думаю, что этот вопрос связан с тем, какие запросы вы хотите выполнять в этой коллекции. Также я использовал mongoengine в своей программе, и у меня уродливая производительность. После того, как я переписал все на чистом pymongo, программа стала примерно в 100-1000 раз быстрее. Поэтому, если у вас будет большая пропускная способность, я думаю, вам следует использовать pymongo   -  person Denis Nikanorov    schedule 29.01.2014
comment
Я изменил идею использовать pymongo напрямую. Это очень помогает в эффективном запросе. Спасибо за комментарий.   -  person tor9ado    schedule 04.02.2014


Ответы (1)


Несколько моментов:

  1. Индексация работает с вложенными документами и связанными с ними полями.
  2. Насколько большим будет каждый документ? Если вы собираетесь добавлять динамические добавочные данные в сам документ, вы должны знать об ограничениях, таких как максимальный размер 16 МБ для документа в MongoDB.
  3. Кроме того, если вы обновляете один и тот же документ из нескольких потоков/соединений, которые могут конфликтовать друг с другом, вам нужно немного глубже подумать о том, как обрабатывать параллелизм на ваших объектах. MongoDB обеспечивает атомарную операцию над документом через «обновление» и условные атомарные обновления через «findAndModify».
  4. Каковы ваши шаблоны запросов и думали ли вы о нефункциональных потребностях с точки зрения производительности и т. д.?
  5. Из определения ваши данные кажутся чем-то, что может иметь определенный срок службы, собираетесь ли вы очищать свои данные через определенные промежутки времени (пытаясь увидеть, будут ли здесь полезны индексы TTL)?
person aks    schedule 28.01.2014
comment
Каждое устройство может увеличить свои данные примерно до 3,1 миллиона строк. Я планирую периодически очищать и удалять старые данные из года в год в другие места. Будет ли каждая строка данных рассматриваться как документ (который будет иметь ограничение в 16 МБ) или вся таблица будет документом. Насколько я думал, документ в основном представляет собой строку. Эта же строка не будет обновляться, я просто закину данные в таблицу. Я планирую использовать запросы на основе уменьшения карты, и наиболее распространенным запросом будет получение данных для 43000 строк (данные за месяц) и их анализ. - person tor9ado; 04.02.2014