Създаване на таблица с много заявки в 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. Колко голям ще расте всеки документ? Ако възнамерявате да добавите динамични инкрементални данни към самия документ, трябва да сте наясно с ограничения като 16MB максимален размер за документ в MongoDB.
  3. Освен това, ако актуализирате един и същ документ от множество нишки/връзки, които могат да бъдат в конфликт помежду си, трябва да помислите малко по-задълбочено как да се справите с паралелността на вашите обекти. MongoDB осигурява атомарна операция върху документ чрез „update“ и условни атомарни актуализации чрез „findAndModify“.
  4. Какви са вашите модели на заявки и мислили ли сте за нефункционални нужди по отношение на производителност и т.н.?
  5. От дефиницията вашите данни изглеждат нещо, което може да има определен живот, възнамерявате ли да изчиствате данните си на периодични интервали (опитвайки се да видите дали TTL индексите биха били полезни тук)?
person aks    schedule 28.01.2014
comment
Всяко устройство може да увеличи своите данни до около 3,1 милиона реда. Планирам периодично да изчиствам и премахвам стари данни на база година по година на други места. Всеки ред от данни ще се счита за документ (който ще има ограничение от 16MB) или цялата таблица ще бъде документ. Колкото и да си мислех, документът е основно ред. Същият ред няма да се актуализира, просто ще хвърля данните в таблицата. Планирам да използвам заявки, базирани на намаляване на картата, и най-често срещаната заявка ще бъде да изведа данни за 43 000 реда (данни за един месец) и да ги анализирам. - person tor9ado; 04.02.2014