Тож норм

Cstore

Ссд

Меланхолично только пакуется

я привык считать хостинг амазоне )) поэтому там еще и эффективно данные хранить тоже полезно

Ну вы там держитесь..

?

Ну вы там держитесь..

да там нестрашно всего 12 инстансов хадупа

Норм

На много не выжмешь на hive

Плюм только

Mapr?

ага а еще спарк, в основном джобы из азкабана считать стату

Я его пока не могу, он ругается странно на компрессию, типа депрешиетед формат

Завтра в фейсбуке запостю

Ему что в кодак не прописываю, у него депрешиетед формат

Мапр :-), такой Мапр

?

Чего его все любят?

?

Хотите поделюсь знанием как стать незаменимым?

Прям реально

нет

Буддой

:-)

Зря

Меня прям толкнул

О

Нужно знать тельгу, хинди и китайский

Все

Бонусов ведро

?

нет

Теперь ты знаешь все, и жизнь уже не будет прежней :-)

?

Жми на ентер :-)

Не иетригуй общественность

Да-да, мы уже поняли, смайлики, с гринплюмом никто не сравнится, мап-редюс плох совсем не потому, что ты с ним не разобрался, и вообще ты, наверное, немного пьян и тебе хорошо. Я готов согласиться с чем угодно, только давай в чате про постгре прекратится вот это вот, а телеграм не будет показывать заблокированных пользователей не только в чатах один на один, но и в общих тоже.

Иес

https://scontent.xx.fbcdn.net/v/t1.0-9/14369999_10210525380832122_254462638708236490_n.jpg?oh=7a850cd5b23c9dba4e1d213a92478ce7&oe=5842FD36

https://www.youtube.com/watch?v=7WXCfUpVqPs

бекап переносится на новый сервер больше 4х суток, это в рамках нормы?

бекап переносится на новый сервер больше 4х суток, это в рамках нормы?

ну всё от размера бекапа и вашей сети зависит

А то?!

Ио

Там же файлики

бекап переносится на новый сервер больше 4х суток, это в рамках нормы?

вы делаете pg_basebackup, или реально копируете файлы?

ну pg_basebackup вполне реально копирует файлы, разве нет?

вы делаете pg_basebackup, или реально копируете файлы?

pg_dump через ssh, а на другом конце | psql dbname

ох, вот так точно не стоит делать

лучше pg_basebackup

ну pg_basebackup вполне реально копирует файлы, разве нет?

не совсем так, посмотрите на cpu у backend'а, по которому через streaming protocol данные льються

ну anyway на выходе $DATADIR получается ;)

лучше pg_basebackup

у меня исходный сервер с магнитными дисками, а новый ssd raid. сейчас iowait на исходном сервере все время занимает, а на ssd iowait составляет 0.1% и загруженность cpu 5% в среднем я не делал basebackup потому, что там появились дубликаты pkey, toast подфаршмачен, и не хочу чтоб это переехало на новый сервер

у меня исходный сервер с магнитными дисками, а новый ssd raid. сейчас iowait на исходном сервере все время занимает, а на ssd iowait составляет 0.1% и загруженность cpu 5% в среднем я не делал basebackup потому, что там появились дубликаты pkey, toast подфаршмачен, и не хочу чтоб это переехало на новый сервер

у pg_restore есть -j

если физ ядра есть и > 4, то будет намного быстрее

при постройке индекса упирается в 1 cpu

ну так дело то в том, что на destination сервере чпу вообще не загружен, узкое горлышко это исходный сервер с магнитными дисками. но блин, 2ТБ переносить более 4 суток это что-то дикое вообще. Будто бы он не последовательно читает, а рандомно

а кто сказал, что файл расположен последовательно по блинам?

pg не автоекстендид

только wal

в процессе экспулатации выделяются блоки по 8k - вот 8k близко расположены с большой долей вероятности

но не больше

то есть если иногда делать CLUSTER, ситуация улучшится?

да

ну или обычный vacuum full

pg_repack тоже умеет cluster

ох ну спасибо, немного стало понятнее

Дим, скажи ключ репака для кластеризации

ох черт, только что все остановилось: ... COPY 0 COPY 386 COPY 0 COPY 120442561 COPY 3266460433 COPY 0 COPY 123537416 COPY 0 setval -------- 1 (1 row) pg_dump: Dumping the contents of table "profile_chunks" failed: PQgetResult() failed. pg_dump: Error message from server: ERROR: unknown type of jsonb container pg_dump: The command was: COPY public.profile_chunks (id, "time", diff) TO stdout; COPY 1389884896 unknown type of jsonb container даже не гуглится, что это может быть?

страшная вещь, я натакое налетал когда руками этот jsonb ковырял (в смысле из Си кода)

Дим, скажи ключ репака для кластеризации

-o https://github.com/reorg/pg_repack/blob/master/bin/pg_repack.c#L2059

Thanks

как можно заставить pg_dump игнорировать ошибки?

как можно заставить pg_dump игнорировать ошибки?

а зачем?

Базу нужно чинить

тут увы не pg_dump ошибки находит а сам postgres

Кто-нибудь имел успешный опыт хранения файлов в БД ? Размер до 10мб, количеством порядка тысяч. Все хорошо?

Под несильной нагрузкой в максимум в десятки запросов в секунду к БД.

думаю не ляжет но ничего хорошего в этом нету

MVCC никто не отменял для них

Тут речь о построении MVP продукта, и есть соблазн все запихнуть в базу для удобства, на первое время по крайней мере. А чтобы отдавать файлы, есть идея кешировать через nginx или аналогичное как-нибудь.

Вообще рекомендуют не хранить файлы в бд

Да я много про эти рекомендации читал, а тут как раз прошу опровергнуть это контрпримером. Ведь странно что в БД есть механизм хранения файлов но все им не рекомендуют пользоваться.

Должен же он быть хоть для чего-то пригоден ;)

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

В отличие от обычных данных.

а сколько весят файлы?

аа все

Это скорее всего будут в 98% обычные фотографии, то есть до 10мб

сорри не увидел

а почему нельзя взять простенькие решения для хранения файлов которые уже есть ?

Например какие?

Ну можно конечно взять библиотеки для абстракции ФС на уровне проекта. Но это выглядит менее удобно чем просто взять и положить в базу закачанный файл как есть.

Система мультитенатная будет по природе, у каждого клиента свой маленький интстанс, и в таких условиях не очень легко оперировать файлами.

а как вы будете клиенту(браузеру?) отдавать файлы?

Например какие?

s3 например или можно структурировано в фс класть

а как вы будете клиенту(браузеру?) отдавать файлы?

Можно класть в кеш nginx

типо один запрос по http к nginx, потом трансфер ваше приложение, потом в СУБД? Это всё очень медленно. Надо понимать что в этом случае вы заюзаете целый процесс или тред у приложения и целый процесс у СУБД.

Ну это же только первое обращение, дальше все закешируется и будет отдаваться быстро.