Я оцениваю варианты эффективного хранения данных в Java. Набор данных представляет собой значения данных с меткой времени и именованным первичным ключом. например,
Name: A|B|C:D
Value: 124
TimeStamp: 01/06/2009 08:24:39,223
Может быть цена акций в определенный момент времени, так что, я полагаю, это классический шаблон данных временных рядов. Однако мне действительно нужно общее решение для СУБД, которое будет работать с любой разумной JDBC-совместимой базой данных, поскольку я хотел бы использовать Hibernate. Следовательно, расширения временных рядов для таких баз данных, как Oracle, на самом деле не вариант, так как я бы хотел, чтобы разработчик мог использовать свою собственную базу данных с поддержкой JDBC / Hibernate.
Проблема здесь заключается в огромном объеме данных, которые могут накапливаться за короткий промежуток времени. До сих пор мои реализации были сосредоточены на определении периодических сводных и чистящих графиков, где необработанные данные агрегируются в таблицы DAY, WEEK, MONTH и т. Д., Но недостатком является ранняя потеря гранулярности и небольшое неудобство несовпадений периодов между периодами, хранящимися в разных агрегаты.
Задача имеет ограниченные возможности, поскольку существует абсолютный предел того, сколько данных может быть физически сжато при сохранении исходной гранулярности данных, и этот предел усугубляется директивой об использовании реляционной базы данных и универсального JDBC, способного один в этом.
Заимствуя концептуальную концепцию из классических алгоритмов сжатия данных и используя тот факт, что многие последовательные значения для одного и того же именованного ключа могут быть идентичными, мне интересно, если есть способ, которым я могу плавно уменьшить количество хранимых записей путем объединения повторяя значения в одну логическую строку, сохраняя при этом счетчик, который фактически указывает, что «следующие n записи имеют одинаковое значение». Реализация всего этого кажется достаточно простой, но компромисс в том, что модель данных теперь ужасно сложна для запроса с использованием стандартного SQL, особенно при использовании любого вида агрегатных функций SQL. Это значительно снижает полезность хранилища данных, поскольку только сложный пользовательский код может восстановить данные обратно в «распакованное» состояние, что приводит к несоответствию импеданса сотням инструментов, которые не смогут правильно обработать эти данные.
Я рассмотрел возможность определения пользовательских типов Hibernate, которые в основном "понимали бы" сжатый набор данных, создавали его и возвращали результаты запроса с динамически созданными синтетическими строками. (База данных будет доступна только для всех клиентов, кроме строго контролируемого потока ввода). Некоторые из инструментов, которые я имел в виду, будут интегрироваться с Hibernate / POJOS в дополнение к сырому JDBC (например, JasperReports), но это на самом деле не решает проблему с агрегатными функциями и, вероятно, также имеет кучу других проблем.
Таким образом, я отчасти смиряюсь с тем, что мне, возможно, придется использовать более проприетарное хранилище данных [возможно, не-SQL] (любые предложения приветствуются), а затем сосредоточиться на, возможно, менее сложной задаче написания псевдо-драйвера JDBC, по крайней мере, облегчить интеграцию с внешними инструментами.
Я слышал ссылку на нечто, называемое " битовый файл ", в качестве механизма для достижения этого сжатия данных, но я не знаю ни одной базы данных, которая обеспечивает это, и последнее, что я хочу сделать ( или может сделать, действительно ....) это написать свою собственную базу данных.
Есть предложения или идеи?