Какая база данных подойдет для триллионов записей с индексами?

Question

[v_k]

Посоветуйте пожалуйста базу данных под Debian для триллионов индексированных данных. Желательно чтобы она была бесплатной.

Comments

[v_k]

Данные будут добавляться (без удаления) все поля VARCHAR, частота обращений высокая. Раз в день будет добавление до миллиона новых записей.

[Модератор]

v_k, Для комментирования ответа жмите линк "Комментировать" под ответом
Не нужно писать комментарий в форме для ответа
Оповещения о такой реплике не поступит автору ответа

Не нужно засорять секцию ответов "спасибовсем", "решено" и тп

https://toster.ru/help/rules
3.2

[Иван Шумов]

v_k, фильтр будет?

[v_k]

Иван Шумов, не очень понял про фильтр.

[Иван Шумов]

v_k, никак не указано какие обращения планируются к базе данных

[v_k]

Иван Шумов, выше вроде ответил: добавление примерно по миллиону записей в день, удаления не будет, обращения от 10 тысяч в день.

[Иван Шумов]

v_k, обращения по фильтру или по ключу?

[v_k]

Иван Шумов, по ключу

[Иван Шумов]

v_k, тогда нужно смотреть key-value storage. если тысяч 10 в день то просто поставить хороший ssd и RAID для надежности. выдержит. Redis подойдет, но я за облака

Answer 1

[Vasiliy Goncharenko]

Нужно больше информации о задаче:
1. тип данных: структурированные или нет.
Предполагаю, что структурированные, под RDBMS
2. размер записи (в байтах)
3. кол-во полей в записи
4. типы данных полей (включая поля с переменной длиной)
5. назначение базы (OLTP/OLAP)
6. кол-во индексов и колонки в индексах

Вот, где-то так.
При наличии информации выше можно дать взвешенный ответ.
Иначе получите что-то типа: "Лошадью ходи, лошадью". :)

Удачи.

Comments

[v_k]

1. Объясните пожалуйст в двух словах что значит структурированный тип. Гуглил, но кроме ответа для языков программирования ничего не нашел.
2. 255 байт самая длинная.
3. 3-5 полей.
4. VARCHAR все поля
5. OLTP
6. 1-2 индекс, 1-2 колонки

[v_k]

v_k, еще погуглил. Наверное, все-таки простые данные.

Answer 2

[p2rcoder]

если речь о каких-то таймсериях, то быстрее всего работает и занимает меньше места ClickHouse

Answer 3

[Иван Шумов]

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

Comments

[Иван Шумов]

Иван, если ты сейчас про горизонтальное масштабирование SQL решений то партиции себя в своей архитектуре плохо показали уже) есть только одно решение из SQL, которое мне действительно нравится в масштабировании, но оно есть только в AWS и это Aurora

[Иван Шумов]

Иван, да) дисковая репликация и логика на уровне дискового хранилица, а не мастера

[Vitaly Karasik]

ИМХО, чересчур категорично.
Зависит от архитектуры, аппликации и т.п.
Старые добрые реляционные базы вполне работают в FB, GitHub и многих других местах.

[Иван Шумов]

Vitaly Karasik, только там и инженеров, которые это тянут не полторы штуки

Answer 4

[grinat]

Обычного постгре хватит. Можешь спокойно сгенерить датасет(https://postgrespro.ru/docs/postgrespro/9.5/functi... и потестить скорость выборки и чтения, много времени это не займет.