Программирую с 1989 года, так что это была бы дичайшая ломка.
Но раз по условиям задачи программировать больше нельзя, то вспомнил бы свое образование и пошел бы преподом математики (матана, ДУ или даже элементарки) в какой-нибудь ВУЗ. Заодно и подтянул бы знания какой-то небольшой группы лиц, а то мне попадались прогеры (на тот момент — студни 5-го курса), которые не помнили даже как вычислить дискриминант квадратного трехчлена.
А если требуется забыть и это, то уехал бы в деревню, где людей (и роль государства/денег) поменьше, и занялся бы крестьянским бытом. Деревня на примете есть. ;)
Насколько мне известно, нет никакой необходимости залезать в information_schema, поскольку это эквивалентно простому запросу
SELECT COUNT(*) FROM test
Этот запрос выполняется условно-мгновенно, не обращаясь к собственно данным таблицы.
Заменив COUNT(pk_id) на (SELECT COUNT(*) FROM test) в вашем запросе из второго варианта:
SELECT t.pk_id FROM test as t,
(SELECT ROUND((SELECT COUNT(*) FROM test) * rand()) as rnd FROM test LIMIT 1) t
WHERE t.pk_id = rnd
я получил более чем десятикратное ускорение выполнения.
К слову, у меня такой запрос выполняется примерно на 50% быстрее вашего третьего варианта с information_schema: 0.0008 сек против 0.0012 сек на таблице в 3 млн записей. Полагаю, на таблицах существенно большего размера эта разница сойдет на нет. Проверить, к сожалению, сейчас не могу.
Спасибо за совет.
Статика пока на том же (основном) сервере, хвала nginx'у.
Эксперимента ради, я однажды частично выносил ее на зеркало, но существенного эффекта не заметил. Понимаю, что это просто пока не заметно. Поэтому в планах у нас есть перенос всей пользовательской статики на отдельный сервер с более дешевыми и более вместительными SATA-винтами.
Сам сайт не отличается оригинальностью: php + mysql. Причем php 5.2, а не 5.3, ибо вроде как кушает меньше.
Чат на самолично написанном демоне c++. Он вообще почти ничего не ест.
При этом, все ключи mysql целиком помещаются в ОЗУ. Что позволяет прилично выигрывать по скорострельности при DELETE, INSERT, UPDATE с учетом delay_key_write=ALL.
В результате, при 4000 юзерах онлайн, мускулу хватает max_connections=100, что и сказывается на скромном аппетите к оперативке.
Так что 4 гектара пока хватает с избытком. Как только появится потенциальная необходимость, добавим мозгов.
Диаграммами не пользуемся, увы.
Насчет экономии. Переезд на более бюджетный сервер чреват кучей впустую потраченного времени, ибо скоро переезжать снова при условии роста посещалки. Это все будет как раз дороговато, имхо.
Но спасибо за совет.
Ни одно из утверждений не верно, поскольку, прежде чем анализировать существование/отсутствие какого-либо объекта, нужно дать четкое определение этого объекта. А вот как раз с последним и возникают проблемы. Один под термином «Бог» подразумевает одно, другой — совсем иное. В результате, вполне возможно, что оба будут утверждать противоположное, но при этом оба будут правы, каждый в своем пространстве имен.
Хм. Может я чего-то не знаю.
Вы утверждаете, что технически возможно отличить новый неделегированный домен от несуществующего домена. Хотел бы узнать: как? Заранее признателен.
Еще было бы крайне любезно с Вашей стороны, если бы сообщили мне (можно в личку) имя доменной зоны, которая в настоящий момент является свежезарегистрированной и пока не делегированной. Для проверки и отладки.
А вот это Вы зря. Не делегированный домен == несуществующий для всей сети, кроме внутренней сети регистратора. Нет никакой возможности узнать сервера ДНС такого домена до момента обновления родительской зоны. Для доменов 2-го уровня родительская зона это домены верхнего уровня — .ru, .com и т.д. Для доменов 3-го и более уровня дело может обстоять иначе, однако обновление кешируемых записей ДНС вдоль маршрута тоже происходит не сразу.
Что толку знать что это такое, если не уметь вычислить дискриминант? ;)
Но раз по условиям задачи программировать больше нельзя, то вспомнил бы свое образование и пошел бы преподом математики (матана, ДУ или даже элементарки) в какой-нибудь ВУЗ. Заодно и подтянул бы знания какой-то небольшой группы лиц, а то мне попадались прогеры (на тот момент — студни 5-го курса), которые не помнили даже как вычислить дискриминант квадратного трехчлена.
А если требуется забыть и это, то уехал бы в деревню, где людей (и роль государства/денег) поменьше, и занялся бы крестьянским бытом. Деревня на примете есть. ;)
Заменив COUNT(pk_id) на (SELECT COUNT(*) FROM test) в вашем запросе из второго варианта: я получил более чем десятикратное ускорение выполнения.
К слову, у меня такой запрос выполняется примерно на 50% быстрее вашего третьего варианта с information_schema: 0.0008 сек против 0.0012 сек на таблице в 3 млн записей. Полагаю, на таблицах существенно большего размера эта разница сойдет на нет. Проверить, к сожалению, сейчас не могу.
Статика пока на том же (основном) сервере, хвала nginx'у.
Эксперимента ради, я однажды частично выносил ее на зеркало, но существенного эффекта не заметил. Понимаю, что это просто пока не заметно. Поэтому в планах у нас есть перенос всей пользовательской статики на отдельный сервер с более дешевыми и более вместительными SATA-винтами.
Сам сайт не отличается оригинальностью: php + mysql. Причем php 5.2, а не 5.3, ибо вроде как кушает меньше.
Чат на самолично написанном демоне c++. Он вообще почти ничего не ест.
При этом, все ключи mysql целиком помещаются в ОЗУ. Что позволяет прилично выигрывать по скорострельности при DELETE, INSERT, UPDATE с учетом delay_key_write=ALL.
В результате, при 4000 юзерах онлайн, мускулу хватает max_connections=100, что и сказывается на скромном аппетите к оперативке.
Так что 4 гектара пока хватает с избытком. Как только появится потенциальная необходимость, добавим мозгов.
Диаграммами не пользуемся, увы.
Насчет экономии. Переезд на более бюджетный сервер чреват кучей впустую потраченного времени, ибо скоро переезжать снова при условии роста посещалки. Это все будет как раз дороговато, имхо.
Но спасибо за совет.
PS. Отправил ошибки в личку.
Вы утверждаете, что технически возможно отличить новый неделегированный домен от несуществующего домена. Хотел бы узнать: как? Заранее признателен.
Еще было бы крайне любезно с Вашей стороны, если бы сообщили мне (можно в личку) имя доменной зоны, которая в настоящий момент является свежезарегистрированной и пока не делегированной. Для проверки и отладки.