Доберусь домой - закину схему, если интересно

с json в Postgres все еще сложновато работать

hstore? в Postgres

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

а я хотел бы это потом индексировать, когда монетизируюсь и появятся средства на новые серверы. Как ни смотрю, nosql вроде тут лучше подходит

А че ты жсон прям хранишь-то? Я присоединюсь к недоумению ораторов выше

А че ты жсон прям хранишь-то? Я присоединюсь к недоумению ораторов выше

В postgre это норма

В postgre это норма

показания расходятся. Ты говоришь норма, а @lleming что нет

кому верить?

плюс проблема в том, что эта таблица сейчас 22ТБ, и приближается к лимиту в 32ТБ - не знаю что будет потом

показания расходятся. Ты говоришь норма, а @lleming что нет

Не слушай леммингов

Все зависит от юз-кейса, например Wix.com вообще все данные хранит в json в mysql, хотя там даже нет поддержки json на уровне базы

да и не представляю сейчас как это все мигрировать на nosql - только что выгружать в тот же S3, да заливать обратно

Хранить недекомпонованный JSON вместо нормализованных данных - это хипстерство и похапе какое-то

ахахаха

Я производил обратную операцию mongo -> postgres и могу сказать что то еще удовольствие

плюс проблема в том, что эта таблица сейчас 22ТБ, и приближается к лимиту в 32ТБ - не знаю что будет потом

S H A R D I N G

у монги вообще лимит 32ТБ на всю БД, офигеть

у монги вообще лимит 32ТБ на всю БД, офигеть

web-scale, ага

Ну монга то же шардинг делает

Монга шардинг делает и postgres шардинг делает, но постгри НИМОДНА, ни WEBSCALE

блин, не вижу экономического смысла шардить, пока можно пихать харды в тот сервер который есть сейчас

блин, хорошая у вас тут дискуссия

блин, не вижу экономического смысла шардить, пока можно пихать харды в тот сервер который есть сейчас

Потому что табличка это один файл и если он у тебя будет ебово огромным то все будет тормозить

Потому что табличка это один файл и если он у тебя будет ебово огромным то все будет тормозить

почему же, они по 1ГБ режутся

но это же два сервера держать

блин, не вижу экономического смысла шардить, пока можно пихать харды в тот сервер который есть сейчас

уверен, что вакуум успеет пройти на 32ТБ таблице до того как наступит xid wraparound? ))

почему же, они по 1ГБ режутся

Это медленно, если у тебя будет запрос по нескольким файлам

Но это конечно спорная тема, что быстрее - прочитать несколько раз файл или агреггировать данные по сети

пока запроса нет то непонятно медленно ли это

уверен, что вакуум успеет пройти на 32ТБ таблице до того как наступит xid wraparound? ))

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

А ты можешь просто ничего не удалять и вакуум не страшен))

Это медленно, если у тебя будет запрос по нескольким файлам

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

Монга шардинг делает и postgres шардинг делает, но постгри НИМОДНА, ни WEBSCALE

я вот что хотел спросить: как там с foreign keys и решардингом?

а google bigtable не распространяется чтоб у себя ее поставить?

ну и джойнами до кучи

а google bigtable не распространяется чтоб у себя ее поставить?

ок, bigtable нет, но есть hbase на яве

можно еще blocksize изменить на 32КБ в постгре, тогда макс лимит будет 128ТБ

но советуют просто сделать партиционирование таблицы

я сильно сомневаюсь, что здесь нужен постгре

вот и я тож

во всяком случае, предлагаемый тюнинг

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

мне интересно, если просто построчно вытаскивать в параллели с кол-вом в 1,5% ядер на сколько быстро можно вытащить все данные)

вероятно команда dd if=/dev/zero of=/var/lib/postgresql/9.5/main/base/16385/16443 bs=8K seek=92803 count=1 conv=notrunc пишет нули куда-то между пейджами, которые видит постгре?

не должен вроде, я пробовал, все норм было у меня...

мне интересно, если просто построчно вытаскивать в параллели с кол-вом в 1,5% ядер на сколько быстро можно вытащить все данные)

1,5% ядер это как так?

неточно выразился видимо, ну если у тебя 100 ядер, то параллельно 150-ю процессами вытаскивать построчно

неточно выразился видимо, ну если у тебя 100 ядер, то параллельно 150-ю процессами вытаскивать построчно

а может быть, только нужно создать вторую таблицу куда вытащенное складывать, а у меня места больше нет :)

только внешний медленный hdd

аа

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

может не совсем верно вычислили начало пэйджа

смещение на 1 байт

что это за смещение? можно поподробнее?

смещение на 1 байт

да интересно, гуглил подобное, но не нашел у других подобных проблем

такого не может быть, как я полагаю в файлах страницы по 8к

еще попробовал дамп другой таблицы сделать, так сервер вообще крашится на text_to_cstring -> toast_decompress_datum -> pglz_decompress

да, бывает и такое там у тебя много что перебито видимо датафайлы, clog, multixact да и файлы ОС

да, бывает и такое там у тебя много что перебито видимо датафайлы, clog, multixact да и файлы ОС

ос я переустановил давно)

а, ну да

но наверное от этого спасет тоже заливка нулями страниц, да?

главное обнаружить какие крашатся

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

a ok

а как вычисляли расположение страницы на диске ?

а как вычисляли расположение страницы на диске ?

посмотрел первую цифру в ctid до запятой, ну и seek=этацифра в dd

точнее я сейчас осознал что нужно было делать этацифра+1, тк тот рекорд не выплюнулся в psql

первая цифра это номер страницы ?

ERROR: S client not available

вторая номер тьпла в странице

как узнать в каком файле эта страница

как узнать в каком файле эта страница

relname селектили

щас поломаете все базы

тут дело в том что я наглядно вижу как заполнение нулями одной страницы делает предыдущую страницу нечитаемой

а если таблица это набор файлов ? по Oid файла сортировали ?

а если таблица это набор файлов ? по Oid файла сортировали ?

да вот это для меня загадка, я делал под диктовку @PeterEgorov

тут дело в том что я наглядно вижу как заполнение нулями одной страницы делает предыдущую страницу нечитаемой

значит неточно определилась страница, точнее ее начало

сейчас тереблю основной файл, который не кусковой

да точно она опрделена

может знаете готовый инструмент, который умеет это автоматически делать?

а что вернет select pg_relation_filenode('tablename::regclass) ? одну запись или несколько

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

у меня ошибка была на ctid 92815. Обнулил 92815, теперь в (92814,45) появился invalid timestamp

просто ты сохрани дампы страниц до и после проблемной страницы, обнули ее и снова сравни соседние страницы

мимо

прошу прощенья

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

heh есть спец extension для таких случаев

pageinspect

можно raw data со страниц выковырять

неа

он не сможет ничего выковырять с неисправной страницы

по крайней мере у меня не получалось

чисто теоритически можно попробовать через dd скопировать отдельно попорченную Page и открыть в Hex Редакторе наверняка какая сигнатура у Заголовка ест

так можно

а таблица в которой затирают большая?

600 млн, 130 гб где-то, на сколько помню

а таблица в которой затирают большая?

да, 600млн записей примерно

понятно почему так бэкапо сложно :)