Д
партиции скорее для более удобной манипуляции данными, чем для скорости
для скорости есть ORDER BY
для скорости есть ORDER BY
большое спасибо)
Size: a a a
2020 May 27
DT
большое спасибо)
у меня партиции примерно по 3млрд записей+-
AM
вообще лучше не стоит.
К примеру могут появляться предупреждения не совпадения данных 1 в после мержа из за разных версий lz4 и тд
И тогда клик стягивает парт с другого сервера
К примеру могут появляться предупреждения не совпадения данных 1 в после мержа из за разных версий lz4 и тд
И тогда клик стягивает парт с другого сервера
но как тогда обновлять кх?
все реплики одновременно? *__*
или между обгновлениями разных нод будет лежать соответствующая репликация?
все реплики одновременно? *__*
или между обгновлениями разных нод будет лежать соответствующая репликация?
DT
но как тогда обновлять кх?
все реплики одновременно? *__*
или между обгновлениями разных нод будет лежать соответствующая репликация?
все реплики одновременно? *__*
или между обгновлениями разных нод будет лежать соответствующая репликация?
По очереди, но желательно не задерживаться надолго.
А так кстати можно по шардам обновлять, тогда хотя бы вот этих предупреждений не будет.
А так кстати можно по шардам обновлять, тогда хотя бы вот этих предупреждений не будет.
D
Эта фича перешла к одному из исполнителей, но этот человек потерял интерес к задаче. Сейчас доделывать будет изначальный автор в июле.
спасибо, будем ждать )
AM
вообще лучше не стоит.
К примеру могут появляться предупреждения не совпадения данных 1 в после мержа из за разных версий lz4 и тд
И тогда клик стягивает парт с другого сервера
К примеру могут появляться предупреждения не совпадения данных 1 в после мержа из за разных версий lz4 и тд
И тогда клик стягивает парт с другого сервера
а например вот такое:
Unsupported fetch protocol version
между 20.1 и 20.4
Unsupported fetch protocol version
между 20.1 и 20.4
AM
это никак не лечится без бампа всех до 20.4? мож какой-то даунгрейд протокола есть
DT
а например вот такое:
Unsupported fetch protocol version
между 20.1 и 20.4
Unsupported fetch protocol version
между 20.1 и 20.4
ох, вообще похоже на баг
DT
AM
оу
то есть нет шансов воспользоваться магией max_insert_threads ?
то есть нет шансов воспользоваться магией max_insert_threads ?
AM
которой в 20.1 нет
DT
оу
то есть нет шансов воспользоваться магией max_insert_threads ?
то есть нет шансов воспользоваться магией max_insert_threads ?
ну, на новых версиях можно(только устанавливать придется эту настройку у юзера), на старых не получится, кмк
AM
> устанавливать придется эту настройку у юзера
думал обойтись сессионной переменной
она так работает?
думал обойтись сессионной переменной
она так работает?
DT
> устанавливать придется эту настройку у юзера
думал обойтись сессионной переменной
она так работает?
думал обойтись сессионной переменной
она так работает?
Ну, тут смотря как ты вставляешь данные.
просто если они могут прилететь на случайный сервер, то тогда на старых будет ошибка
просто если они могут прилететь на случайный сервер, то тогда на старых будет ошибка
AM
это мне для быстрого insert-selecta нужно
оно ведь локально выполняет его?
а на реплики отправляет уже информацию о кусках ?
оно ведь локально выполняет его?
а на реплики отправляет уже информацию о кусках ?
DT
это мне для быстрого insert-selecta нужно
оно ведь локально выполняет его?
а на реплики отправляет уже информацию о кусках ?
оно ведь локально выполняет его?
а на реплики отправляет уже информацию о кусках ?
да
AM
ну ок
спасибо! будем думать и следить за ишшей)
спасибо! будем думать и следить за ишшей)
DT
ну ок
спасибо! будем думать и следить за ишшей)
спасибо! будем думать и следить за ишшей)
ну, ее закрыли, так что не думаю что будут какие то обновления)
A
ну, если вас смущает объем данных, то можете.
На самом деле оно потихоньку само пережмет это дело в фоне.
На самом деле оно потихоньку само пережмет это дело в фоне.
В итоге после optimize final, колонки разрослись еще сильнее
DT
В итоге после optimize final, колонки разрослись еще сильнее
ты какой запрос делаешь?