LINUX.ORG.RU

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

 ,


1

3

У нас в проекте на данном этапе результаты вычислений (десятки полей и десятки/сотни/тысячи строк) хранятся в файлах.
Есть идея перенести их в БД. Зачем - это позволит сделать экспорт в различные форматы и создавать цепочки вычислений.
В результате получится что-то вроде десятков/пары сотен таблиц с сотнями миллионов строк (результаты хранятся в течение ограниченного времени, по истечении которого будут удаляться).
Внимание, вопрос первый - выдержит ли это постгрес? Вопрос второй - есть ли лучший инструмент для подобной задачи? Граничные условия - в 95% случаев строки будут добавляться, а не обновляться, каждая строка будет прочитана из базы... единицы, десятки раз за всю жизнь. В среднем, разумеется.

★★★★★

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

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

anonymous ()

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

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

maxcom ★★★★★ ()

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

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

x0r ★★★★★ ()
Ответ на: комментарий от x0r

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

Xellos ★★★★★ ()

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

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

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

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

maxcom ★★★★★ ()

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

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

Deleted ()

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

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

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

soomrack ★★★ ()
Ответ на: комментарий от soomrack

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

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

maxcom ★★★★★ ()
Ответ на: комментарий от maxcom

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

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

vertexua ★★★★★ ()

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

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

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

soomrack ★★★ ()
Ответ на: комментарий от soomrack

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

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

Deleted ()
Ответ на: комментарий от stevejobs

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

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

Deleted ()
Ответ на: комментарий от soomrack

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

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

yyk ★★★★★ ()

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

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

mashina ★★★★★ ()

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

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

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

outtaspace ★★★ ()
Ответ на: комментарий от Karapuz

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

Xellos ★★★★★ ()
Ответ на: комментарий от mashina

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

Xellos ★★★★★ ()
Ответ на: комментарий от Xellos

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

mashina ★★★★★ ()

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

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

Alve ★★★★★ ()
Ответ на: комментарий от maxcom

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

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

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

soomrack ★★★ ()
Ответ на: комментарий от outtaspace

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

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

Xellos ★★★★★ ()
Ответ на: комментарий от Xellos

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

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

outtaspace ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.