Вы тоже этим занимаетесь. Тема дискуссии никакого отношения к первому посту не имеет. Сам ппервый пост гиперстрофированное приувеличение содержания статьи.
P.S. Топикстартер ссылается на статью. В статье рассказывается, как пара-тройка китайцев арендовала землю у одного мужика. Эти негодяи не хотят платить аренду. Мол раз они работают на земле, то это их земля. Вот под это и создан данный топик с великолепным названием "Китайцы объявляют территорию России своей землей". Ну не гений пустых высказываний, а?
В год рождается 1 млн. детей. Из них пол ляма - вторые. 250 000 р./чел это 5 млрд. долларов в год. 10% бюджета в год. Будет какой-то подвох типа жилищных сертификатов военным....
KosoyRoman, а бестолку - таблица всё равно будет записана на диск. Даже если она десять раз уместится в памяти. Особенность такая у MySQL.
Dreammaker, увы, помоему это бизнес-логика: сортировка по дате добавления, по заглавию или случайным образом. Так что вряд ли тут что-то можно править. Но Вы правы - проблемы из-за этих сортировок.
По RAND(). Проблема не в RAND(), а в самом факте сортировки с mediumtext полями.
Значит так. В обеих таблицах есть поля типа mediumtext. При этом в ряде запросов происходит слияние таблиц и последующая сортировка. При слиянии и сортировке таблиц с извлечением mediumtext данных, вся новая таблица кладётся на диск и забирается оттуда. Отсюда и тормоза - из-за чтения-записи на диск всей таблицы.
Оптимизируется так: разбиваете каждую Вашу таблицу на две. В одной есть mediumtext поля, в другой нет. Сортируете слиянием только те таблицы, которые не имеют mediumtext полей. Затем отсылаете запросы на данные в таблицы с mediumtext полями. Запросов будет в десять раз больше, но работать будет в сотни раз быстрее.
CREATE TABLE `pqdb_articles` ( `article_id` int(11) NOT NULL auto_increment, `article_title` varchar(255) NOT NULL default '', `article_text` mediumtext NOT NULL, `article_cat` mediumint(9) NOT NULL default '0', `article_meta_key` mediumtext NOT NULL, `article_meta_desc` mediumtext NOT NULL, PRIMARY KEY (`article_id`) ) TYPE=MyISAM AUTO_INCREMENT=50972 ; -- -------------------------------------------------------- -- -- Table structure for table `categories` -- CREATE TABLE `pqdb_categories` ( `category_id` mediumint(9) NOT NULL auto_increment, `category_name` varchar(255) NOT NULL default '', `category_desc` varchar(255) NOT NULL default '', `category_meta_key` mediumtext NOT NULL, `category_meta_desc` mediumtext NOT NULL, `category_rss` mediumtext NOT NULL, PRIMARY KEY (`category_id`) ) TYPE=MyISAM AUTO_INCREMENT=250 ;
Должно превратиться в
CREATE TABLE `pqdb_articles` ( `article_id` int(11) NOT NULL auto_increment, `article_title` varchar(255) NOT NULL default '', `article_cat` mediumint(9) NOT NULL default '0', PRIMARY KEY (`article_id`) ) TYPE=MyISAM AUTO_INCREMENT=50972 ; CREATE TABLE `pqdb_articles_text` ( `article_id` int(11) NOT NULL default 0, `article_text` mediumtext NOT NULL, `article_meta_key` mediumtext NOT NULL, `article_meta_desc` mediumtext NOT NULL, PRIMARY KEY (`article_id`) ) TYPE=MyISAM; -- -------------------------------------------------------- -- -- Table structure for table `categories` -- CREATE TABLE `pqdb_categories` ( `category_id` mediumint(9) NOT NULL auto_increment, `category_name` varchar(255) NOT NULL default '', `category_desc` varchar(255) NOT NULL default '', PRIMARY KEY (`category_id`) ) TYPE=MyISAM AUTO_INCREMENT=250 ; CREATE TABLE `pqdb_categories_text` ( `category_id` mediumint(9) NOT NULL default 0, `category_meta_key` mediumtext NOT NULL, `category_meta_desc` mediumtext NOT NULL, `category_rss` mediumtext NOT NULL, PRIMARY KEY (`category_id`) ) TYPE=MyISAM;
Код бесплатно переписывать не буду - времени много займёт. Платно тоже не буду - могу лишь www.weblancer.net посоветовать.
Соло, а что там такого написано? Мало ли кто что считает своим?
Блин, положите мне Яндекс или, лучше, Google с его несколькими ДЦ.
P.S. Никто не пробовал форвардить DDoS на сайт ФСБ?
Структуру базы можете привести? Есть подозрение на сортировку большой таблицы с полем типа TEXT.
Насколько важна надёжность записи данных, которые летят на запись? Можно ли сбрасывать их на диск время от времени или нужно постоянно вести лог запросов, чтобы потом в пакетном режиме забрасывать в базу?
Сколько стоит 4 часа простоя сервера? Грубо говоря, может дешевле вообще поставить два сервака понимая, что падение одного из них не приведёт к остановке сайта. Например, один на чтение, другой на запись, при этом в любой момент каждый из них может превратиться в полномасштабный сервер.
Кстати, можно сюда стукнуться: ru_highload - здесь есть классные специалисты по оценке требуемого железа. Да и много разных архитектур разобрано.
Здесь обсуждают конфигурацию под сходную нагрузку 1500-3000 запросов в сек.
Kosya, именно. Причём взрыв нужен сферически симметричный и равномерный по поверхности оболочки бомбы. Иначе не рванёт.
