posgresql compressed database

Навскидку - завести базу на ФС, которая умеет в компрессию. Но мне почему-то кажется, что это под pg будет не очень оптимально.

Вариант с ФС, на самом деле, не так уж и плох, вполне может сработать.

Постгрес умеет в нативное сжатие данных, но с оговорками https://www.postgresql.org/docs/current/storage-toast.html Возможно для того, чтобы это заработало придется переделывать структуру БД.

в постгресе никак

смотри greenplum

Какие данные и почему ты уверен, что тебе нужен postgres?

Мне нужно под большое кол-во цифр. Работать буду с djangorest. Есть что-то лучше под эти нужды, чтобы там было сжатие данных?

юзай key-value БД типа ardb

Купить железа?

«нету денег - нехер строить.»

Postgreql и вправду жрет место как не в себя. И захлебывается bloat'ом своих индексов. Как результат - больше таблицы требуют регулярного и дорогого обслуживания

А что кстати за данные? С чего их много, но срочно не нужны.

Может какой овер-инжиниринг закрался. Может не место там sql? Rrdb и вся любовь

Данных много, скорость не важна. Нужно компактное хранение. Как это реализовать?

В реляционных базах не строить индексов, не создавать primary key колонок, индексы много места занимают. Как сжато хранить не подскажу.

большое кол-во цифр

Это мало о чём говорит, без конкретики невозможно тебе что-то адекватно советовать. И «большое» количесво — это сколько? Миллионы, сотни миллионов, миллиарды записей?

Ну и важны не только данные, но и юзкейсы. Будут ли данные часто изменяться, или БД только под запись и выборки?

djangorest

Это варианты сильно сужает. Я бы на твоём месте плясал не от ORM, а от задач и той БД, что их лучше решает.

Нужно компактное хранение.

Скорее всего, не нужно.

скорость не важна. Нужно компактное хранение

https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engine.html - всё как ты хочешь, сжато и медленно.

Если скорость _действительно_ не важна, может, поизвращаться с SQLite + squashfs?

чем sqlite отличается от другой подобной бд.

Вопрос не относится к теме. Но SQLite простая и маленькая по размеру дистрибутива реляционная СУБД, поэтому хорошо подходит для слабых устройств (даже для телефонов) и для встраивания в свою программу. Плохо подходит для многопользователькой работы, Сжатие данных, если кого интересует, хуже чем в PostgreSQL(вряд ли оно на самом деле нужно автору темы, но мне отсюда плохо видно). PostgreSQL - самая мощная бесплатная реляционная СУБД. Подходит для важных многопользовательских проектов,

Что значит много ? 30 Гб в минуту ?
Или канал к БД 2g поэтому скорость не важна ?

Большой объем и низкая скорость - это взаимоисключающие параметры, потому что на низкой скорости
а) большой объем не записать
б) большой объем не обработать, т.е. запрос будет выполняться сутки или месяц

или компактное хранение - это ограничение носителя 1.44 Мб ?

Скорость - это имеется ввиду скорость распаковки данных при селекте

В общем хотелки такие:

1. интеграция бд с djangorest
2. возможность сжатия данных
3. sql

Ты дейтсвительно настолько беспросветное нубьё, что не понимаешь, что базы данных совсем разные бывают? Без конкретики никто ничего адекватного не посоветует, ещё раз тебе повторяю. Выпиши все БД, что сможешь нагуглить, наклей нарулетку и покрути, результат будет тем же.

Какая тебе конкретика нужна, гуру? Тебе говорят, что сжатие нужно данных, чтобы вместо 120гб занимало меньше и что данные - числа. Окей, конкретизирую конкретно для тебя, не просто числа, а float.

Какая тебе конкретика нужна

Ну и важны не только данные, но и юзкейсы. Будут ли данные часто изменяться, или БД только под запись и выборки?

Что здесь не ясно-то, а?

Это какой-то адовый тупак. Пиши в CSV и жми lzma.

под запись и выборки. Данные статичные

Vertica: 10х сжатие данных, SQL, jdbc присутствует.

Почему не key-value? https://github.com/ideawu/ssdb