|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Есть высоко нагруженная БД для букмекерской конторы. В которой ежесекундно обновляются тысячи событий. Событие = матч В событии есть много различных коэффициентов. Победа первой команды, победа второй, Тоталы и т.д. Таких рынков коэффициентов порой доходит до тысячи. Основной вопрос это архитектурный. На данный момент у каждого события есть столбец longtext, где хранится огромный JSON со всеми рынками коэффициентов. Вот хотелось бы понять как построить более производительную архитектуру. Продолжить ли хранить все коэффициенты в JSON, или создать отдельную таблицу где будут храниться все коэффициенты всех событий по отдельности. т.е. если у события 900 типов коэффициентов то создать 900 строк в новой таблице, куда их всех записать. По поводу выборки по JSON то она не нужна. Тут еще интересует не мало важный момент постоянного обновления коэффициентов. Если JSON можно просто обновить, то тут придется зацепить все 900 коэффициентов, сравнить их с новыми, и если они не совпадают то заменить. Запросов к БД получится огромное множество. Конечно было бы намного удобнее если всё разделить, но будет ли это быстрее чем отправить один жирный запрос? Тут еще суть в том что событий могут быть тысячи, а у каждого события коэффициентов под тысячу, и в дабавок всё это обновляется очень часто ~2-5 сек. (сила парсеров =)) Коротко о БД: Postgres расположенная в RDS amazon Вроде всё что хотел написал, нужны любые советы по проектированию такой БД) Как лучше, что быстрее и т.д. Спасибо всем кто откликнется =) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2020, 16:06 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Тут нужен программист, как минимум способный отличить PostgreSQL от Oracle DBMS. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2020, 17:12 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Иван Фамилия Если JSON можно просто обновить, то тут придется зацепить все 900 коэффициентов, сравнить их с новыми, и если они не совпадают то заменить. Запросов к БД получится огромное множество. Мне вот это непонятно. Ничто не мешает и отдельно хранящиеся коэффициенты заменить одним update'ом. Да даже сравнив. Или я не понимаю, как рождаются коэффициенты / что вы имели в виду под запросами к БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 13:39 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Иван Фамилия Вот хотелось бы понять как построить более производительную архитектуру. Такие вопросы теоретически не решаются. Для начала необходимо видеть физическую модель, посмотреть нагрузки и т.д. Потом уже можно о чем-то говорить. А с вашим подходом вы можете с таким же успехом спросить у гадалки. Как правило при смещении в сторону производительности отказываются от EAV. Но бывают случаи что даже отказавшись - особо ничего не приростает. Причины разные - от кривизны рук разработчиков, до банальной экономии владельца. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 16:33 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
часто апдейтить в постгресе плохая идея. там нет UNDO на подобии того какой в оракле или mysql. будет пухнуть датафайл и вакум портить жизнь. я бы предпочел реляционный вариант с UPSERT/MERGE вместо json ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 19:08 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Иван Фамилия Коротко о БД: Postgres расположенная в RDS amazon Почему не DocumentDB в том же Amazon, что представляет собой документную базу данных и упрощает хранение и индексирование данных JSON, а также выполнение запросов к ним? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 19:23 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Иван Фамилия, Может имеет смысл разделить хранение оперативных ("сырых") данных и производных от них (например "аналитических")? Типа лямбда-архитектуры И да, хранить большие json-ы в PostgreSQL не самая лучшая идея, возможно стоит посмотреть в сторону NoSQL? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 05:41 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Иван Фамилия Есть высоко нагруженная БД для букмекерской конторы. В которой ежесекундно обновляются тысячи событий. Ну и вызывает определенные сомнения, что это "букмекерская контора". Если вы принимаете ставки на эти кэфы, то вам нужно в позиции ставки какую-то ссылку на конкретное значение исхода делать. Иначе, при расчете этих ставок, вам придется заново поднимать с диска все ваши JSON блобы. Ну или, как вариант, вы решили забить на ссылочную целостность и храните значения кэфов непосредственно в ставке, наивно полагая что ваше приложение идеально и никогда не сбоит, а ваши админы - люди существа кристальной честности и никогда не ищут дополнительных источников дохода к своей зп. Значит, это не контора, а просто аналитика для игроков. В этом случае вам наверняка потребуется показывать историю изменений кэфов в разрезе отдельных исходов. Учитывая, что в нормальном лайве кэфы меняются минимум 1 раз в минуту (а в динамичных видах спорта, типа баскетбола, и того чаще), вашему приложению придется обмолачивать изрядные объемы этого самого JSONa на каждый запрос к сайту / приложению. Памяти-то хватит, проверяли? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 06:30 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
mad_nazgul Иван Фамилия, Может имеет смысл разделить хранение оперативных ("сырых") данных и производных от них (например "аналитических")? Типа лямбда-архитектуры И да, хранить большие json-ы в PostgreSQL не самая лучшая идея, возможно стоит посмотреть в сторону NoSQL? Вы не первый раз уже упоминаете лямбда-архитектуру на SQL.ru. Круто, что вы её продвигаете в массы. А вот сами уже применили где-нибудь? Если да, то что за проект, если не секрет? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 09:21 |
|
Оптимизация Базы данных
|
|||
---|---|---|---|
#18+
Дмитрий Мух И да, хранить большие json-ы в PostgreSQL не самая лучшая идея, возможно стоит посмотреть в сторону NoSQL? Вы не первый раз уже упоминаете лямбда-архитектуру на SQL.ru. Круто, что вы её продвигаете в массы. А вот сами уже применили где-нибудь? Если да, то что за проект, если не секрет?[/quot] Увы нигде пока не применял :-( Но теоретическую часть учу, т.к. подход интересный. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 09:34 |
|
|
start [/forum/topic.php?fid=32&fpage=3&tid=1539855]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
others: | 229ms |
total: | 357ms |
0 / 0 |