@pgsql

Страница 459 из 1062
Dmitrii
06.09.2017
12:38:22
Плюс еще бизнес логика редиректов в приложении должна учитывать эти легаси переадресации и не конфликтовать с ними

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

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

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

Google
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 селект запихать в постгре?

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
Все мы небезгрешны

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

Igor
06.09.2017
16:24:22
где такой констурктор?
http://pgtune.leopard.in.ua/

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

Igor
06.09.2017
16:25:38
shared memory смотри, и на huge pages
а какие значения и как выбирать?

Google
Artem
06.09.2017
16:27:02
а какие значения и как выбирать?
shmem в основном ориентируется на каждый коннекшон, по huge pages лучше подскажет инет

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

Igor
06.09.2017
16:27:57
shared memory смотри, и на huge pages
так те значение которые на скрине применять?

Artem
06.09.2017
16:28:29
примерно, да

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

Igor
06.09.2017
16:30:13
можешь под себя подгонять более точней
kernel.shmmax kernel.shmall как из рассчёта 16 гигов на сервере распределить?

Artem
06.09.2017
16:32:02
kernel.shmmax kernel.shmall как из рассчёта 16 гигов на сервере распределить?
на скрине сказано как раз, для имеющих 16 гиг на борту, следуют такие данные, которые на скрине

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
ок, покапаюсь
если что найдешь годное, скинь плиз, тоже почитаю

Алексей
06.09.2017
16:34:22
спасибо, а как вообще рассчитывать, формула и т.д.?
#!/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

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

Ничем, это прямо-таки ворклоад для нее. Единственное, о чем нужно подумать - о допустимости eventual consistency.
Допустимо. Если в какой-то момент кластер "соврёт" о наличии пары - ничего страшного не случится

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
Просто здесь нахваливали какие-то типа индеков, но я, к сожалению, не помню названия

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 -- разные пары.

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