Как постгрес работает с большим количеством данных?

В результате получится что-то вроде десятков/пары сотен таблиц с сотнями миллионов строк (результаты хранятся в течение ограниченного времени, по истечении которого будут удаляться).

Можно взлететь практически на любой бд.

Надо планировать workflow так, чтобы удалять таблицы целиком (TRUNCATE или DROP), а не с DELETE FROM xxx WHERE yyy.

В такой схеме будет нормально работать, ну с учетом только того что PostgreSQL не умеет сам параллелить запросы, надо планировать хранилище с учетом этого факта.

инсерты нагнуть БД не должны, выбирай шо угодно: postgres/percona. у последней можно по движкам почитать, может чтото чуть больше соптимизированно под вставки.

тут вопрос, потянет ли эта дрянь джойны по десяткам таблиц. если между таблицами нету связей вообще и планируются выборки из одной таблицы по определенном криетрию то я бы вообще в nosql плясал.

Длинных джоинов тоже не предполагается. Три-четыре сущности максимум.

1) хороший топик на so: http://stackoverflow.com/questions/12206600/how-to-speed-up-insertion-perform...

2) в mysql наверняка можно дропать данные путем удаления файлов (в которых хранятся партишены) с жесткого диска

3) подумать, как для этого использовать Apache Cassandra и Apache Hadoop/HBase, если это вообще возможно. Попрофайлить.

TRUNCATE или DROP

Хмм. Партиционирование по интервалам дат?..

Да, например так

Cassandra не для аналитики, она запросы с full scan плохо умеет

каждая строка будет прочитана из базы... единицы, десятки раз за всю жизнь

А не избыточно ли?

Да. Выдержит, без проблем, если нормально будешь проектировать. Полистай книгу Gregory Smith «Postgres 9.0 High Performance».

Пара моментов на всякий случай:
1. единица данных для постгреса — строка, т.е. если ты хочешь что-то прочитать из таблицы, то субд выдернет всю строку, поэтому если в таблице есть тяжелые данные (бинарники, файлы, огромные тексты), то лучше их выносить в отдельную таблицу и связывать индексами.
2. если много insert/update/delete, то не делай слишком много индексов, это сильно тормозит, особенно на больших таблицах
3. если таблица большая, порой разумно ее делить на несколько таблиц поменьше (по годам, например), а если все же нужно потом работать с ней, как с большой — сваргань представление, которое объединит их. Оптимизатор субд потом подстроится и не будет дергать ненужны таблицы.

По поводу того как настраивать субд — смотри в книгу.

единица данных для постгреса — строка, т.е. если ты хочешь что-то прочитать из таблицы, то субд выдернет всю строку

это не так, большие данные хранятся отдельно и вытаскиваются только если ты их реально запросил

blobы — да, text — нет.

с учетом только того что PostgreSQL не умеет сам параллелить запросы

что, серьезно?

Gregory Smith «Postgres 9.0 High Performance».

На аглицком?

maxcom уже сказал, я повторю:

В результате получится что-то вроде десятков/пары сотен таблиц с сотнями миллионов строк (результаты хранятся в течение ограниченного времени, по истечении которого будут удаляться).

Обязательно спроектировать так, чтобы DROP'ать целыми таблицами. Обязательно.

Да, на русском — не видел, да и зачем? Технический язык простой, поэтому читать лучше в первоисточнике.

Технический язык простой, поэтому читать лучше в первоисточнике.

У мну проблемка психологическая: с аглицким знаком, но постоянно преследуют думки, что что-то не так понял.

Проверяй) Все равно книги пишут торговцы технологиями и упоротые, верить нельзя никому)

верить нельзя никому

Угу. Особенно маркетологам.

blobы — да, text — нет.

text тоже «да», см. TOAST

Обязательно спроектировать так, чтобы DROP'ать целыми таблицами. Обязательно.

головную боль - гильотиной? Ну уже выше согласились - «партицирования» достаточно.

Вопрос второй - есть ли лучший инструмент для подобной задачи?

не поверишь, но как раз ваш текущий подход более лучший, нужно его только причесать. рСУБД с ACID есть смысл в вашей системе использовать только как хранилище метаданных, т.е. чтобы знать где что и в каком виде находится с какой версией обновлений. Некий наколеночный аналог BigTable

получится что-то вроде десятков/пары сотен таблиц

Сейчас в public-схеме моего проекта 300 таблиц. Проекту уже 9 лет и на сервере версии постгреса обновляются раз в год.

Самая большая таблица, и самая интересная, весит 60 гигов (все данные по некому процессу). Аналог этой таблицы, truncated-версия, каждый день чистится. Читают в основном из truncated. Полет нормальный. За 2 года моих наблюдений сбоев небыло. То есть совсем никаких.

Когда то давно на глаза попадалась такая nosql тулза для работы с массивами чисел Не подойдет?

Это не массивы чисел. Это совершенно разнородные данные, результат скорее не вычислений, а ... я бы назвал это датамайнингом.

«Причесать» это начать и кончить. Сейчас это csv-файлы. Когда пользователю нужна аналитика (достаточно стандартная) по ним, он их загружает в ёксель и... Это же бардак.

чего хочется - чтобы пользователь загружал этот же бардак из рСУБД или прямо в рСУБД всё считал и получал только ответ?

В результате получится что-то вроде десятков/пары сотен таблиц с сотнями миллионов строк

Фигня. MySQL/Postgresql такое сожрут без проблем.

Да, действительно, text тоже да.

Но toast будет задействован, только когда какое-либо значение из столбца превысит TOAST_TUPLE_THRESHOLD, который по умолчанию 2кб.

2кб это много. Мне обычно хватает 200-400 байтов. Все остальное — часто выкидываю в отдельные таблицы.

Это оно и есть.

Самая большая таблица, и самая интересная, весит 60 гигов

Настроки постгреса какие? Кеши там? Памяти сколько на машине?

Настроки постгреса какие? Кеши там? Памяти сколько на машине?

32 гигабайта памяти. Тюнингом этого инстанса постгреса не занимаюсь.