Документы MongoDB соседних массивов и словарей

Question

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

В настоящее время я использую MySQL, но запрашивая его немного громоздким (немного медленно из-за JOINS) и хранения довольно раздутой, поэтому я изменил табличную структуру данных из

2014-10-13T08:28:35.570+0200 | 192.168.5.5 | A | 72.21.210.52 | device-metrics-us.amazon.com 

2014-10-13T08:28:44.522+0200 | 192.168.5.9 | CNAME | googleapis.l.google.com | www.googleapis.com 
2014-10-13T08:28:44.522+0200 | 192.168.5.9 | A | 74.125.29.95 | googleapis.l.google.com 

2014-10-13T08:28:45.618+0200 | 192.168.5.5 | CNAME | android.l.google.com | android.clients.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.160 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.165 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.166 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.168 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.162 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.169 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.163 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.164 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.174 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.161 | android.l.google.com 
2014-10-13T08:28:45.618+0200 | 192.168.5.5 | A | 74.125.226.167 | android.l.google.com 

к NoSQL-формате

["2014-10-13T08:28:35.570+0200", "Mon 08:28", "192.168.5.5", ["device-metrics-us.amazon.com"], ["72.21.210.52"]], 
["2014-10-13T08:28:44.522+0200", "Mon 08:28", "192.168.5.9", ["www.googleapis.com", "googleapis.l.google.com"], ["74.125.29.95"]], 
["2014-10-13T08:28:45.618+0200", "Mon 08:28", "192.168.5.5", ["android.clients.google.com", "android.l.google.com"], ["74.125.226.160", "74.125.226.165", "74.125.226.166", "74.125.226.168", "74.125.226.162", "74.125.226.169", "74.125.226.163", "74.125.226.164", "74.125.226.174", "74.125.226.161", "74.125.226.167"]], 

Я получил эти фиксированные показатели:

0: временную метку,

1: более читаемая метка время

2: источник запроса

3: массив, где первый элемент является запрашиваемым именем DNS, и последующие элементы CNAMEs

4: массив возвращенные IP-адреса

Поскольку все эти материалы также будут храниться в памяти, и структура не изменится, я подумал, что пропущу ключи, чтобы сохранить ОЗУ (сервер хранения уже максимизирует использование ОЗУ).

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

{"timestamp": "2014-10-13T08:28:35.570+0200", "nice": "Mon 08:28", "ip": "192.168.5.5", "query":["device-metrics-us.amazon.com"], "result":["72.21.210.52"]}, 

Я действительно предпочитаю иметь исходные массивы.

Я буду часто запрашивая для IP-адреса в списке результатов, и ожидать, чтобы получить первоначальный запрос, как следствие, ограничение по времени и устройства (ОТН и 2-го поля)

В настоящее время, я планируя использовать MongoDB.

Какие-либо рекомендации в отношении формата данных для максимальной эффективности (ОЗУ и скорости) и запросов?

Answer 1

Я пишу некоторые комментарии здесь только для справки:

• Массив BSON фактически структура документа (другой тип данных, конечно). Например, [1, 2, 3] == {"0":1, "1":1, "2":3}BSON spec;
• Индекс создается с помощью ключа (ов), используя определенный ключ для узкого диапазона данных, который помогает улучшить производительность запросов. Так что с ключом необходимо для вашей структуры.
• Как вы хотите экономить память чрезвычайно, создайте ключи с одним символом для каждого.

Таким образом, структура вашего обеспечивают

{"timestamp": "2014-10-13T08:28:35.570+0200", "nice": "Mon 08:28", "ip": "192.168.5.5", "query":["device-metrics-us.amazon.com"], "result":["72.21.210.52"]} 

лучше и лучше.