Комментарии 15
Может это нюансы MySQL, но селективность зависящая от похожести значений — звучит как то странно. (если мне не изменяет память, она, всё-таки о количестве уникальных значений, а не похожести значений… тем более уидов)
А можно поподробнее о том, куда в уид вставлялся таймстамп? Возможно, если он вставлялся в начало, то и с сортировкой по уидам (кластерный индекс) и с партициями проблем бы не было.
И, да — со скоростью вставки вы расплатились необходимостью KeyLookup каждого значения… правда, опять же, возможно тут есть нюансы того, что это MySQL.
Вообще весь сырбор начался с фразы про селективность, которая достаточно сомнительна)
… а нормализация, обычно, никак не мешает выбрать те же денормализованные данные в один запрос…
Странная статья )
А можно поподробнее о том, куда в уид вставлялся таймстамп? Возможно, если он вставлялся в начало, то и с сортировкой по уидам (кластерный индекс) и с партициями проблем бы не было.
И, да — со скоростью вставки вы расплатились необходимостью KeyLookup каждого значения… правда, опять же, возможно тут есть нюансы того, что это MySQL.
Вообще весь сырбор начался с фразы про селективность, которая достаточно сомнительна)
… а нормализация, обычно, никак не мешает выбрать те же денормализованные данные в один запрос…
Странная статья )
Немного не так выразился.
Индекс в mysql — это Би-дерево, поэтому когда uuid-ы содержали timestamp-ы, то это было не очень эффективное хранение.
Чтение происходит в разы реже, чем вставка. Поэтому основной выигрыш, конечно же был с когда мы стали вставлять в конец, а не искать нужное место для вставки. Ну и Key Lookup — в разы проще, чем проходиться по дереву и искать место вставки.
Индекс в mysql — это Би-дерево, поэтому когда uuid-ы содержали timestamp-ы, то это было не очень эффективное хранение.
Чтение происходит в разы реже, чем вставка. Поэтому основной выигрыш, конечно же был с когда мы стали вставлять в конец, а не искать нужное место для вставки. Ну и Key Lookup — в разы проще, чем проходиться по дереву и искать место вставки.
ммм… так а в бидерево вставляется на основе сортировки элементов. А сортировка по таймстампу в уиде бы как раз и давала бы вам вставку в конец, как Вы и хотели.
Проблема то была как раз в том, что вы использовали чистые уиды, которые непосортируешь. А вот зачем вы это сделали — большой вопрос (хотя в итоге сами же к этому и пришли).
Выстрелили себе в ногу )
Проблема то была как раз в том, что вы использовали чистые уиды, которые непосортируешь. А вот зачем вы это сделали — большой вопрос (хотя в итоге сами же к этому и пришли).
Выстрелили себе в ногу )
К сожалению не с timestamp начиналось — он был в середине него. Но да, если бы он был в начале, то да. Но все равно вставка с помощью AUTO_INCREMENT быстрее.
Ну ок, вставили бы таймстамп в начало уида и построили бы по нему кластерный индекс (раз уж вы всё равно его вставили).
Разницы в скорости вставки не было бы. Зато не надо было бы новое поле вводить и терять на выборе данных.
ЗЫ: а зачем уникальность в разрезе уида и даты вставки? уиды могут дублироваться?
Разницы в скорости вставки не было бы. Зато не надо было бы новое поле вводить и терять на выборе данных.
ЗЫ: а зачем уникальность в разрезе уида и даты вставки? уиды могут дублироваться?
При нескольких миллионах инсертов в день возможно стоит рассмотреть создание отдельной таблицы на каждый день, генерировать линки вида UUID-DDMM, и при клике из урла вычислить имя таблицы. Таблицы тогда будут маленькими и быстрыми, их легко будет удалять.
На случай, если нужны какие-то отчеты за период можно создать вьюхи или SP, которые будут все таблицы соединять. Создавать вьюхи мог бы тот же скрипт, которые создает и дропает дневные таблицы.
На случай, если нужны какие-то отчеты за период можно создать вьюхи или SP, которые будут все таблицы соединять. Создавать вьюхи мог бы тот же скрипт, которые создает и дропает дневные таблицы.
Инсертов не несколько миллионов в день, а несколько сотен миллионов в день.
Ваш подоход неправильный, это получается какой то кривой шардинг. Партиции хорошо работают.
Все события по ссылкам пишутся в очередь, оттуда батчами в clickhouse, вот оттуда отчёты и строятся.
`UUID` varchar(32)А почему не BINARY(16)?
Дало бы экономию 17 байт на запись.
При добавлении новой строки в таблицу, она дописывается не в конец файла, не в конец плоского списка, а в нужную ветку древовидной структуры, соответствующую ей по сортировке.
Пришлось, конечно, добавить уникальный ключ, чтобы не было коллизий, но скорость вставки мы увеличили.Но запись нового значения в индекс уникального ключа тоже происходит не в конец, а «в нужную ветку древовидной структуры». За счет чего получилось ускорение?
Если primary key является монотонно возрастающим, т.е автоинкрементным, то вставка происходит в конец, за счёт кеша в дереве. Я привёл ссылку на исходник postgres, там об этом упоминается, в mysql очень похожая реализация.
Как минимум меньшие объёмы данных нужно двигать, чтобы вставить запись в индекс.
Кстати, эта операция полностью блокирует таблицу — это нам совсем не подходило.
Насколько мне известно блокировка идет лишь в самом начале процесса и в самом конце.
Все остальное время никакой блокировки нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История одной оптимизации MySQL