ежедневно имеется достаточно большой объём данных, содержащий в себе, пользователей и некоторые их характеристики (числовые, текстовые и пр.). Характеристики ежедневно меняются, сами пользователи также имею свойство смены имени или фамилии. Суть задачи в том, чтобы проанализировать все изменения для разработки различного рода отчетов. Так как ежедневно все эти данные и изменения необходимо фиксировать, встаёт вопрос каким образом хранить эти данные?
Желательно, чтобы хранение данных было без сторонних программ, но выслушаю различные варианты.
библотека sqlite, или no-sql если данные разнобразны или что еще подходящая под твои данные.
или костылить свой велосипед на основе кучи алгоритмов сериализации данных.
минус своего велосипеда - выпиливать ошибки необходимо будет самому.
Александр,
Чудес в реальном мире не бывает, поэтому чем больше вы храните информации тем медленнее будет ее обработка.
Вы как аналитик должны понимать, что требование "достаточно быстро"- звучит крайне непрофессионально, тем более без детального описания конкретных алгоритмов ее обработки. Кроме того, вопрос даже не в количестве строк, а в совокупном объеме информации.
Вообще-то 100 млн записей для любой профессиональной СУБД - это не сверхзадача. Можно смотреть технические характеристики и решать. Обойтись при таких объемах "без сторонних программ" при более-менее серьезной обработке информации - очень самоуверенно. И точно - быстрее не будет.
Хранить можно запросто и в SQLite. Но для аналитики / OLAP она плохо подходит.
Однако, имеется вариант SQLite, оптимизированный для аналитики: DuckDB — SQLite for Data Analysis.
Для хранения большого объема архивных данных, по которым нужно будет строить аналитику, используйте ClickHouse. Данная БД позволяет обрабатывать огромные объемы данных (более 1 млрд) достаточно быстро. Но вам нужен соответствующий сервер, с не менее, чем 8-16GB оперативной памяти и достаточно большим жестким диском.
Maxim Siomin, тогда это несерьёзно и кликхауз - оверкилл. У меня постгрес на стандратных настройках мгновенно прожёвывал запросы к таблице с 23 миллиардами строк.
Сергей Горностаев, а какого рода запросы? Если простые селекты, то возможно. Но вот сложные запросы, с подзапросами, с 10+ джойнами и группировками - это навряд ли. А вот КХ потянет.
Простой
