Стоит ли делать такую оптимизацию?

sim3x, Суммировать эти данные с чем? Как вообще их можно суммировать? О чем вы говорите?

Стоит ли делать такую оптимизацию?

sim3x,
Таблица statistics выглядит примерно так:
id, user_referrer, user_ip, user_action, page_id, created_at
Каждое действие пользователя записывается в таком виде, что вы предлагаете суммировать?

Стоит ли делать такую оптимизацию?

sim3x, всех пользователей. Пользователи заходят на разные страницы, мы собираем данные: кто куда зашел, откуда пришел, на что нажал и тп.

Стоит ли делать такую оптимизацию?

sim3x, Зачем суммы? Мне нужно хранить сырые данные, потому что я генерирую из них различные отчеты.

Стоит ли делать такую оптимизацию?

sim3x, Поясните, пожалуйста, что значит агрегировать. Вы имеете ввиду загружать из файла через LOAD DATA?

Стоит ли делать такую оптимизацию?

BD_ l3ftoverZ!, Потому что везде пишут, что данные лучше вставлять реже большими кусками, чем часто маленькими. А причина именно индексы.

Стоит ли делать такую оптимизацию?

sim3x, Графики без онлайн обновлений.
Так что вы можете сказать по моему вопросу? Имеет ли смысл писать в таблицу без индексов и переносить в таблицу с индексами большими пачками?

Стоит ли делать такую оптимизацию?

BD_ l3ftoverZ!, Можно, но меня интересует в первую очередь вариант, который я описал. То есть запись в таблицу без индексов, что, судя по всему, должно быть быстрее, чем запись в таблицу с индексами.

Стоит ли делать такую оптимизацию?

sim3x, писать начали в мускуле, потому что нужно было начать собирать данные, БД у проекта - мускул и так было проще. Со временем стали проявляться минусы мускула на больших объемах данных. Данные используются для красивых графиков, которые смотрят пользователи. На другие хранилище переходить нужно, чтобы быстрее все это работало. Как вставка, так и чтение. Под другими хранилищами я подрозумеваю, например, ClickHouse

Стоит ли делать такую оптимизацию?

Александр, В таблице хранятся данные и отдельно хранятся индексы.
Я имею ввиду вот это:

Вставка в таблицу с индексами медленнее, чем без. Если нужно вставлять большими кусками по милиону записей и больше, можно выключить индексы, вставить данные, а потом включить.

ALTER TABLE DISABLE KEYS
INSERT INTO xxx VALUES (1,2,3)
ALTER TABLE ENABLE KEYS

В 99% это не нужно, достаточно вставлять данные большими кусками c помощью
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9); что уже даст очень приличный прирост скорости

MySQL. Что происходит с индексами при вставке данных в таблицу с индексами?

Какой подход выбрать для горизонтального масштабирования?

Boris Korobkov,
1. Сессий нет, у нас авторизация на токенах, которые хранятся в базе.
2, 3. По поводу балансировщиков, их ведь тоже может быть несколько? У амазона есть health check, который проверяет доступность сайта, что если завести два балансировщика и с помощью амазон проверять их доступность и просто направрять пользователей на доступный?
4. Да, об этом я писал в вопросе.

Ну вот вы пишете об узких местах, то есть горизонтальное масштабирование - это довольно нетривиальная задача, получается? Везде пишут о недостатках того или иного метода, но как работают крупные сервисы? Это ведь первое, что приходит в голову, докупить железа.

Какой подход выбрать для горизонтального масштабирования?

FanatPHP, Это само собой, но сервер может упасть и не от нагрузки. У нас сервер в Hetzner, а там частенько проблемы и сервер бывает недоступен.

Почему сортировка массива "вешает" страницу во Vue?

Оказывается "искусственный" тоже вешает.

Почему сортировка массива "вешает" страницу во Vue?

Я тоже так подумал. Но почему тогда искусственно созданный массив (я просто создал заглушку, вместо того, чтоб дергать реальные данные с сервера) не вешает страницу?

Почему сортировка массива "вешает" страницу во Vue?

Не могу посмотреть в консоль, так как страница недоступна. Очень похоже на бесконечный цикл, но как это возможно?

Как сделать сеанс на телеграм боте (php, mysql)?

bobrui4anin, Пример не найду. Давно делал.
Да, речь идет о ['from']['ID'].
У вас ведь при ответе от пользователя, приходит запрос на вебхук, вы получаете какие-то данные: что за кнопку пользователь нажал, что он в ответ ввел и тп.
Вышеуказанную информацию нужно писать в БД, то есть записывать id пользователя, действие, которое он совершил, время и любую другую нужную информацию. При следующем запросе, вы на сервере получаете id пользователя, делаете запрос в БД и вот у вас вся история общения с этим пользователем, то есть как бы сеанс.

UPD вечный цикл вам не поможет, потому что сервер у вас один, а клиентов много. Сервер просто реагирует на поступающий запрос и не хранит никакой истории.

В чем опасность "клиентской" oAuth авторизации?

Lander, ну так это в требованиях, без этого не получится использовать oAuth (по крайней мере я такой соц сети не встречал). Получается, что вся опасность - это что кто-то на стороне клиента "подсмотрит" строку адреса или вытащит токен из истории? В голову мне лично больше ничего не приходит.

В чем опасность "клиентской" oAuth авторизации?

edward_freedom, объясните, пожалуйста, как прокси может перехватить запрос, он ведь зашифрован?

В чем опасность "клиентской" oAuth авторизации?

Как любой прокси видит запрос, если он зашифрован?

Зачем существует "дырявая" клиентская oAuth авторизация?

Спасибо! Я почему-то был уверен, что шифруются только данные и даже не проверил это.