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 ★★★★
()
Ответ на: комментарий от Deleted

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

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 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.