Мне нужно хранить большие объемы данных измерений в базе данных. Запись состоит из идентификатора, который идентифицирует источник данных, временную метку и значение. Записи впоследствии извлекаются через идентификатор и их метку времени.
Согласно моему предыдущему опыту (я разрабатываю преемника приложения, которое находилось в продуктивном использовании в течение последних пяти лет), дисковый ввод-вывод является важным узким местом производительности для извлечения данных. (См. Также этот мой другой вопрос ).
Поскольку я никогда не ищу отдельные строки, а всегда (возможно, большие) группы строк, которые соответствуют диапазону идентификаторов и временных отметок, довольно очевидная оптимизация, по-видимому, заключается в том, чтобы хранить большие сжатые порции данных которые доступны по гораздо меньшему индексу (например, по номеру дня) и распаковываются и фильтруются на лету приложением.
Что я ищу, так это лучшая стратегия для определения того, какую часть данных поместить в один блок . В идеальном мире каждый пользовательский запрос будет выполняться путем извлечения одного куска данных и использования большей части или всех этих данных. Поэтому я хочу минимизировать количество чанков, которые нужно загружать для каждого запроса, и хочу минимизировать избыточные данные на чанк.
Ниже я опубликую ответ, содержащий мои идеи, и сделаю его достоянием сообщества, чтобы вы могли его расширить. Конечно, если у вас другой подход, опубликуйте свой.
ETA: S. Лотт опубликовал этот ответ ниже, что полезно для обсуждения, даже если я не могу использовать его напрямую (см. Мои комментарии). Дело в том, что «размеры» моих «фактов» находятся (и должны) быть под влиянием конечного пользователя и со временем меняются. Это основная особенность приложения и, собственно, причина, по которой я задумался над этим вопросом.