История изменений
Исправление AlexAT, (текущая версия) :
XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось
Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.
Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице. Что для хистори - ну, не фатал, но очень плохо.
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever... Если, не приведи разум, по каким-то причинам в таком запросе появился row lock... в общем, на все эти грабли нормально понаступали, и решили, что лучше без, чем с.
Обалдеть, 3 запроса - это уже нетривиальная задача?
Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)
Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов с темплейтами лучше даже и не пытаться.
Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.
Исправление AlexAT, :
XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось
Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.
Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице. Что для хистори - ну, не фатал, но очень плохо.
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever... Если, не приведи разум, по каким-то причинам в таком запросе появился row lock... в общем, на все эти грабли нормально понаступали, и решили, что лучше без, чем с.
Обалдеть, 3 запроса - это уже нетривиальная задача?
Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)
Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов лучше даже и не пытаться.
Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.
Исправление AlexAT, :
XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось
Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.
Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице. Что для хистори - ну, не фатал, но очень плохо.
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever... Если, не приведи разум, по каким-то причинам в запросе появился row lock / table lock... в общем, на все эти грабли нормально понаступали, и решили, что лучше без, чем с.
Обалдеть, 3 запроса - это уже нетривиальная задача?
Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)
Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов лучше даже и не пытаться.
Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.
Исправление AlexAT, :
XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось
Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.
Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице. Что для хистори - ну, не фатал, но очень плохо.
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever...
Обалдеть, 3 запроса - это уже нетривиальная задача?
Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)
Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов лучше даже и не пытаться.
Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.
Исправление AlexAT, :
XXI век на дворе, ограничение в 1024 дескриптора на процесс давно кончилось
Дело там не в лимите, его-то можно раздуть, но я уже вижу - вы тему MySQL и партиционирования дальше пары команд (если не вообще) не щупали.
Если очень просто - любой запрос, не ограниченный range'м из партиции, приведёт к открытию тредом всего мегатонного блока таблиц партиций. Открытие таблицы - это очень далеко не просто открытие файла. В случае TokuDB я не зря упомянул, что у него файлов до фига - там кроме табличного файла ещё открываются все файлы индексов. С чтением/инициализацией структур для каждого. На время собственно открытия и чтения метаданных мы имеем полный read-only lock на таблице.
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()/avg()/whatever...
Обалдеть, 3 запроса - это уже нетривиальная задача?
Самый интересный пункт - это пункт 2, где нужно выбрать соответствие itemid между старой и новой инсталляцией :)
Если копируем только хистори - итемы копировать не надо. Если копируем итемы - лучше копировать всё целиком, там оно настолько друг на друга гвоздями прибито, что отдельно например от дискавери и хостов лучше даже и не пытаться.
Снова видно, что совсем не щупали. Прекращаю, потому что получается демагогия ради демагогии.
Исправление AlexAT, :
И вдогонку про партиционирование...
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100. Поэтому разбивать хистори на сотни партиций, и потом смотреть, как нетороплив и важен стал last()...
Исходная версия AlexAT, :
И вдогонку про партиционирование...
А потом, после того, как у нас всё открыто, наступает самое страшное. Самая жёсткая засада. В случае, если у нас допустим 100 партиций, и запрос выбирает данные, не ограниченные партицией, один запрос превращается в 100.