|
Задавайте вопросы, мы ответим
Вы не зашли.
Ресурс на обслуживание == лишние открытые таблицы (i.e. файлхэндлы). Не так много, чтобы было плохо :-)
А какой вообще ресурс системы на эти файлхэндлы? Вопрос, возможно, некорректный. Это просто чтоб ориентироваться.. (например, когда выделяешь серверу память, то обычно знаешь, сколько её есть и какой потолок; как дело обстоит с этими самыми файлхэндлами? и что это вообще такое, если совсем коротко)
Неактивен
Это чиселки, они задаются ulimit (см. ulimit -a для списка всех ограничений, которые
накладывает система на процессы). В принципе, повышать их не очень плохо, но
следует иметь какой-то разумный лимит всё-таки. Для того, чтобы ты осмысленно
контролировал жизнь процессов, которые потенциально помимо дескрипторов жрут
что-то еще 
Неактивен
Есть вероятность, что перевод PK на site_id приведет к еще большим проблемам :-(
Растут они из особенностей работы кластерных индексов.
На эту проблему яндекс в свое время попал
http://softwaremaniacs.org/blog/2008/02 … e-crashed/
Задача там стояла очень похожая на эту.
Решили проблему созданием нафиг ненужного автоинкрементного PK.
Может есть мысли как более эффективно с подобным бороться?
Неактивен
В моём случае пока работает нормально (если будет плохо работать - видимо, сделаю MEMORY, т.к. переписал так, что таблица теперь маленькая).
Неактивен
У Вани задачки немножко другие и реализации немножко другие
Неактивен
EugeneTM написал:
... особенностей работы кластерных индексов.
...
Может есть мысли?
:-(
Неактивен
Мысли по поводу чего? В чем вопрос?
Кластерный индекс работает именно так: данные сортируются физически
по нему. У него такая особенность
Неактивен
paulus написал:
Кластерный индекс работает именно так: данные сортируются физически
по нему. У него такая особенность
Это понятно. Не нравится способ борьбы с этим :-(
При интенсивной долбежке, если PK не автоинкремент, велика вероятность просадки на тусовке страниц.
Если добавить автоинкрементный PK, а выдавать по обычному - нагрузка при инсертах подрастает и выдача потормознее по обычному индексу. Причем по задаче этот автоинкремент нафиг не нужен.
Неприятно оно как то ....
Костыль бы какой нить.
Неактивен
В случае с InnoDB, нет возможности хранить данные не по кластерному
индексу. Если производительность не устраивает, то нужно или кластеризоваться,
или искать другие типы таблиц.
Неактивен
paulus написал:
В случае с InnoDB, нет возможности хранить данные не по кластерному
индексу. Если производительность не устраивает, то нужно или кластеризоваться,
или искать другие типы таблиц.
Кластеризоваться вроде как еще рановато.
По типам таблиц не особо и выбор широкий.
MySAM других проблем за собой потянет вагон.
В свете сделки по покупке ораклом может движок Berkeley DB восстановят. Он тут в самый раз.
Нет таких сплетен?
Неактивен
Кластеризоваться нужно уметь при создании системы, чтобы потом не
кусать локти, когда производительность сдохнет совсем.
Беркли того не стоит; InnoDB никто отзывать не собирается, т.к. он
опенсорсный. Если сырцы закроют — тут же появится открытый форк
от последней открытой ветки. Сплетни есть про Фалькон и Марию, но
эти движки, конечно, сыроваты.
Неактивен
paulus написал:
Кластеризоваться нужно уметь при создании системы, чтобы потом не
кусать локти, когда производительность сдохнет совсем.
Беркли того не стоит; InnoDB никто отзывать не собирается, т.к. он
опенсорсный. Если сырцы закроют — тут же появится открытый форк
от последней открытой ветки. Сплетни есть про Фалькон и Марию, но
эти движки, конечно, сыроваты.
Про InnoDB в принципе в курсе. :-)
Про беркли, ну тут на вкус и цвет. В принципе от задачи зависит. Для кей-валуе оно очень даже ничего. Другой вопрос не особо востребовано.
Кстати я правильно понял - InnoDB плагин по дефолту теперь от InnoBase идет?
Неактивен
Он всегда был InnoBase, сейчас просто плагин
Неактивен
