Меню
Что нового?

Как лучше организовать структуру модерируемой таблицы?

Demiurg

Guest
тогда очень странно, что ты собираешься использовать его в проектах с большой нагрузкой и не знаешь даже ссылки на офицальный сайт.
 

uchenik

Новичок
webxtor

1. Для ID выбираешь тип поля int, максимальное значение которого 2 млрд. с лишним. Допустим в сутки в таблицу добавляется 20 тыс. новых записей, что очень и очень завышено, - модераторы не будут успевать модерировать. За год ID достигнет отметки в 7 млн. Простые расчеты убеждают, что рост ID (того, который auto_increment) - не проблема.

2. По поводу скорости выборки. Тестировал недавно таблицу на максимальную нагрузку - 10 столбцов и примерно 700 тыс. записей. Из-за интенсивной вставки (около 3 тыс. запросов на вставку в час) пришлось отказатся от индексов. Запросы с группировкой, функцией MAX() и почти всеми столбцами в условии WHERE выполнялись тысячные доли секунды. Правда в моем случае не использовались обьединения и все столбцы имели цифровые типы.

...(забыл написать - тестировал на хостинге Каравана)...

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

Для несложных запросов при настроенных индексах 300 тыс. записей - это НЕ МНОГО и выборка будет очень быстрой.
 

Demiurg

Guest
uchenik
один апдейт в секунду - для тебя считается большой накрузкой ?
 

Demiurg

Guest
>Причем здесь апдейты?
разве я писал про 3 тысячи "вставок в час" ?
 

uchenik

Новичок
Автора топика интересует скорость выборки из его таблицы.
Я считаю, что выборка из таблицы с 300 тыс. записей при настроенных индексах будет очень быстрой. Поэтому выносить в отдельную таблицу "лишних" 500 записей на скорости не скажется, а геморроя добавит.

Про выборку из своей БД я написал как пример. Вот и все.
 

Demiurg

Guest
> Поэтому выносить в отдельную таблицу "лишних" 500 записей на скорости не скажется
а какие критерии были учтены при вынесе такого вердикта ?
 

uchenik

Новичок
Еще раз повторюсь: "Для несложных запросов при настроенных индексах 300 тыс. записей - это НЕ МНОГО и выборка будет очень быстрой".
 

Demiurg

Guest
uchenik
я помню на спектруме, когда у меня появился дисковод игрушки тоже грузились "очент быстро".
 

uchenik

Новичок
Demiurg,
Интересуют цифры?
Отталкиваюсь от приведенного примера, предположу что "очень быстро" - это не более 0.001 сек.
 

uchenik

Новичок
Время выполнения одного запроса на выборку. По-моему это очевидно.
 

Demiurg

Guest
совсем не очевидно ... какую выборку, какие данные? Про то, какое железо даже спрашивать не хочу.
 

uchenik

Новичок
По поводу железа - хостинг Караван, тарифный план "Бизнес". Здесь тестировал свою бд на 700 тыс. записей, соответственно от ресурсов этого тарифного плана и отталкиваюсь.

Данные добавляются пользователями, проверяются модераторами, имеют уникальный id, хранятся в одной таблице редко модифицируются - это либо статьи, либо какие-то регистрационные данные.

Какие выборки делают с такими наборами данных Demiurg знает лучше меня.
 

webxtor

Новичок
Автор оригинала: Demiurg
тогда очень странно, что ты собираешься использовать его в проектах с большой нагрузкой и не знаешь даже ссылки на офицальный сайт.
Нажмите для раскрытия...
Я когда-то один раз лазил по сайту апача и искал бинарик для моей ОС.

С того времени я занимался только разработкой проектов. А все, что касалось администрирования, делал админ!

Ладно, я вроде как узнал все за и против для разных вариантов, буду работать!

О том, как будет работать, напишу тут!
 

webxtor

Новичок
Пусть тушит! Курение вредно для здоровья. Твои высказывания тоже, если их воспринимать всерьез.

-~{}~ 27.02.05 18:04:

Ну все, я пошел кодить и обрабатывать полученную тут инфу!
Спасибо всем, кто дал мне то, за чем я сюда пришел - знания и ссылки на них :)

ЗЫ. Спасибо и Фанату за то, что высказал свое мнение и дал возможность еще шире на ВСЕ посмотреть.

PLUR

-~{}~ 27.02.05 19:49:

К стати, нашел вот статейку Жданова Евгения касательно сабжа - советует использовать временную таблицу для таких целей:

Операция UPDATE идет в три этапа: поиск того, что будете менять, затем запись данных, обновление индексов. При этом, чем больше таблица, тем дольше поиск. Если есть индексы, то операция кешируется и выполняется достаточно быстро. Но сам процесс очень емкий. И только дурак не догонит, что большая таблица со множеством индексов и записей, будет тормозить при UPDATE. INSERT же выполняется одним залпом, очень быстро. Поэтому обычно используют аддитивные записи (вставками INSERT) во временные таблицы, потом блокируют основные талицы, суммируют обновления, и плюют их в основную таблицу. Получается, что в основном, главные таблицы работают только в режиме вывода, а обновления идут гораздо реже и быстрее. Например, можно копить данные о загрузках новостей во временной таблице, а по крону или иным образом обновлять счетчик каждые 10 минут (или реже). Это ускорит работу сервера.
Нажмите для раскрытия...
-~{}~ 27.02.05 19:51:

Так что думаю таки сделать временные таблицы!

А статейка эта тут http://www.web-mastering.ru/index/3/10/
 
Войдите или зарегистрируйтесь для ответа.
Сверху