@pgsql

Страница 360 из 1062
 
Белая Стрекоза
08.06.2017
09:07:34
Я вам просто советую открыть доку по ораклу и почитать. Есть отдельный раздел по logical standby, отдельная книжка (sic!!!) по Advanced Replication и отделная книжка (sic!!!) по Streaming Replication. Это мы про Golden Gate ещё ничего не сказали. Если вам всё это интересно, прочитайте и разберитесь вместо того, чтобы оффтопить в посгресовой конфе.
кстати дмитрий, а можно быстро неофиту ответ на дурацкий вопрос? подозреваю обладаете знаниями в обоих предметных областях? что почитать (желательно в кратком формате) про "как в пг называется рман"?

 
Dmitry
08.06.2017
09:09:42
Увы, в pg не rman "из коробки". Есть pg_basebackup. Есть сторонние проекты: barman, arman и что-то ещё, но на вскидку не вспомню, возможно кто-то дополнит список.

 
Белая Стрекоза
08.06.2017
09:10:19
есть какие-то сформировавшиеся best practice?

 
Петр
08.06.2017
09:15:07
мы bacula пользуем

Google
 
Dmitry
08.06.2017
09:15:43
Мы используем pg_basebackup в скриптовых обвязках. В Яндексе используют патченый barman. На там была мутная история с их патчем, который 2ndquadrant так и не приняли в апстрим. PGPro пилит pg_arman с инкрементами и всякими плюшками.

 
Бакула забирает бэкапы, а чем вы их делаете? Какой бэкенд/модуль бакулы используете для бэкапа пг?

 
Dmitry
08.06.2017
09:16:41
дело не в инструментах, что их не хватает

 
не хватает поддержки со стороны ядра PostgreSQL

 
Dmitry
08.06.2017
09:16:54
У нас тоже бакула на ленту готовый бэкап кладет.

 
Dmitry
08.06.2017
09:17:18
почти все инструменты - это обвязка вокруг start_backup() && sync && минимальный лог контроль

 
а так нет ни валидации бакапа не проверка даже контрольных сум

 
вот со стороны ядра проблемы пытаются решить ребята из PostgresPro

 
Петр
08.06.2017
09:19:40
Бакула забирает бэкапы, а чем вы их делаете? Какой бэкенд/модуль бакулы используете для бэкапа пг?
бэкапим на ленточки

 
Dmitry
08.06.2017
09:20:12
И репозитория бэкапов нет из коробки. PG в отличие от оракла не знает о своих бэкапах ничего.

 
Петр
08.06.2017
09:20:52
и расписание бэкапов и каталог ведется в бакуле

 
Dmitry
08.06.2017
09:22:03
бэкапим на ленточки
Вы наверно не поняли вопрос. Чем бакула бэкапит постгрес перед тем как на ленту положить? Судя по вашему ответу, боюсь предположить что pg_dump. В лучшем случае pg_dumpall. Вы wal на ленту бэкапите?

 
Петр
08.06.2017
09:22:52
нене

Google
 
Петр
08.06.2017
09:22:55
tar

 
вроде бы, точно не помню, надо глянуть

 
Белая Стрекоза
08.06.2017
09:23:25
ага, спасибо

 
Петр
08.06.2017
09:23:43
это простое копирование директорий, не дамипы

 
Dmitry
08.06.2017
09:23:59
)))))))))))) С работающей бд? Просто tar? А вы хоть раз из этого бэкапа восстанавливались? Проверяли как там всё живо )))

 
Петр
08.06.2017
09:24:20
конечно

 
стендбай как делаете?

 
копируете?

 
Dmitry
08.06.2017
09:24:47
pg_basebackup через стриминг

 
Петр
08.06.2017
09:24:50
тут тоже самое, pg_start_backup и вперед

 
Andrey
08.06.2017
09:25:09
)))))))))))) С работающей бд? Просто tar? А вы хоть раз из этого бэкапа восстанавливались? Проверяли как там всё живо )))
А в чём проблема, если вызывать pg_start_backup()?

 
Dmitry
08.06.2017
09:25:47
Ну это потом сказали ) Если так, то всё ок конечно.

 
Петр
08.06.2017
09:27:04
но, если хотите, можно и дампы делать, там можно скрипты выполнять, хоть до, хоть после

 
просто на терабайтных базах не вижу особого смысла дампы делать

 
Dmitry
08.06.2017
09:27:42
А валы как бэкапите? Как обеспечиваете, что валы не потрутся до бэкапа в рамках такого бэкапа через бакулу?

 
Про дампы вообще речи нет.

 
Петр
08.06.2017
09:28:45
валы тоже бэкапим, они удаляются скриптом после завершения их копирования

 
Dmitry
08.06.2017
09:29:24
А если валы нужны для наката реплики, а вы их бэкапным скриптом потёрли?

 
Петр
08.06.2017
09:29:45
))

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

Google
 
Петр
08.06.2017
09:30:44
в любом случае, при необходимости их легко можно восстановить из бэкапа

 
Darafei
08.06.2017
09:31:10
восстанавливать реплики только из бекапа, чтобы проверять его восстановимость :)

 
Dmitry
08.06.2017
09:52:21
И репозитория бэкапов нет из коробки. PG в отличие от оракла не знает о своих бэкапах ничего.
ну это тоже в pgpro пытаются решить

 
правда сбоку :)

 
я вообще мечтал что этим можно будет управлять не только через отдельную утилиту но и в дополнение через sql :)

 
Denis
08.06.2017
12:09:05
Кстати, все прочитали про внесённый в Госдуму законопроект о блокировках анонимайзеров и VPN?

 
Это к вопросу про запасную площадку после блокировки телеграмма

 
Konstantin
08.06.2017
12:10:51
полянка в лесу на берегу?

 
Denis
08.06.2017
12:12:37
Мне до неё только голубей слать через всю страну

 
Anton [Mgn, az09@osm]
08.06.2017
12:54:31
Это к вопросу про запасную площадку после блокировки телеграмма
Телега это первое или второе?

 
Denis
08.06.2017
12:58:21
Телегу просто прикроют как не внесённую в реестр рано или поздно - Дуров вряд ли пойдёт сотрудничать. А вот обход блокировок без VPN будет проблемой, особенно если это будет не просто бан сервисов, а анализ пакетов у провайдера

 
Алексей
08.06.2017
13:00:42
надо больше паники. не только прикроют но и будут пресделовать всех ее пользователей.

 
Алексей
08.06.2017
13:01:42
и их семьи. и семиь семей. и так далее.

 
Сергей
08.06.2017
13:01:46
куда уж там... лояльных пользователей будут частями через телеграм передавать, и по первому канала транслировать

 
Алексей
08.06.2017
13:04:00
в гитхабе щас много списков полезных каналов. будет жопа с телегой уверен будут пулреквесты в эти листы. и всё будет хорошо.

 
Sergey
08.06.2017
13:46:29
ну наконец-то перейдут все в токс и ему подобные чаты

 
Артур
08.06.2017
14:57:39
Какой ис строковых поисков быстрее?

 
rum, триграмм, обычный (индекс + LIKE)

 
Может у кого бенчмарки сохранились

 
Сергей
08.06.2017
15:04:33
так у тебя результаты будут разные, че сравнивать?

Google
 
Сергей
08.06.2017
15:05:08
под задачу выбирай

 
Alex
08.06.2017
15:05:19
триграмы обычно быстрее

 
Arthur
08.06.2017
15:05:27
смотря, какой поиск вам нужен, строковый или полнотекстовый

 
Alex
08.06.2017
15:05:57
но вообще да, смотря что надоть )

Admin
ERROR: S client not available

 
Артур
08.06.2017
15:07:52
АНАЛОГ LIKE '%test%

 
триграмм дает возможность опечатки юзать

 
Arthur
08.06.2017
15:09:04
LIKE должен быть быстрее, чем триграммы, если не путаю

 
Артур
08.06.2017
15:09:43
Я поэтому и спросил про замеры. М.б. кто-то сравнивал или в закладках статейку держит

 
по идее могу индекс по lower(field) сдеалть, но может триграм быстрее... или rum юзать уже пора.

 
Arthur
08.06.2017
15:13:15
триграммы быстрее не будут, т.к. там есть оверхед из-за алгоритма вычисления похожести двух строк, но можно будет выполнять поиск с опечатками. rum или gin можно использовать, если нужен полнотекстовый поиск, но они не дадут поиск с опечатками.

 
Dmitry
08.06.2017
15:13:16
нужно в select выкинуть значения столбца, встречающиеся только один раз (аналог uniq -d). есть что-то лучше чем SELECT col1, unnest(array_agg(col2)) FROM .. GROUP BY col1 HAVING count(col2) > 1 ?

 
Артур
08.06.2017
15:18:31
триграммы быстрее не будут, т.к. там есть оверхед из-за алгоритма вычисления похожести двух строк, но можно будет выполнять поиск с опечатками. rum или gin можно использовать, если нужен полнотекстовый поиск, но они не дадут поиск с опечатками.
спасибо

 
Arthur
08.06.2017
15:18:35
Я поэтому и спросил про замеры. М.б. кто-то сравнивал или в закладках статейку держит
есть вот такой обзор способов сортировки https://dba.stackexchange.com/a/10696/94836

 
он старый, но думаю все еще актуальный

 
Олег
08.06.2017
15:49:01
Товарищи, подскажите плиз. Что можно затюнить, чтобы асинхронная реплика не отставала от мастера?

 
abc
08.06.2017
17:34:11
Доброе время суток. Есть таблица с видео 90 млн записей. Есть таблица с ид просмотренных видео. 72 млн записей. Чтобы каждый раз показывать новые видео делаем пересечение этих таблиц. Выполняется долго. Я вот думаю а не лучше ли будет к таблице с видео добавить jsonb или array поле где хранить ид юзеров что посмотрели видео? У кого был такой опыт?

 
Сергей
08.06.2017
17:42:17
Денормализуй/кэшируй в отдельной таблице

 
Fike
08.06.2017
17:44:09
Доброе время суток. Есть таблица с видео 90 млн записей. Есть таблица с ид просмотренных видео. 72 млн записей. Чтобы каждый раз показывать новые видео делаем пересечение этих таблиц. Выполняется долго. Я вот думаю а не лучше ли будет к таблице с видео добавить jsonb или array поле где хранить ид юзеров что посмотрели видео? У кого был такой опыт?
В этом случае записи быстро разрастутся до неподъемного размера

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

Google
 
Айтуар
08.06.2017
17:52:07
Доброе время суток. Есть таблица с видео 90 млн записей. Есть таблица с ид просмотренных видео. 72 млн записей. Чтобы каждый раз показывать новые видео делаем пересечение этих таблиц. Выполняется долго. Я вот думаю а не лучше ли будет к таблице с видео добавить jsonb или array поле где хранить ид юзеров что посмотрели видео? У кого был такой опыт?
А может от обратного сделать? Хранить id не просмотренного. Т.е. при добавлении нового видео в этой таблице добавлять id этого нового видео. А при просмотре удалять этот id.

 
Аггей
08.06.2017
17:56:02
Эмм. Для каждого пользователя по 90 млн записей?

 
Вообще я даже не представляю какого жанра 90 млн видео... Наверное про котиков

 
Да и... Либо я не понял чего то о структуре... Либо там должна быть фильтрация в таблице просмотрееных по пользователю... Причём индексированная

 
А конечная выдача должна ограничиваться лимитом... Не отображаете же вы по 80 млн записей?

 
ildus
08.06.2017
18:02:46
Доброе время суток. Есть таблица с видео 90 млн записей. Есть таблица с ид просмотренных видео. 72 млн записей. Чтобы каждый раз показывать новые видео делаем пересечение этих таблиц. Выполняется долго. Я вот думаю а не лучше ли будет к таблице с видео добавить jsonb или array поле где хранить ид юзеров что посмотрели видео? У кого был такой опыт?
учитывая что придется весь список вытаскивать и снова сохранять после добавления нового ида, то лучше не стоит

 
Ildar
08.06.2017
18:06:52
АНАЛОГ LIKE '%test%
с таким wildcard-ом обычный btree будет малополезен, лучше триграммы имхо. btree хорош для префиксных запросов типа 'something%'

 
Айтуар
08.06.2017
18:35:11
Эмм. Для каждого пользователя по 90 млн записей?
А ну да так больше выходит.

 
Anatoliy
08.06.2017
18:37:06
А чо вы делаете? Предлагаете юзерам посмотреть то, что они ещё не видели или то, что видели ранее?

 
Вы же можете выбирать в cte что посмотрел юзер и делать exists или not exists (в зависимости от того, что надо) на видео которые надо показать (они очевидно отсортированы по привлекательности), выбирая рандомный небольшой кусок

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

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

 
И очевидно, что не надо показать Юзеру миллион видосов

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

 
Чувствую, будет простыня щас

Страница 360 из 1062