В один момент времени (datetime 8 bytes) с мак-адреса клиента (6 bytes) на мак-адрес точки (6 bytes) поступает сообщение в 1 byte.
Итого размер одного события 8+6+6+1 = 21 byte

У каждой точки есть ряд тегов, не более 10 (всего тегов не более 64к), у точки теги могут меняться, и это должно влиять на старые данные.

Основные запросы: получить все события с дата+время_1 до дата+время_2 с фильтром по определенному тегу или мак-адресу точки, иногда нужна сортировка по времени. Период запрашиваемых данных не выходит за последние 60 дней (хотя поговаривают о 2-х годах)

Кол-во точек не более 100к, кол-во клиентов не ограничено, на каждую точку в день приходит в среднем 70к событий.

Ну и как обычно нужна экономия ресурсов :)

Какую бы вы базу взяли, как хранили бы и какие индексы?

o7412369815963
Ну и как обычно нужна экономия ресурсов :)

Тогда надо вообще без индексов :).
Берете hdf5 делаете по папке внутри файла hdf5 на каждый день. От даты времени вместо 8 байт останется 2-4. Если поток событий более или менее однороден, осуществляем дельта компрессию времени оставим на время бит 10. В каждой “дневной” папке делаете по последовательности по макам точек. Еще 6 байт из сообщения долой. Траты на создание одной последовательности байт 200-300. Выигрыш очевиден. Сообщения естественно упорядочены во времени (если нет то в большинстве случаев решается небольшим кешированием). Следовательно долой индекс. Проще и быстрее захапать всю последовательность в память и выделять куски двоичным поиском. Фильтрация по тегам решается словарем в памяти тег -> множество точек. Или список если теги меняются очень редко. Теперь включаем надежду на наличие корреляций маков клиентов и маков точек и на основе этой надежды включаем компрессию данных (платим за это буферизацией данных в памяти и снижением скорости запросов) и получаем компрессию на диске в 3-10 раз с соответствующим увеличением скорости чтения данных с диска.

Проблема удаления устаревших данных решается вообще элементарно - удалением старых папок.

Это конечно шутка, но аналогичные вещи можно сделать почти в любой субд. Ну в постгресе точно.

doza_and
Тогда надо вообще без индексов :).

Без индексов будет cpu и io тратится

А вообще у меня подобным образом сделано в mongodb, документы собираются за час по точке, все жмется с zlib.
Данные автоматом будут шардится по серверам. :)

Ещё интересно, если нумеровать маки клиентов в пределах “пакета”, будет 2б вмето 6б на событие, или по принципу utf8, 1-2 байта на мак клиента. Даст ли это профит? по сути сжатие должно это покрыть. Так же ещё можно с самим сжатием поиграться. Вообщем есть задел на следующую версию метода хранения.

В итоге индекс весит копейки ~0.015 байт на событие, где-то в 1600 раз меньше чем индекс исходных, а скорость запросов выросла в 10 - 20 раз.

Пакеты по дням экономнее, но могут быть тяжелые когда нужна сортировка, например если по тегу получили 1000 “пакетов” за единицу времени, нужно их распаковать и отсортировать по времени. А разрез по часам - самое то (полегче), тем более что есть запросы “получить за сутки” но но со сдвигом по таймзоне.

o7412369815963
Без индексов будет cpu и io тратится

В том что я изложил индексы вообще есть - они используются когда ищутся объекты в hdf5 директории с данными и последовательности по точке.
Алгоритмы сжатия очень часто не могут допереть как вести сжатие, на них лучше не полагаться когда есть возможность надо самому сделать сжатие.
В обычной реляционной базе и в hdf5 данные будут храниться компактнее чем в монго, поскольку информация о типах вынесена отдельно в заголовок таблицы. Шардинг можно устроить в любой базе.

zlib не лучший выбор. см http://www.oberhumer.com/opensource/lzo/. По возможности надо использовать быстрые алгоритмы компрессии декомпрессии.

Применяемый прием с разбиением таблицы на группы называется секционирование, оно есть у всех баз данных http://habrahabr.ru/post/74984/

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

doza_and
В том что я изложил индексы вообще есть

Да, они везде есть где много данных.

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

Согласен, сейчас на это тратится примерно 0.3%, в принципе не так существенно (плата за удобство, хотя в любой момент можно будет подменить базу), а вот компрессию можно поменять.
Быстрая компрессия не так важна, она будет делаться единоразово, декомпрессия и само сжатие важнее.
вот интересная ссылка.
Думаю попробовать lzma / xz, питон как раз их умеет. 6 сек на распаковку 500М данных - вполне достаточно, зато жмет в 1.5-2 раза лучше. - размен места на cpu, тем более что cpu не всегда загружен, в отличие от занимаемого места.

Пошел новый этап проекта, появились новые хотелки, и появилась необходимость получать данные с фильтром по клиенту.

Из нескольких придуманных вариантов пока остановился на таком:
Сделать новую коллекцию: мак-клиента, время пакета (точнее час), массив ссылок на запаковынные данные (с 1 поста). Т.е. один такой документ будет ссылаться на несколько “пакетов” в конкретном часе, где был замечен мак-клиента.
Таким образом нет дублирования/раздувания данных, есть индекс мак-клиента + время, что позволяет быстро найти данные и сделать шардинг, хотя для этой коллекции шардинг не обязателен, коллекция не должна быть большой.

Кстати появилась идея - таким же образом можно сделать задачу из 1 поста, - оторвать запакованные данные и индексированные данные, причем индексированные можно будет перенести в psql, и можно будет делать хитрые индексы которые не возможны при шардинге, например хранить список тегов в каждой записи, что-б не фильтровать по списку точек, а фильтровать по самому тегу.
:)

o7412369815963
коллекция не должна быть большой.

Рано я сделал вывод, при том что клиентов не ограничено…
А вот над исходной задачей можно ещё подумать.

o7412369815963
при том что клиентов не ограничено…

По клиентам можно рассчитывать на 2 лимита: 10М (и 100М).
На данные момент быстрого получения данных не требуется - построение отчетов в бекграунде, но и сильно медленно не должно быть.

По в голове крутятся идеи, по группировке до дня, делать разрез не маков - а групп маков, например брать 2 байта из 6.
Связывать клиентов не с пакетами, а с точками…
Самое медленное - полный перебор, поэтому нужно как-то оптимально уменьшить объем перебора…

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