Друзья есть вотткакая таблица с данными create table

ping
(
id serial primary key,
created timestamp not null,
id_1 varchar(255),
user_id varchar(255),
name varchar(255) not null,
platform varchar(255),
version varchar(255),
workgroup varchar(255),
description text not null,
s3_domain varchar(255)[] not null,
s3_urls varchar(255)[] not null,
installed_frends text not null
);

и есть проблема поле s3_domain installed_frends представляют из себя строки но по факту там вписанны массивы типо installed_frends = ['Killmax','dima_tossster','vasya23big']

им щас у меня очень страдает выборка по этим строкам при агрегации.

Как мне правилььнее поступить ?
вынести эту таблицу вобще в другую бд какуюнибуд ?
перевести строки в массивы (как вобще у постгреса с выборкой по массивам)
Вынеси все что в массивых по таблицам. ( тут большой вопрос потомучто ммассивы эти имют по 100 индексов, и джойнитьь по 100 раз такое себе)
Или есть другое более правильное решение

сразу оговорюс бд юзается для статистики . Предыдущий разраб так все накатал , вот разбираюсь

>как вобще у постгреса с выборкой по массивам Гораздо лучшэ, чем с выборкой по элементам строк, которые на самом деле не строки, а массивы. >тут большой вопрос Вообще не понял вопроса.

ну таблица на 15 млн строк. Самый простой способ помимо конвертации в массивы это вынести дыннaые из installed_frends в отдельную таблицу а потом соеденинть как многие ко многим и через join подтягивать данные. Но я никогда не подтягивал столько данных через join. Вот и справшиваю что будет лучьше. Сделать из этого массив, Сделать из этого несколько таблиц и подтягивать через join, или вытащить в другую бд.

Второй вариант -- ну, в принцыпе так и надо. Лет хотя бы 10 назад я сказал бы, что только так и надо... Но на практике во-первых при маленьких массивах -- массивы могут быть быстрее, во-вторых в постгрессе нет индэксов на join и несколько таблиц, а на массивы -- есть. Потому всё сложно и требует анализа запросов, которые будут идти к базе. Но в большынстве случаев -- вторая таблица один-ко-многим правильнее и быстрее.

спасибо , буду эксперементировать

я тут прикинул в таблице 15 милионов строк, в ней есть массивы которые хранятся строкой, массивы эти длинной могут быть 1000 пунктов если я это все переведу в отдельные таблицы то таблица (которая будет многое ко многим), она же будет просто овер гигантская

Гигантская -- это когда не влезает на бытовой SSD.

хмм

А разных вариантов классификатора у вас сколько? И какие у вас агрегации и пр. запросы про s3_domain? А то может быть s3_domain можно заменить на bitset А может быть оставить как есть, просто добавить gin индекс

gin индексы на всех строках стоят, ну например есть строка installed_frends = ['Killmax','dima_tossster','vasya23big'] и надо найти всех у кого есть vasya23big и еще с десяток других васянов

Поиск Васянов должен работать быстро при наличии gin индекса. Что медленно работает?