Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Приветствую! Пытаюсь настроить партицирование таблицы MySQL. Таблица с 1 внешним ключом, InnoDB. При попытке запартицировать ее как раз по внешнему ключу постоянно плюется и пишет про PRIMARY-ключ. Если внешний ключ удаляю, то же самое абсолютно. Что посоветуете? Т.К. данных в таблице куча кучная и притом еще часто по этой таблице идут запросы ORDER BY RANDOM()... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 17:13 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Покажите точную версию MySQL, тексты DDL, которые вы пытаетесь выполнить, и точные тексты сообщений об ошибках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 17:17 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Версия 5.1.40-community К примеру, таблица Код: plaintext 1. 2. 3. 4. 5. 6. 7. Пытаемся партицировать Код: plaintext Получаем A PRIMARY KEY must include all columns in the table's partitioning function ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 17:47 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Причем хочу заметить: я пробовал делать поле `id` PRIMARY... партицировать по этому признаку глупость - т.к. задача как раз разбить данные по признаку `dictionary_id` - а он не может быть PRIMARY, ведь тогда это поле должно быть UNIQUE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 17:48 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Тогда сразу хочу заметить... Предположим, у меня есть определенное количество словарей (dictionaries) и они могут добавляться/удаляться. Каждый словарь может содержать довольно приличное количество позиций. Если сделать так - при добавлении/удалении словаря вызывался бы триггер, который бы перепрописывал партиции в дочернюю таблицу? Либо если триггером такое невозможно реализовать, реализовать это в программной части бизнес-логики? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 17:59 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
любой уникальный индекс должен содержать столбцы, которые используются при секционировании (учите русское слово!). то есть придется сделать UNIQUE KEY `id_idx` (`dictionary_id`,`id`), или отказаться от уникальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 20:30 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Alexeyco, у MySQL достаточно много ограничений на секционирование таблиц, советую почитать мануал в этой части внимательно, есть сильно неочевидные вещи. То ограничение, которое встретилось вам, как правильно указал netwind, звучит примерно так: каждый уникальный ключ (включая PK, который является UK NOT NULL) должен содержать все колонки, используемые в выражении, по которому идет секционирование. Вызвано это тем, что в MySQL отсутствуют глобальные индексы, так как поддержание подобных индексов достаточно дорогая операция. Иными словами, имея PK id и секционирование по полю ddate, MySQLю бы пришлось каким-то образом гарантировать, что id уникален во всех партициях сразу. Для этого нужен индекс, проходящий сквозь все секции. MySQL такого не умеет. А вот если PKем станет пара id, ddate, то достаточно, чтобы внутри каждой секции эти значения были уникальными. Так как ddate в разных секциях будет разный, то это автоматически гарантирует уникальность пары id, ddate на всей таблице. Спасибо ораклистам, объяснившим мне это некоторое время назад . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2010, 22:18 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Мне очень "понравилась" в свое время особенность MySQL партицирования, когда при обращении только к одной секции таблицы, эта "база" открывала файлы всех партиций. Поэтому после пары с виду безобидных запросов (к таблице с несколькими сотнями партиций), любой следующий запрос валился с "Too many open files". Помогало конечно FLUSH TABLES, но это не могло быть решением. Поэтому в конце концов решили отказаться от секционирования вообще. Будьте аккуратны вобщем. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 05:51 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Антон_118"Too many open files". Помогало конечно FLUSH TABLES, Это вообще не та проблема, которую стоит иметь ввиду. Настройте сервер нормально. Сколько у вас был секций, сколько физических носителей и НАФИГА ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 10:26 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
аа, увидел несколько сотен. по-моему это лишнее. Там начинаются ухудшения при большом количестве партиций. Хотя есть ряд запросов однозначно станут лучше, если к ним просто приписать в условие WHERE ограничения, но зачем так много ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 10:45 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
netwindаа, увидел несколько сотен. по-моему это лишнее. Там начинаются ухудшения при большом количестве партиций. Хотя есть ряд запросов однозначно станут лучше, если к ним просто приписать в условие WHERE ограничения, но зачем так много ? Точнее сказать я делал 150 секций. Это совсем не много. :( Таблица с большим количеством статистической информации, параметризированная 150-ю типами статистики. Решение с секционированием отлично подходило в данном случае. Условие WHERE на ключ секционирования использовалось и по плану видно было, что работа идет только по одной партиции. Но при этом OPEN_FILES рос очень быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 16:41 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Антон_118, раз уж вы от секционирования отказались, значит научились индексировать таблицы и добились того же эффекта, правильно? ну чуть-чуть cгруппируете данные по файлам и что принципиально изменилось? вот почитайте http://www.mysqlperformanceblog.com/2009/12/05/how-many-partitions-can-you-have/ при некоторых положительных эффектах, многое ухудшается и тем сильнее, чем больше секций. А то, что вы описываете с файлами - не проблема вовсе. Наймите такого сисадмина, который не будет разводить руками и заставлять разработчиков менять тактику, а найдет как увеличить эти лимиты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 17:08 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
netwind, С секционированием select-ы работали быстрее. Но мы посчитали, что проблема с open_files хуже медленных селектов. Скорость Insert-ов и Update-ов в нашем случае была не акутальна. Заполнение таблицы происходило один раз, а дальше только выборки. За статью спасибо. Хороший и полезный сайт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2010, 18:06 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
С секционированием все более или менее встало на свои места. Теперь косвенный вопрос. Дело в том, что указанная таблица, которую я хочу секционировать, будет содержать действительно большое количество записей. Я не уверен, что идея, которая мне пришла в голову, по-настоящему хорошая. Вот в чем она состоит. Вот к примеру, в таблицу dictionaries мы добавляем новую запись (или удаляем). И я хочу в триггер прописать инструкцию по принудительному созданию партиции для указанного id нового словаря. Соответственно, при удалении словаря партиция будет удаляться. Что скажете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2010, 21:25 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Alexeyco, ми думаем, что все попытки изобразить на процедурном mysql что-либо сложное изначально обречены. http://dev.mysql.com/doc/refman/5.1/en/stored-program-restrictions.html SQL Statements Not Permitted in Stored Routines .. SQL prepared statements (PREPARE, EXECUTE, DEALLOCATE PREPARE) can be used in stored procedures, but not stored functions or triggers. Thus, stored functions and triggers cannot use dynamic SQL (where you construct statements as strings and then execute them). это означает, что в триггере сконструировать текст формирующий эти ваши псевдополезные секции не получится никак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2010, 23:55 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
однако вы можете создать процедуру А_не_пора_ли_создать_партицию(666) и спокойно ее вызывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2010, 23:56 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
AlexeycoДело в том, что указанная таблица, которую я хочу секционировать, будет содержать действительно большое количество записей. Я не уверен, что идея, которая мне пришла в голову, по-настоящему хорошая. Вот в чем она состоит. Вот к примеру, в таблицу dictionaries мы добавляем новую запись (или удаляем). И я хочу в триггер прописать инструкцию по принудительному созданию партиции для указанного id нового словаря. Соответственно, при удалении словаря партиция будет удаляться. Что скажете? DDL в триггерах - зло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2010, 09:48 |
|
||
|
Партицирование таблиц
|
|||
|---|---|---|---|
|
#18+
Очень подробно партицирование данных на примере БД Mysql (MariaDB) рассмотрен в статье Как обрабатывать статистику за длительный период ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2018, 15:33 |
|
||
|
|

start [/forum/topic.php?fid=47&tid=1829924]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 395ms |

| 0 / 0 |
