
Dmitrii
06.09.2017
12:38:22
Плюс еще бизнес логика редиректов в приложении должна учитывать эти легаси переадресации и не конфликтовать с ними
Т.е. надо 2 таких списка хранить. Один в nginx, а другой в приложении как литералы

Denis
06.09.2017
12:39:10
А быдло-вариант написать обвязку-парсер вокруг конфига и ручку для reload процесса? В конце концов и текстовый файл база данных)
Ну или храните и управляйте регулярки и адреса в базе, а по ручке "примените" генерируйте на их базе часть конфигурации nginx и перегружайте процесс

Google

Ilya
06.09.2017
12:56:01

Darafei
06.09.2017
13:19:48
нет правильного поведения
оно не определено

Ilya
06.09.2017
13:21:11
а кому у вас в проекте пришло в голову их рядом ставить?

Darafei
06.09.2017
13:21:19
мне.

Ilya
06.09.2017
13:21:53
ну молодец. смогЪ )

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

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

Pavel
06.09.2017
13:23:31

Ilya
06.09.2017
13:23:44
но зачем
это ж теплое с мягким получается

Pavel
06.09.2017
13:26:01
но зачем
"The reason anyone would do this if they could, which they can't would be because they could, which they can't."

Darafei
06.09.2017
13:27:39
Отличное объяснение

Google

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

Ilya
06.09.2017
13:28:48
да понятно, что потому что может. просто нелогично так мешать данные

Pavel
06.09.2017
13:29:04
Все мы небезгрешны

Darafei
06.09.2017
13:29:34

Ilya
06.09.2017
13:29:59
потому что хрен знает как у тебя связан один сетоф и другой

Darafei
06.09.2017
13:30:15
Да, и я ожидаю cross join

Ilya
06.09.2017
13:31:27
да я понял что ты хотел по столбцам собрать. )

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

Darafei
06.09.2017
13:55:33
Без них не будет конфликта

Mikhail
06.09.2017
15:48:52
Всем привет! А можете дать ссылку как в селект запросе на выходе получить json скомбинированные из полей таблицы?
Так вообще можно?

Darafei
06.09.2017
15:56:20
row_to_json

Mikhail
06.09.2017
16:04:36
О, спасибо!

Igor
06.09.2017
16:22:26

Artem
06.09.2017
16:23:10
shared memory смотри, и на huge pages

Igor
06.09.2017
16:23:16
значение для конфига следующие
# 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

Artem
06.09.2017
16:23:47

Igor
06.09.2017
16:24:22

Artem
06.09.2017
16:24:29
спасибо

Igor
06.09.2017
16:25:38

Google

Artem
06.09.2017
16:27:02

Igor
06.09.2017
16:27:14

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

Igor
06.09.2017
16:27:57

Artem
06.09.2017
16:28:29
примерно, да
можешь под себя подгонять более точней

Igor
06.09.2017
16:30:13

Artem
06.09.2017
16:32:02

Igor
06.09.2017
16:32:30
спасибо, а как вообще рассчитывать, формула и т.д.?

Artem
06.09.2017
16:33:10

Igor
06.09.2017
16:33:23
ок, покапаюсь

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

Artem
06.09.2017
16:33:38

Igor
06.09.2017
16:34:22

Алексей
06.09.2017
16:34:22

Igor
06.09.2017
16:35:49

Fike
06.09.2017
16:36:17


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

Artem
06.09.2017
16:38:29
спасибо!
вот еще, маны:
https://yadi.sk/d/Ye_CAThBhD9h3

Google

Igor
06.09.2017
16:38:48

Alexander
06.09.2017
16:38:50
Просто здесь нахваливали какие-то типа индеков, но я, к сожалению, не помню названия

Dmitrii
06.09.2017
17:38:38

Alexander
06.09.2017
17:40:30
Иммутабельны на уровне строки

Pavel
06.09.2017
17:42:47
А где такое определение написано?

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

Dmitrii
06.09.2017
17:49:51
Когда ставится вопрос в рамках целой кассандры, то логично что как только данные удаляются то это уже никакая не иммутабельность
Append-only — вот хороший пример иммутабельности на мой взгляд. Типа WAL'а.

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

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

Alexander
06.09.2017
17:53:27
Да-да, согласен, теперь есть вопрос :)
Насколько безопасны с точки зрения транзакционности удаления в Casandra?
С обновлениями беда, насколько я знаю. Там не гарантируется, что кто-то другой уже что-то не обновил

Alexandr
06.09.2017
17:56:38
Не, если хочешь quorum, то он будет. Только медленно
Транзакции лучше вовсе не использовать
Задача только в хранении пар?

Alexander
06.09.2017
17:57:39
Там вроде можно указывать уровень согласованности для каждого конкретного действия

Alexandr
06.09.2017
17:57:52
Да, именно так

Alexander
06.09.2017
17:58:01

Google

Alexandr
06.09.2017
17:58:14
Только одной пары?
Или пачки?

Alexander
06.09.2017
17:59:24
Зачастую одной. Но может быть и около 5-10
Не сотен :)

Dmitrii
06.09.2017
17:59:36
Блокировку придется ставить, наверное
Пока проверяешь/пишешь

Alexandr
06.09.2017
18:00:03
Это точно не k/v?

Alexander
06.09.2017
18:00:15
Удаления будут очень редко или почти никогда
Это можно сделать как k/v, но для одного key может быть несколько тысяч value

Alexandr
06.09.2017
18:03:08
Можно сделать на кассанде. В качестве партишен ключа использовать пару
Только все это выглядит коряво

Alexander
06.09.2017
18:04:13
А что не коряво будет? :)
Следует уточнить, что порядок элементов в паре важен: 1;2 и 2;1 -- разные пары.