lega

Скорость ssd до 550Mb/sec, если события по 20б, то можете по файликам разливать ~27 млн событий в сек (одного канала не хватит чтобы нагрузить)

Выборка событий будет происходить с использованием фильтров по полям в среднем раз в секунду.

Разливайте в "доль" фильтров и будет норм.

1 - встречалось в поле properties 350 раз
2 - встречалось в поле properties 100 раз

Для этого можно держать кеш: {_id: 1, count: 350}

db.collect.find({"properties": {$all:[1]}})
Когда элемент один, лучше так:
db.collect.find({"properties": 1})

Но для seek он каждый раз делает его не от текущего места а от начала файла

seek просто задает адрес и не делает io операций, поэтому это не влияет.

Скорее всего SSD тормозной, можете проверить его тулзами. Так же когда вы считываете всего 100 байт, с самого девайса считывается минимальный блок (4кб, 16кб, ...)

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

Вариантов много, зависит от того как вы будете использовать данные.
Например если сессия закрывается, то переносить её с прошлого месяца в текущий (в ид сессии зашит месяц старта).

Ещё можно хранить события (а не период), тогда можно данные "резать" хоть по дням/по часам, например так:
session_id, event, datetime
12345, 'start_session', 2015-09-15
12345, 'finish_session', 2015-10-15

https://www.freebase.com/

Можно попробовать sphinxsearch (или эластик), он ищет с сортировкой по релевантности, т.е. сверху будут наибольшие пересечения ключей, но он может сильно задуматься если там много пересечений.
Либо попробовать сделать обратный индекс с сортировпнными сайтами, за один проход вычислять пересечение по сайту, все сайты раскидать по нодам, результат скидывать в БД для сортировки.

Сколько в среднем ключей у сайта?

В вашем случае наверно самым оптимальным будет параллельное вычерпывание сортированных данных (по одному проходу по каждому серверу и одной записи на каждую строку), если % пересечений высок.

А вообще почему не сделать шардинг?, сделать индекс (например) по 3-м полям и заливать данные в нужные сервера (типа всех alex на 1 сервер, max на 2-ой), что-б не было пересечений, таким образом данные мержить не нужно будет + экономия памяти.
Так же непонятно наличие мастер базы, вполне возможно её можно было избежать.

Можно взять MongoDB, плюсы такие:
* При большой нагрузке или объеме можно будет данные разлить по шардингу. Это так же может помочь сэкономить, например можно вместо одного сервера DO за $480 можно взять 24 минимальных виртуалки за $120, + будет больше ядер и трафика.
* Можно хранить доп. параметры, теги, (атрибутивную информацию) и прочее вместе с файлом, таким образом тайл и все с ним связанное будет в одном блоке данных, в отличие от применения *sql. Это хорошо для производительности, т.к. меньше индексов и меньше обращений к ФС.
* Можно сделать доп. индексы
* Можно использовать гео-индексы, выборка тайлов по радиусу и т.п.
* Так же для данной задачи (вполне возможно) достаточно атомарных комитов, они лучше по производительности чем полноценные транзакции.

Я делал примерно так:
Каждый час я формировал чанки с несколькими разрезами, в вашем случае можно взять например "дата время" и "номер рекламного места" (зависит от запросов), в итоге 1 "колонка" "исчезнет", вместо даты можно хранить diff от начала часа.
Чанки максимально сжимались и разливались по шардингу.
В результате хранимый объем был в 5-10 раз меньше исходного.

Формирование отчета: Сервис на питоне, из БД за период доставались чанки, распаковывались передавались в расширение на C который обсчитывал и возвращал результат.
По скорости выходило примерно 250 млн "событий" доставались и обсчитывались за 2-4 сек на одном ядре виртуалки от DO.

Каждый час (период времени) для каждого отчета формировались результаты/кешы во всех разрезах - это позволило выдавать результаты клиентам моментально. Весили они мало если сравнивать с весом исходных данных.

Т.е. каждый час формировались свежие данные, но кроме этого ещё были реал-тайм отчеты - копия входного потока уходила на этот сервер который "считал цифры" и обнулял их каждый час.

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

Если список ключевых слов не большой то можно сделать индексированный массив в документах и туда помещать эти ключевые слова (или их идентификаторы).
В противном случае использовать sphinx/elasticsearch. Можно так же использовать text index из mongoDB, но он мне показался через чур прожорливым.

попробовал сделать выборку через Matches

При этом происходит перебор и проверка всех документов, поэтому это так долго.