В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.elixir

1150 membersпожаловаться на группу
2021 May 05

B

Bogdan in pro.elixir
Да, и причем нужно делать поиск по всем таким Спискам c JSON.

Видимо в таком случае rows лучше подходит. Спасибо, что наталкнули на правильню мысль.

Даст ли Redis лучше результат?
источник
21:00пожаловаться#1

AD

Anastasiya Dyachenko in pro.elixir
А чем postgres не устраивает?
источник
21:01пожаловаться#2

NM

Natalia Maximenko in pro.elixir
По jsonb, как и сказала Анастасия, искать не быстро. Насчёт redis больше вопрос как это можно правильно разложить по структуре. А если можно, то почему редис а не ETS?
источник
21:02пожаловаться#3

NM

Natalia Maximenko in pro.elixir
Объёмы тоже бы прикинуть. Чтобы понять будет ли pg недостаточно быстрым. И может какой то кусок данных иметь в доступе побыстрее
источник
21:03пожаловаться#4

AD

Anastasiya Dyachenko in pro.elixir
Вы просто называете разные технологии, не аналоги. Postgres подходит для поиска. Если вы уже упёрлись в какие-то ограничения, то другой разговор
источник
21:03пожаловаться#5

AD

Anastasiya Dyachenko in pro.elixir
А блин, про potsgres не было речи то, в общем чем обычные бд не устраивают
источник
21:05пожаловаться#6

B

Bogdan in pro.elixir
Я боюсь потенциально в них упереться.

Нужны быстрый поиск по таблице. Около 5 ключей. В одном из ключе может быть текст в 300-5000 символов. Всего таких rows будет 2-3млн. Это много для постгрес?
источник
21:06пожаловаться#7

B

Bogdan in pro.elixir
Во всяком случае базовая имплементация должна иметь такой запас.
источник
21:06пожаловаться#8

AD

Anastasiya Dyachenko in pro.elixir
В лимиты помещается, про скорость не скажу. Но тут вопрос решается не редисом и не jsonb
источник
21:08пожаловаться#9

AD

Anastasiya Dyachenko in pro.elixir
А поиск полнотекстовый или какой?
источник
21:08пожаловаться#10

B

Bogdan in pro.elixir
Да.
источник
21:09пожаловаться#11

NM

Natalia Maximenko in pro.elixir
Очень интересно сколько по итогу индекс будет весить под такую табличку
источник
21:09пожаловаться#12

B

Bogdan in pro.elixir
Будет ли лучше это хранить на object storage?
источник
21:10пожаловаться#13

AD

Anastasiya Dyachenko in pro.elixir
Как вариант можно попробовать сделать partitions
источник
21:10пожаловаться#14

NM

Natalia Maximenko in pro.elixir
Читала я недавно интересную историю про ускорение на фоне databaseless. Ищу ссылку
источник
21:12пожаловаться#15

AD

Anastasiya Dyachenko in pro.elixir
Elasticsearch ещё подойдёт если цель чисто полнотекстовый поиск
источник
21:13пожаловаться#16

LL

Lama Lover in pro.elixir
5000 символов это 5кб, что вообще не много и для object storage смысла нет
источник
21:14пожаловаться#17

LL

Lama Lover in pro.elixir
Если поиск будет по полному совпадению, то я бы подумал о хэшировании
источник
21:15пожаловаться#18

B

Bogdan in pro.elixir
Подумал еще. Пожалуй поиск по тексту можно нафиг убрать, и обойтись без него.
источник
21:16пожаловаться#19

AD

Anastasiya Dyachenko in pro.elixir
Вот, отличное решение проблемы 😁👍
источник
21:17пожаловаться#20