5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Расскажи тогда чуть подробнее про задачу, что происходит с данными, что это за реестр такой, что за корреляции такие
Читать полностью…
Надо избавиться сперва от n+1, имхо.
Посмотреть планы запросов, проверить индексы.
Если это витрина, точно ли всегда нужны все данные?
Сомнительно. Скорее всего можно основную таблицу партиционировать например по дате и в основной партиции держать последний месяц только, а другие которые не используются, будет доступны если что
Сперва короче избавиться от паразитных запросов, ненужных данных в ответе - имхо. + Часто нужна пагинация в ui.
А потом уже чето дальше думать...
Ну окей, оно обычно тоже скорее всего в хипе(сам менеджмент), но ладно
Читать полностью…
Не держат данные для сокета на стеке, это нерационально и по перфомансу и по логике
Читать полностью…
Включил, увидел, что у человека vthreads производительнее, чем реактор и выключил, он точно что-то не то делал
Читать полностью…
так в том-то и дело, что реактивное программирование как парадигма оно не про последовательный флоу request-response, оно про потоки и сигналы. Про "прикапывать это все на стек" не понял, о каком стеке речь?
Читать полностью…
Он был давно (spring gateway mvc), но видимо с приходом виртуальных потоков теперь убрали предупреждения, что лучше использовать реактивный вариант
Читать полностью…
Вроде уже года полтора как создали Spring Cloud Gateway MVC без реактивщины) Мы в свое время переписывали гейтвей с реактивщины на MVC с грин-тредами
Читать полностью…
Сомнительно, что прям все нужны. Запросы ведь с фронта
Читать полностью…
Постгря, 128 ядер 512 рам
Сейчас база 2тб, будет +- 200тб
Id генерится random.uuid()
Индексов предостаточно)
Подключение по r2rdbc
Сбор запроса самописный qdsl
Вообще, мало инфы.
Что за база(постгря?), сколько там приблизительно данных. ( странно что долго, если связи 1:м , индексы есть, и по id скорее всего)
Как генерятся sql хибером? Что ещё юзаете для сбора запроса (jpa spec?)
Да это то понятно)
Пагинация, индексы партиции все уже давно навесили
Все запросы достаточно оптимальны
Планировщик только по индексам бегает
Результат невелик, прироста получили -1с
Это не витрина, поэтому, данные нужны все и всегда, причем достаточно актуальные
Уже, приблизительно 4 мес занимаемся вопросом оптимизации этого функционала
Всем привет! Помогите с выбором решения
Вводные: 1. есть реляционная база, с 15 табицами
Одна таблица основная, все остальные относятся к ней как oneToMany
2.Есть фронт и некий реестр, который собирается из этих 15 таблиц. Фильтры позволяют фильтроваться почти по каждой из таблиц, причем инвариантов фильтров бесконечное множество.
2.1 фильтр это словарное значение
3. Данные обновляются не часто(раз в день, неделю)
4. Запросы с фронта работают медленно, >5с (много корелляционных подзапросов для сбора модели ответа)
5. Рост данных ожидается еще в >100раз за два года
Варианты, которые обдумываю
Вариант1: Полнотекстовый поиск. Но этот вариант мне не нравится по трем причинам : 1. Тащить технологию, которой ранее небыло в проекте 2. Так как словарные значения, мне не кажется, что оправдано использовать полнотекстовый поиск
3. Большой дубль информации + синхронизация
Вариант 2:
Что то думать с Постгресом - строить какие то пайплайны сборки модели ответа. Некоторая обратная матрешка. Тоже не ясно, на долго ли решение, тк данных будет больше
Вариант 3:
Денармолизовать реляционную модель и хранить в какой то таблице постгреса (опять же дубль + синхронизация)
Подскажите с выбором и что можно почитать на эту тему, буду благодарен!
Не данные для сокета, а данные сокета ( дескриаторы сокета)
Читать полностью…
Стек потока.
Не совсем плнял про request response.
На строне клиента в лббом случае ждут ответ( байтики из сокета)
Котлин вроде там гордился что блокирующий вызов можно в корутин положить и вебфлаксу будет хорошо.
Читать полностью…
Да этому 100 лет в обед.
И кучу народа придумало много решений.
Реактивщина, вирт треды, очереди
Но все сводится к одному, зачитали данные из сокета, их обработали
А потом надо найти этот сокет и отправить в него данные.
Поток просто прикапывает это все на стеке, а без него это все вручную.
Последние полтора года не начинал новых проектов гейтвеев :) mvc застал только когда она а-ля бетка была. Так-то согласен, на луме может и прикольнее будет. Флаксы это для многих вообще самострел ))
Читать полностью…
Ну максимум что то интересное в data streams было и то хз, можно взять spring integration или руками наделать
Читать полностью…
люди никак не могут смириться просто что надо выкинуть понаписанное) зря страдали получается)
Читать полностью…
Реактивный стек, имхо, отлично укладывается только в одном спринговом проекте – Spring Cloud Gateway.
Читать полностью…