Телеграмм чат группы ru_devops страница 6717

Alexander

У тебя в любом случае есть схема базы. Как минимум, в твоей голове и в твоем коде.

только для юзеров

18:37пожаловаться #1

A

Alexander in DevOps

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

Постгрес тоже можно, но лучше не надо. Потому что сторадж с http-интерфейсом - это еще не сервис.

18:37пожаловаться #2

I

ну типа если много сложного поиска появляется с джоинами и прочим, то тогда конечно постгрес. А если хватит публичного кв с простым поиском/сессии, то редис. Так?

18:40пожаловаться #3

I

CouchDB, кстати, в каких случаях можно рассматривать как альтернативу?

18:41пожаловаться #4

A

Alexander in DevOps

CouchDB, кстати, в каких случаях можно рассматривать как альтернативу?

Давно его не трогал. Ну и в интернет его выставлять тоже лучше не надо.

18:43пожаловаться #5

A

Alexander in DevOps

ну типа если много сложного поиска появляется с джоинами и прочим, то тогда конечно постгрес. А если хватит публичного кв с простым поиском/сессии, то редис. Так?

А что ты в базе собираешься хранить?

18:44пожаловаться #6

I

в редисе - таблицу индексов, в КХ - логи, в постгресе - юзеров

18:45пожаловаться #7

I

насчет остального (статика) - я думаю, как лучше: в стороннем CDN, в стороннем S3, в своем S3, в своей статике на диске и отдавать джинксом

18:49пожаловаться #8

I

Все решения плюс-минус одинаковые

18:51пожаловаться #9

A

Alexander in DevOps

в редисе - таблицу индексов, в КХ - логи, в постгресе - юзеров

Как ты собираешься логировать и ограничивать доступ к данным в редисе?

18:52пожаловаться #10

I

для публичных данных использовать отдельную базу, ограничение доступа там не требуется. Логгирование идет на уровне джинкса - там видно, откуда стучатся и за чем стучатся

18:53пожаловаться #11

I

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

18:54пожаловаться #12

I

просто не реализовывать в джинксе к ней доступ

18:54пожаловаться #13

A

Alexander in DevOps

для публичных данных использовать отдельную базу, ограничение доступа там не требуется. Логгирование идет на уровне джинкса - там видно, откуда стучатся и за чем стучатся

Просто мне не очень понятно, почему не юзать для хранения списка индексов тот же постгрес, который у тебя уже есть. Readonly-ручку для отдачи данных из таблицы не то, чтобы сильно сложно сварганить. Что ты пытаешься оптимизировать? И нужна ли эта оптимизация?

18:57пожаловаться #14

I

не. под таблицей индексов я имел ввиду какой-то сервис, который может сказать, на какой сервак стучаться, чтобы получить ту или иную статику. Частично это можно, конечно, сетью и балансировщиками разрулить, но куда быстрее будет спрашивать сразу конкретный сервак

19:01пожаловаться #15

I

Например, у тебя есть картинка, которая лежит на 3 серверах среди всех. Ты днс-ами разруливаешь, чтобы все эти 3 сервера были доступны по одному имени. Но таких групп серверов может быть несколько, и в редисе как раз лежит (хэш картинки - днс-имя серверов, где она лежит)

19:04пожаловаться #16

I

там вроде так и так надо спрашивать какой-то сервис, где лежит конкретная статика

19:05пожаловаться #17

A

Alexander in DevOps

Например, у тебя есть картинка, которая лежит на 3 серверах среди всех. Ты днс-ами разруливаешь, чтобы все эти 3 сервера были доступны по одному имени. Но таких групп серверов может быть несколько, и в редисе как раз лежит (хэш картинки - днс-имя серверов, где она лежит)

Я бы тогда тем более в постгрес положил, т.к. он не in-memory.

19:05пожаловаться #18

I

а причем здесь In-memory?

19:07пожаловаться #19

I

ну типа если картинка не является охереть какой важной, то вроде достаточно 99,9999% вероятности ее отдачи