SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#26 31.12.2009 21:34:13

LazY
_cмельчак
MySQL Authorized Developer and DBA
Зарегистрирован: 02.04.2007
Сообщений: 849

Re: долгий выбор данных

Ресурс на обслуживание == лишние открытые таблицы (i.e. файлхэндлы). Не так много, чтобы было плохо :-)

А какой вообще ресурс системы на эти файлхэндлы? Вопрос, возможно, некорректный. Это просто чтоб ориентироваться.. (например, когда выделяешь серверу память, то обычно знаешь, сколько её есть и какой потолок; как дело обстоит с этими самыми файлхэндлами? и что это вообще такое, если совсем коротко)

Неактивен

 

#27 03.01.2010 22:00:41

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

Это чиселки, они задаются ulimit (см. ulimit -a для списка всех ограничений, которые
накладывает система на процессы). В принципе, повышать их не очень плохо, но
следует иметь какой-то разумный лимит всё-таки. Для того, чтобы ты осмысленно
контролировал жизнь процессов, которые потенциально помимо дескрипторов жрут
что-то еще smile

Неактивен

 

#28 04.01.2010 19:58:55

EugeneTM
Гуру
Зарегистрирован: 11.04.2008
Сообщений: 89

Re: долгий выбор данных

Есть вероятность, что перевод PK на site_id приведет к еще большим проблемам :-(

Растут они из особенностей работы кластерных индексов.
На эту проблему яндекс в свое время попал
http://softwaremaniacs.org/blog/2008/02 … e-crashed/

Задача там стояла очень похожая на эту.

Решили проблему созданием нафиг ненужного автоинкрементного PK.

Может есть мысли как более эффективно с подобным бороться?

Неактивен

 

#29 04.01.2010 20:18:31

LazY
_cмельчак
MySQL Authorized Developer and DBA
Зарегистрирован: 02.04.2007
Сообщений: 849

Re: долгий выбор данных

В моём случае пока работает нормально (если будет плохо работать - видимо, сделаю MEMORY, т.к. переписал так, что таблица теперь маленькая).

Неактивен

 

#30 04.01.2010 23:43:35

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

У Вани задачки немножко другие и реализации немножко другие smile

Неактивен

 

#31 05.01.2010 16:23:48

EugeneTM
Гуру
Зарегистрирован: 11.04.2008
Сообщений: 89

Re: долгий выбор данных

EugeneTM написал:

... особенностей работы кластерных индексов.
...

Может есть мысли?
:-(

Неактивен

 

#32 07.01.2010 00:10:23

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

Мысли по поводу чего? В чем вопрос?

Кластерный индекс работает именно так: данные сортируются физически
по нему. У него такая особенность smile

Неактивен

 

#33 07.01.2010 00:28:19

EugeneTM
Гуру
Зарегистрирован: 11.04.2008
Сообщений: 89

Re: долгий выбор данных

paulus написал:

Кластерный индекс работает именно так: данные сортируются физически
по нему. У него такая особенность smile

Это понятно. Не нравится способ борьбы с этим :-(
При интенсивной долбежке, если PK не автоинкремент, велика вероятность просадки на тусовке страниц.
Если добавить автоинкрементный PK, а выдавать по обычному - нагрузка при инсертах подрастает и выдача потормознее по обычному индексу. Причем по задаче этот автоинкремент нафиг не нужен.

Неприятно оно как то ....
Костыль бы какой нить.

Неактивен

 

#34 09.01.2010 00:12:51

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

В случае с InnoDB, нет возможности хранить данные не по кластерному
индексу. Если производительность не устраивает, то нужно или кластеризоваться,
или искать другие типы таблиц.

Неактивен

 

#35 09.01.2010 19:14:21

EugeneTM
Гуру
Зарегистрирован: 11.04.2008
Сообщений: 89

Re: долгий выбор данных

paulus написал:

В случае с InnoDB, нет возможности хранить данные не по кластерному
индексу. Если производительность не устраивает, то нужно или кластеризоваться,
или искать другие типы таблиц.

Кластеризоваться вроде как еще рановато.
По типам таблиц не особо и выбор широкий.
MySAM других проблем за собой потянет вагон.

В свете сделки по покупке ораклом может движок Berkeley DB восстановят. Он тут в самый раз.
Нет таких сплетен?

Неактивен

 

#36 11.01.2010 12:30:42

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

Кластеризоваться нужно уметь при создании системы, чтобы потом не
кусать локти, когда производительность сдохнет совсем.

Беркли того не стоит; InnoDB никто отзывать не собирается, т.к. он
опенсорсный. Если сырцы закроют — тут же появится открытый форк
от последней открытой ветки. Сплетни есть про Фалькон и Марию, но
эти движки, конечно, сыроваты.

Неактивен

 

#37 11.01.2010 18:06:22

EugeneTM
Гуру
Зарегистрирован: 11.04.2008
Сообщений: 89

Re: долгий выбор данных

paulus написал:

Кластеризоваться нужно уметь при создании системы, чтобы потом не
кусать локти, когда производительность сдохнет совсем.

Беркли того не стоит; InnoDB никто отзывать не собирается, т.к. он
опенсорсный. Если сырцы закроют — тут же появится открытый форк
от последней открытой ветки. Сплетни есть про Фалькон и Марию, но
эти движки, конечно, сыроваты.

Про InnoDB в принципе в курсе. :-)

Про беркли, ну тут на вкус и цвет. В принципе от задачи зависит. Для кей-валуе оно очень даже ничего. Другой вопрос не особо востребовано.

Кстати я правильно понял - InnoDB плагин по дефолту теперь от InnoBase идет?

Неактивен

 

#38 11.01.2010 19:25:17

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: долгий выбор данных

Он всегда был InnoBase, сейчас просто плагин smile

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson