Database Reference
In-Depth Information
two
strings
that represent dates. The same issue holds for numeric fields; storing numbers as
strings requires more space and is more difficult to query.
Consider the following document that captures all data from the log entry:
{
_id
:
ObjectId
(...),
host
:
"127.0.0.1"
,
logname
:
null
null
,
user
:
'frank'
,
time
:
ISODate
(
"2000-10-10T20:55:36Z"
),
request
:
"GET /apache_pb.gif HTTP/1.0"
,
status
:
200
,
response_size
:
2326
,
referrer
:
"[http://www.example.com/start.html](http://www.example.com/..."
,
user_agent
:
"Mozilla/4.08 [en] (Win98; I ;Nav)"
}
The is better, but it's quite a large document. When extracting data from logs and designing
a schema, you should also consider what information you can omit from your log tracking
system. In most cases, there's no need to track
all
data from an event log. To continue this ex-
ample, here the most crucial information may be the host, time, path, user agent, and referrer,
as in the following example document:
{
_id
:
ObjectId
(...),
host
:
"127.0.0.1"
,
time
:
ISODate
(
"2000-10-10T20:55:36Z"
),
path
:
"/apache_pb.gif"
,
referer
:
"[http://www.example.com/start.html](http://www.example.com/..."
,
user_agent
:
"Mozilla/4.08 [en] (Win98; I ;Nav)"
}
Depending on your storage and memory requirements, you might even consider omitting ex-
plicit time fields, since the BSON
ObjectId
implicitly embeds its own creation time:
{
_id
:
ObjectId
(
'...'
),
host
:
"127.0.0.1"
,
path
:
"/apache_pb.gif"
,
referer
:
"[http://www.example.com/start.html](http://www.example.com/..."
,
