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

Т.е. надо 2 таких списка хранить. Один в nginx, а другой в приложении как литералы

А быдло-вариант написать обвязку-парсер вокруг конфига и ручку для reload процесса? В конце концов и текстовый файл база данных)

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

а кто ещё не обновился на Postgres 10 и хочет, чтобы обновление прошло менее болезненно, чем у нас, голосуйте за тикет про валидацию синтаксиса Set Returning Functions в DataGrip :) https://youtrack.jetbrains.com/issue/DBE-5117

мне не приходило в голову 2 unnest пихать в 1 селект. и да, правильное то поведение какое должно быть? :)

нет правильного поведения

оно не определено

а кому у вас в проекте пришло в голову их рядом ставить?

мне.

ну молодец. смогЪ )

Кстати, Илья ищет работу. Кто-нибудь хочет ему её предложить? :)

это погодь а чо получается так можно 2-3 сетофа в 1 селект запихать в постгре?

это погодь а чо получается так можно 2-3 сетофа в 1 селект запихать в постгре?

why not?

но зачем

это ж теплое с мягким получается

но зачем

"The reason anyone would do this if they could, which they can't would be because they could, which they can't."

Отличное объяснение

Обожаю "Рика и Морти". Теперь это мой эквивалент "почему? Потомму" ?

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

Все мы небезгрешны

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

Почему нелогично?

потому что хрен знает как у тебя связан один сетоф и другой

Да, и я ожидаю cross join

да я понял что ты хотел по столбцам собрать. )

Привет, ON CONFLICT UPDATE не сработает без изменения тех колонок где unique стоит?

Без них не будет конфликта

Всем привет! А можете дать ссылку как в селект запросе на выходе получить json скомбинированные из полей таблицы?

Так вообще можно?

row_to_json

О, спасибо!

shared memory смотри, и на huge pages

значение для конфига следующие # DB Version: 9.6 # OS Type: linux # DB Type: oltp # Total Memory (RAM): 16 GB # Number of Connections: 200 max_connections = 200 shared_buffers = 4GB effective_cache_size = 12GB work_mem = 20971kB maintenance_work_mem = 1GB min_wal_size = 2GB max_wal_size = 4GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100

значение для конфига следующие # DB Version: 9.6 # OS Type: linux # DB Type: oltp # Total Memory (RAM): 16 GB # Number of Connections: 200 max_connections = 200 shared_buffers = 4GB effective_cache_size = 12GB work_mem = 20971kB maintenance_work_mem = 1GB min_wal_size = 2GB max_wal_size = 4GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100

где такой констурктор?

где такой констурктор?

http://pgtune.leopard.in.ua/

спасибо

shared memory смотри, и на huge pages

а какие значения и как выбирать?

а какие значения и как выбирать?

shmem в основном ориентируется на каждый коннекшон, по huge pages лучше подскажет инет

shmem в основном ориентируется на каждый коннекшон, по huge pages лучше подскажет инет

спасибо

спасибо

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

shared memory смотри, и на huge pages

так те значение которые на скрине применять?

примерно, да

можешь под себя подгонять более точней

можешь под себя подгонять более точней

kernel.shmmax kernel.shmall как из рассчёта 16 гигов на сервере распределить?

kernel.shmmax kernel.shmall как из рассчёта 16 гигов на сервере распределить?

на скрине сказано как раз, для имеющих 16 гиг на борту, следуют такие данные, которые на скрине

спасибо, а как вообще рассчитывать, формула и т.д.?

спасибо, а как вообще рассчитывать, формула и т.д.?

а вот это я бы сам почитал/восполнил знания

ок, покапаюсь

Ребята, вот здесь недавно обсуждали, что всякие noSQL типа Casandra не нужны, потому что есть какие-то хитрые индексы. Допустим, есть задача: нужно храниться много уникальных пар bigint к bigint, которые могут только добавляться или удаляться (имутабельны). Записей может быть несколько миллиардов и это число будет всегда расти. Чаще всего нужно будет проверять существование пары. Хочется, чтобы при росте нагрузки на хранилище можно было легко и просто добавить новую ноду и она сразу включилась в работу без какой-либо болезненной настройки. А теперь вопрос: для такой задачи Casandra все ещё плоха? Как можно использовать postgres для этой задачи максимально эффективно?

ок, покапаюсь

если что найдешь годное, скинь плиз, тоже почитаю

спасибо, а как вообще рассчитывать, формула и т.д.?

#!/bin/bash page_size=`getconf PAGE_SIZE` phys_pages=`getconf _PHYS_PAGES` shmall=`expr $phys_pages / 2` shmmax=`expr $shmall \* $page_size` echo kernel.shmmax = $shmmax echo kernel.shmall = $shmall

#!/bin/bash page_size=`getconf PAGE_SIZE` phys_pages=`getconf _PHYS_PAGES` shmall=`expr $phys_pages / 2` shmmax=`expr $shmall \* $page_size` echo kernel.shmmax = $shmmax echo kernel.shmall = $shmall

спасибо!

Ребята, вот здесь недавно обсуждали, что всякие noSQL типа Casandra не нужны, потому что есть какие-то хитрые индексы. Допустим, есть задача: нужно храниться много уникальных пар bigint к bigint, которые могут только добавляться или удаляться (имутабельны). Записей может быть несколько миллиардов и это число будет всегда расти. Чаще всего нужно будет проверять существование пары. Хочется, чтобы при росте нагрузки на хранилище можно было легко и просто добавить новую ноду и она сразу включилась в работу без какой-либо болезненной настройки. А теперь вопрос: для такой задачи Casandra все ещё плоха? Как можно использовать postgres для этой задачи максимально эффективно?

Ничем, это прямо-таки ворклоад для нее. Единственное, о чем нужно подумать - о допустимости eventual consistency.

Насколько я понимаю, для такой задачи в postgres придётся городить либо шардинг, либо реализацию, а может и все вместе. В таком случае добавление новой ноды трудно назвать безболезненным.

Ничем, это прямо-таки ворклоад для нее. Единственное, о чем нужно подумать - о допустимости eventual consistency.

Допустимо. Если в какой-то момент кластер "соврёт" о наличии пары - ничего страшного не случится

спасибо!

вот еще, маны: https://yadi.sk/d/Ye_CAThBhD9h3

вот еще, маны: https://yadi.sk/d/Ye_CAThBhD9h3

спасибо!

Просто здесь нахваливали какие-то типа индеков, но я, к сожалению, не помню названия

Ребята, вот здесь недавно обсуждали, что всякие noSQL типа Casandra не нужны, потому что есть какие-то хитрые индексы. Допустим, есть задача: нужно храниться много уникальных пар bigint к bigint, которые могут только добавляться или удаляться (имутабельны). Записей может быть несколько миллиардов и это число будет всегда расти. Чаще всего нужно будет проверять существование пары. Хочется, чтобы при росте нагрузки на хранилище можно было легко и просто добавить новую ноду и она сразу включилась в работу без какой-либо болезненной настройки. А теперь вопрос: для такой задачи Casandra все ещё плоха? Как можно использовать postgres для этой задачи максимально эффективно?

Если данные могут удаляться то они уже по определению не иммутабельны

Иммутабельны на уровне строки

А где такое определение написано?

Впрочем, если отсутствие объекта рассматривать как его состояние, то вы будете правы. Но тогда все или почти все данные не иммутабельны.

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

Append-only — вот хороший пример иммутабельности на мой взгляд. Типа WAL'а.

Когда я говорил о "только чтении и записи", это и имел ввиду

> нужно храниться много уникальных пар bigint к bigint, которые могут только добавляться или удаляться (имутабельны)

:)

Да-да, согласен, теперь есть вопрос :)

Насколько безопасны с точки зрения транзакционности удаления в Casandra?

С обновлениями беда, насколько я знаю. Там не гарантируется, что кто-то другой уже что-то не обновил

Не, если хочешь quorum, то он будет. Только медленно

Транзакции лучше вовсе не использовать

Задача только в хранении пар?

Там вроде можно указывать уровень согласованности для каждого конкретного действия

Да, именно так

Задача только в хранении пар?

Да. И быстрой проверки на предмет существования пары

Только одной пары?

Или пачки?

Зачастую одной. Но может быть и около 5-10

Не сотен :)

Блокировку придется ставить, наверное

Пока проверяешь/пишешь

Это точно не k/v?

Удаления будут очень редко или почти никогда

Это можно сделать как k/v, но для одного key может быть несколько тысяч value

Можно сделать на кассанде. В качестве партишен ключа использовать пару

Только все это выглядит коряво

А что не коряво будет? :)

Следует уточнить, что порядок элементов в паре важен: 1;2 и 2;1 -- разные пары.