AV
UPDATE
option
SET
organization = device.organization
FROM
device
WHERE
option.device = device.primarykeyспасибо!!!
Size: a a a
2020 August 09
AV
Ну не аналогично в части проставления null возможно
те ? тестирую - работает норм
SB
Подскажите плиз 20 миллионов записей ежедневно в течение пяти лет в postgresql реально класть и искать по индексам? По килобайту одна запись. Это 6 миллиардов записей в год. 30 за пять лет. Постгрес потянет? С архивной схемой или можно без нее?
m
Подскажите плиз 20 миллионов записей ежедневно в течение пяти лет в postgresql реально класть и искать по индексам? По килобайту одна запись. Это 6 миллиардов записей в год. 30 за пять лет. Постгрес потянет? С архивной схемой или можно без нее?
беглый гуглеж дает что-то такое
In 2008, Yahoo claimed to have if not the largest then, one of the largest databases based on a heavily modified PostgreSQL data base engine.
The size they reported was a 2 PB (Petabytes) database and processing 24 billion events per day. This was data mentioned by Waqar Hasan, then VP of Engineering at Yahoo's data group.
In 2008, Yahoo claimed to have if not the largest then, one of the largest databases based on a heavily modified PostgreSQL data base engine.
The size they reported was a 2 PB (Petabytes) database and processing 24 billion events per day. This was data mentioned by Waqar Hasan, then VP of Engineering at Yahoo's data group.
m
или вот так наверно более интересней будет
https://medium.com/@gajus/lessons-learned-scaling-postgresql-database-to-1-2bn-records-month-edc5449b3067
https://medium.com/@gajus/lessons-learned-scaling-postgresql-database-to-1-2bn-records-month-edc5449b3067
YS
Подскажите плиз 20 миллионов записей ежедневно в течение пяти лет в postgresql реально класть и искать по индексам? По килобайту одна запись. Это 6 миллиардов записей в год. 30 за пять лет. Постгрес потянет? С архивной схемой или можно без нее?
А почему нет? Это же, грубо, где-то 40 терабайт?
Только в одну таблицу это не "влезет", придётся партиционировать.
А в остальном — вопрос "железа" и запросов, конечно.
Только в одну таблицу это не "влезет", придётся партиционировать.
А в остальном — вопрос "железа" и запросов, конечно.
RS
Yaroslav Schekin
А почему нет? Это же, грубо, где-то 40 терабайт?
Только в одну таблицу это не "влезет", придётся партиционировать.
А в остальном — вопрос "железа" и запросов, конечно.
Только в одну таблицу это не "влезет", придётся партиционировать.
А в остальном — вопрос "железа" и запросов, конечно.
https://www.2ndquadrant.com/en/blog/postgresql-maximum-table-size/ Походу это до 9.6 могло не влезть
SB
всем спасибо, получается особых противопоказаний нет. мы так же прикидывали 40 тб. Идеальный вариант наверное по году партиционировать, что бы потом старые партиции удалят ь. А версия pg 11.5 можно и 12 поставить если будет нужно
YS
https://www.2ndquadrant.com/en/blog/postgresql-maximum-table-size/ Походу это до 9.6 могло не влезть
Там написано ровно то же самое, что я и написал.
Лимит всё тот же ( https://www.postgresql.org/docs/current/limits.html ), с не default BLCKSZ PostgreSQL собирает примерно... никто, партиционировать придётся.
Лимит всё тот же ( https://www.postgresql.org/docs/current/limits.html ), с не default BLCKSZ PostgreSQL собирает примерно... никто, партиционировать придётся.
A
беглый гуглеж дает что-то такое
In 2008, Yahoo claimed to have if not the largest then, one of the largest databases based on a heavily modified PostgreSQL data base engine.
The size they reported was a 2 PB (Petabytes) database and processing 24 billion events per day. This was data mentioned by Waqar Hasan, then VP of Engineering at Yahoo's data group.
In 2008, Yahoo claimed to have if not the largest then, one of the largest databases based on a heavily modified PostgreSQL data base engine.
The size they reported was a 2 PB (Petabytes) database and processing 24 billion events per day. This was data mentioned by Waqar Hasan, then VP of Engineering at Yahoo's data group.
Это явно не на одном сервере, а нехило пошардировано, а также специально по соответствующие взоникающие ограничения написан софт.
m
на один сервер я бы вообще не стал столько данных складывать, тем более они исторические
YS
всем спасибо, получается особых противопоказаний нет. мы так же прикидывали 40 тб. Идеальный вариант наверное по году партиционировать, что бы потом старые партиции удалят ь. А версия pg 11.5 можно и 12 поставить если будет нужно
Для партиционирования — чем новее версия, тем лучше.
Кстати, у партиционирования хватает ограничений, которые могут помешать его использованию — Вы проверьте, что для этих данных подойдёт.
Кстати, у партиционирования хватает ограничений, которые могут помешать его использованию — Вы проверьте, что для этих данных подойдёт.
SZ
точно ))))
YS
на один сервер я бы вообще не стал столько данных складывать, тем более они исторические
Хмм... а почему?
SZ
Всем привет. Скажите, есть возможность ускорить postgres startup из рекавери? А то есть 3 тера вал логов, и постгрес их медленно проигрывает
попробуйте pg_prefaulter — проблема, что wal читает только один процесс — полезно для реплик и для загрузки когда много wal-ов
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
m
Yaroslav Schekin
Хмм... а почему?
как минимум, чтобы не пробовать возмоные грабли на себе,
к тому же сделать себе пространство для маневра под изменеие схемы/нагрузки/других условий
к тому же сделать себе пространство для маневра под изменеие схемы/нагрузки/других условий
m
таймскейл данные к тому же имеют особенности и их как правило можно обрабатывать параллельно
RS
попробуйте pg_prefaulter — проблема, что wal читает только один процесс — полезно для реплик и для загрузки когда много wal-ов
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
если я правильно понял, то это классная тема когда уже реплика поднялась и подключилась к мастеру, тогда будет preload в cache OS . а у меня еще на этапе старта оно медленно поднимается..
RS
попробуйте pg_prefaulter — проблема, что wal читает только один процесс — полезно для реплик и для загрузки когда много wal-ов
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
pg_prefaulter https://github.com/joyent/pg_prefaulter -- может помогать для борьбы с лагом репликации -- утилита на go -- читает wal с помощью pg_xlogdump и разогреват кеш фс для файлов, которые потребуются при применении wal -- делает это многопоточно вроде работает с 9.6 https://www.pgcon.org/2018/schedule/attachments/485_pg_prefaulter.pdf
спасибо, так как когда поднимется то нужно будет уже ускорить валы с мастера
YS
как минимум, чтобы не пробовать возмоные грабли на себе,
к тому же сделать себе пространство для маневра под изменеие схемы/нагрузки/других условий
к тому же сделать себе пространство для маневра под изменеие схемы/нагрузки/других условий
Я просто не понял, о каких "граблях" речь.
Тем более что у альтернативы (несколько серверов) "грабли" точно есть — ниже надёжность; возможно, выше TCO; вполне вероятно, придётся либо писать приложение(я) специально под эту архитектуру и заниматься настройками, либо получить и низкую производительность; возможны проблемы с консистентностью.
Тем более что у альтернативы (несколько серверов) "грабли" точно есть — ниже надёжность; возможно, выше TCO; вполне вероятно, придётся либо писать приложение(я) специально под эту архитектуру и заниматься настройками, либо получить и низкую производительность; возможны проблемы с консистентностью.