Общие поля вынести в одну таблицу, а все остальные пихать

в jsonb рядом ?

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

Я тоже вижу в этом риск) Насколько знаю, по jsonb искать можно, но это так себе затея

для чего там еще индексы?

Индексы туда не накидывал. Вот сейчас про это читаю

то есть индексы будут работать норм с данными без схемы?

Зависит от целей, кмк. Далее - от размера jsonb и строки

А с чем Вы сравниваете, извините? Где-то есть какие-то "волшебные" индексы и неземные структуры данных для оптимизации такого поиска, что ли? Лично я вот тут https://www.mongodb.com/docs/manual/indexes/ их не вижу. Невнимательно смотрю?

Я в целом про то, что в json долго что-то искать

не быстрее чем в монге, нет?

Вероятно. Не сравнивал

Послушайте... вот мне может в целом казаться, что массивы [используя только сравнения] долго как-то сортировать, аж O(n log n). Проблема тут в том, что сравнивать это не с чем, метода с лучшей асимптотикой существовать не может. Вот поэтому я и спрашиваю — долго по сравнению с чем, конкретно?

самое время

с классическими реляционными данными?

Если сравнивать с методом, когда для каждой категории создаем отдельную таблицу. Одна таблица с общими полями для всех объявлений и много таблиц со спец полями для каждой категории

Ну это же не Вы утверждали (я хотел выяснить, что именно имели в виду @ciplenok57 и @ask_ai)...

Ага. И в условной "монге" это будет быстрее, потому что?

В монге в рамках одной коллекции могут быть данные с разными ключами. Не встаёт проблема, что у тебя будет 20 таблиц из-за 20 категорий

И от jsonb с GIN индексом в PostgreSQL это существенно отличается... как?

> Не встаёт проблема, что у тебя будет 20 таблиц из-за 20 категорий Да, кстати... а почему это проблема?

Тем, что монга это чистый nosql, а jsonb это нашлепка сверху sql бд. Интуитивно nosql должна работать лучше

наоборот: монга это чистая нашлепка без нормального sql, отношений и контроля целостности. Интуитивно она более ограничена в возможностях, а еще занимает очень много места и работает в несклько раз медленнее.

Нда. Т.е. всё свелось к "волшебным индексам и неземным структурам данных для оптимизации такого поиска". ;( А benchmarks PostgreSQL vs то-что-думаете-использовать Вы видели / делали? > Интуитивно nosql должна работать лучше Интуиция тут может подвести — ярлык "NoSQL", наклеенный на какую-то СУБД, не делает её быстрее (а её авторов — более компетентными в реализации каких-то структур данных и т.д. и т.п.).

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

да, обновлять скажем отдельные числа в монге может быть быстрее, чем обновлять жсонб, но медленнее, если все раскидано по полочкам

Для решения "нужно персист хранилище, чтобы побыстрому втолкать, а потом понемногу разбирать и в кликхаус" - сойдет. Но я бы тогда, наверное, сциллу взял.

Нормальные benchmarks в студию, что ж. ;)

потому что на диск не пишет?

https://www.diva-portal.org/smash/get/diva2:1595003/FULLTEXT01.pdf вот тут некоторые кейсы есть. на геоданных пг быстрее во всех случаях

Ну и вот там написано: The result from the benchmarking show that the latency for Insert and Update operations were lower for MongoDB, while the latency for Read was lower for PostgreSQL. Но вот на этом месте я как-то стал сомневаться, что вообще стоит читать дальше (см. подчёркнутое). > The results from the source code analysis show that both DBMSs have a complexity of O(n), but that there are multiple differences in their software architecture affecting latency Как ни читай, это феерический бред — потому что одиночная вставка в таблицу у нас`O(1), в индекс `O(log N) (и поиска — тоже) , а если они считали на n вставок и поисков, то должно было получиться O(n) и O(n log n) соответственно. Т.е. такой единой асимптотики в PostgreSQL тупо нет. Опять-таки — нужны нормальные benchmarks.

выше ссылка на бенч от клика. "обычная" пг из коробки - медленней

Вы пропустили слово "нормальные" в моей просьбе показать benchmarks, мне кажется. ;) "Из коробки" (без настроек под "железо" и нагрузку) "обычная пг" предназначен(а) для того, чтобы работать "на кофеварке", в отличие от более новых СУБД, которые подобным не заморачиваются, понимаете? Т.е. увеличение производительности того же PostgreSQL, на том же "железе" и т.п. после tuning в три раза (или даже в шесть-восемь, в исключительных случаях) — это нормально.

я так понимаю, нормальный бенчмарк это где постгрес быстрее всех других? 🙂

Ты задал верный вопрос в правильном чате 😏

Особенно в условиях санкций

Нет, Вы понимаете неправильно. Это такой benchmark, где СУБД (и OS, и т.п.) адекватно сконфигурированы специалистами по каждой СУБД (под какой-то вид нагрузки), обеспечивают выполнение тех же (или сходных) требований к надёжности, восстанавливаемости и т.п. и выполняются на том же "железе" (и без параллельной нагрузки и т.п.), и benchmark tools к ним тоже написаны адекватно (т.е. имеют не сильно отличающийся от идеального для данной СУБД overhead). Честные, короче говоря, а не так любимый всеми benchmarketing (к слову, я как-то видел benchmark, где PostgreSQL версии 8-с-чем-то (!) доблестно "побеждает" современный ему Oracle — честностью там и не пахло, разумеется).

не стоит забывать классику https://youtu.be/VjryXJYATWk?t=3549

Select 1; Однопоточно, учитывая время холодного старта СУБД

Обычно описывают железо: - CPU, RAM, диски, как собраны, VM или нет, сеть (если удалённо) - какая ОС стоит - любый настройки ядра/ОС отличные от дефолта - любые репы поставленные поверх дефолта - любые пакеты поставленные поверх дефолта - любые изменния конфигов, отличные от дефолта И сам тест: - как готовилась база — полностью воспроизводимый скрипт или дамп - как нагружалась: какие команды и как запускались, сколько потоков, какое время, и пр. Основная идея — другие на схожем (или идентичном) железе при такой же настройки и подготовке должны воспроизвести ваш результат.

+100 Кстати, тесты TPC (публикуемые результаты) делаются именно так, по идее (плюс там должен быть внешний аудит). У стандартизированных, длительно используемых тестов есть другие проблемы, правда — например, производители/авторы конкретных СУБД начинают "затачивать" их под эти тесты, в т.ч. вводя в свои СУБД такие механизмы и настройки, которые полезны, грубо говоря, только для увеличения "попугаев" в этих самых тестах.

Кстати, даже про эту ссылку (и то, что я писал про настройки): настолько могут отличаться результаты после tuning.

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