D
всмысле не получилось?
Size: a a a
2020 July 17
MR
картинки не подгружаются
D
картинки не подгружаются
в плане?
D
тебе сервис отдаёт url-ы на картинки или файлы?
MR
получается так, сперва он запрашивает структуру обьекта, затем запросы на ресурсы то есть видео, картины которые доступны по урлу, через газл если попробовать вернуть картинку то натыкаюсь на корс
MR
точнее сказать по газлу она не работает
MR
а когда сервис напрямую запрашивает корс блочит
D
странно конечно, корс вроде не должен вылазить если ты с бэка дёргаешь, это браузерная хрень
LY
Ребята, если ли смысл одну большую таблицу истории разделять на несколько, т.к. в ней очень много записей и берет очень много производительности. Если разделить их на 5 таблиц и при первом запросе делать поиск по 1 таблице( 15 записей допустим) и на кнопку «Показать ещё » делать снова поиск следующих 15 записей. Если не находит в первой таблице, то брать со второй, если во второй не находит, то брать с 3 . Имеет ли место быть данному способу увеличения производительности?
ИФ
Ребята, если ли смысл одну большую таблицу истории разделять на несколько, т.к. в ней очень много записей и берет очень много производительности. Если разделить их на 5 таблиц и при первом запросе делать поиск по 1 таблице( 15 записей допустим) и на кнопку «Показать ещё » делать снова поиск следующих 15 записей. Если не находит в первой таблице, то брать со второй, если во второй не находит, то брать с 3 . Имеет ли место быть данному способу увеличения производительности?
лучше один запрос вместо трех. а если он у вас долго работает - у вас неверная архитектура/настройки бд. смотрите в сторону explain. выбрать строчку по индексированным данным даже из многомиллионных таблиц - это доли секунды, бд под это заточены. если совсем дохрелионы записей - смотрите в сторону колоночных бд, типа кликхауса
ES
Ребята, если ли смысл одну большую таблицу истории разделять на несколько, т.к. в ней очень много записей и берет очень много производительности. Если разделить их на 5 таблиц и при первом запросе делать поиск по 1 таблице( 15 записей допустим) и на кнопку «Показать ещё » делать снова поиск следующих 15 записей. Если не находит в первой таблице, то брать со второй, если во второй не находит, то брать с 3 . Имеет ли место быть данному способу увеличения производительности?
Смысла нету, есть смысл архвировать старые запили в истории, можно или средствами БД делать (партицированние) или руками переносить записи
LY
Дело в том, что старые данные редко кто будет доставать
ИФ
ну тогда максимум 2 таблицы - одна полная, вторая текущая, и правильно сконфигурированные индексы
ИФ
до 20-30 миллионов записей вполне можно жить и без второй таблицы
ES
На сайте есть встроенный сервис который имеет свои определенные апи запросы, они не входят в список роутов сайта, как можно разрешить этому запросу получать данные с домена моего сайта
Если у вас там например nginx делает маршрутизацию, то можно им отдавать правильные корсы
LY
База стоит MySQL innodb . История на 3млн записей с 12 полями. Вес ее около 2.1гб
LY
Машина очень мощная
ИФ
вам эти гигабайты глаз режут? бывают мускули и на терабайты, и ничего, работают
LY
Просто процесс mysqld при поиске из этой таблицы, нагружается на 20% от одного пользователя
U
База стоит MySQL innodb . История на 3млн записей с 12 полями. Вес ее около 2.1гб
если там данные не очень нужные можете вытащить в облако монго и при селекте можно мержить через агрегацию (библиотека для монго Jessengers в помощь) а вообще 2гб это не ужас