Правильное проектирование mongodb, какой способ выбрать?

Я бы сделал так:

{
  "ip": "1.2.3.4",
   dat: [
     {
       mac: 'FF:00:FF:00:11:22',
       port: 1,
       vlan: 2
     },
     {
       mac: 'FF:00:FF:11:33:44',
       port: 3,
       vlan: 5
     }
   ]
}

db.col.find({ip:"1.2.3.4","dat.mac":"FF:00:FF:00:11:22"})

Сюда же метод $elemMatch:

db.col.find({dat:{ $elemMatch: {port:1} }})

Но как в таком случае мне найти на каком именно порту сидит мак? Ведь запрос без «проекции» выдаст весь документ целиком, а как бы выглядел нужный мне запрос я найти пока не могу не могу (роюсь сейчас в документации)

Модель №1:

db.devices.find()
{ _id:1, sn: "sn0001", addr:["1.2.3.4","127.0.0.1"]}
{ _id:2, sn: "sn0002", addr:["10.0.0.1"]}

db.ports.find()
{ _id:1, device: ObjectId(1), mac: "11:22:33:44:55:66", vlan: 4, port: 1}
{ _id:2, device: ObjectId(2), mac: "33:33:33:55:55:66", vlan: 5, port: 3}

Модель №2 выше в моем примере.

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

Плюсы 2 модели - простота и атомарность документа.

Ведь запрос без «проекции» выдаст весь документ целиком, а как бы выглядел нужный мне запрос я найти пока не могу не могу (роюсь сейчас в документации)

Срез до первого попавшегося поля: http://docs.mongodb.org/manual/reference/projection/positional/#proj._S_

Только это не поможет, если ты хочешь чтобы было более чем одно совпадение.

db.col.find({"dat.vlan":5}, {"dat.$":1})

Просто ради интереса: а чем не подошла для этой задачи обычная RDBMS?

Да, сделал по этому способу. Только вот чтобы получить ссылку не на документ, а на конкретный массив запросы делаю так:

db.maclist.find({'dat.mac':'90f652410d6b'}, {'ip':1, 'dat.$.mac':1})

Вот тогда оно мне выдает аккуратненкий результат:

{ "_id" : ObjectId("5227a01ee13823298b82803e"), "dat" : [ { "mac" : "90f652410d6b", "vlan" : "100", "port" : "5" } ], "ip" : "10.124.125.35" }
{ "_id" : ObjectId("5227a01fe13823298b828057"), "dat" : [ { "mac" : "90f652410d6b", "vlan" : "100", "port" : "19" } ], "ip" : "10.124.125.147" }
{ "_id" : ObjectId("5227a01fe13823298b828058"), "dat" : [ { "mac" : "90f652410d6b", "vlan" : "100", "port" : "25" } ], "ip" : "10.124.125.148" }
{ "_id" : ObjectId("5227a022e13823298b828088"), "dat" : [ { "mac" : "90f652410d6b", "vlan" : "100", "port" : "Gi1/0/28" } ], "ip" : "10.124.125.224" }

Без $ лепит весь массив целиком. К стати, когда пробовал в своем первом случае делать что-то типа {'ports.$.macvlan.$.mac'} то выдавало ошибку.

Просто ради интереса: а чем не подошла для этой задачи обычная RDBMS?

Применимо к этой задаче монга - это тестовый полигон, чтобы быстрее изучить нюансы использования этой бд. Ну а применимо к RDBMS - не вижу никаких плюсов, что она может дать по сравнению с простым хранением в текстовом документе

Только это не поможет, если ты хочешь чтобы было более чем одно совпадение.

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

Пожалуй лучшим выходом будет использовать дополнительные коллекции с id'ами, т.е. вторую модель.

Я так понимаю пока в монге проблематично оперировать со вложенными в массивы субдокументами.

Монга оперирует на уровне документа. Все суб/под это костыли в моем понимании. Потому что проектировать надо с учетом запросов в отличие от СУБД, где педалит иерархия. Задачи в сабже ты решил, но я же не телепат :)

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