92, про смски это я образно ))) Ну да вообще, хранить только информацию об
активных персонажах - разумная идея. Но каков критерий активности )))
95, 96 Приятно видеть таких людей в посте о моем жалком сайтишке ))) Илья, ну
там индексы еще, то-се. Таблица с данными весит 26.6 Гб сейчас, в ней 28 колонок
и приблизительно 116 миллионов записей. Сегодня кстати круглая дата - 111 дней
со старта сервиса ))) Кэшировать мне пока что надо разве что сводную таблицу по
синдикату, никак руки не доходят - этот ужас генерится по 40-50 секунд. В
остальном, SQL не так уж и тормозит, хотя я морально готовлюсь )))
Основная идея у меня была в том, чтобы точно знать состояние персонажа на
некоторый момент времени (отдача игрой статистики ежедневно, плюс ручные
апдейты). Я что-то думал-думал сегодня, не придумал, как, не меняя этой идеи,
сделать что-то, что не требовало бы хранения всех тех данных, которые хранятся
сейчас. Ну разве что не хранить данные старше какого-то времени - но этим я
хотел заняться через годик. Проблема сейчас исключительно в том, что я несколько
заблуждался на тему хостера. Например, к лежащим с 14 марта на винте ежедневным
данным претензий у них нет (я просто не раскомментировал в скрипте строчку,
удаляющую файл после обработки - они так там и копятся :-)))

скока я на Ganjastats.ru не заходил,у меня постоянно всё по нулям,хотя в игре
каждый день(

101

Все в одной таблице? оО

Оптимизируй структуру, разбей по таблицам. Не храни повторяющиеся значения, если
за сутки параметры перса не изменились – это сократит темпы увеличения базы на
несколько порядков. И пройдись по существующим записям по тому же алгоритму.

Наример: http://ganjastats.ru/players/item/1308195 – зачем хранить динамику
набора экспы моего теха? :)

102, вы, вероятно, видите не себя, распространенная проблема. Сходите по ссылке
http://ganjastats.ru/907777

+103

А когда проблемы будут решены, все еж хотелось бы видеть статистику вцелом по
игрокам – например сколько % игроков с определенным оружием на моих левелах.

103, вот как раз только что сидел, перечитывал весь топ. Не создавать новую
запись, если ничего не изменилось - пожалуй, самая здравая идея. Мысль разбить
по таблицам по, скажем, месяцу - тоже крутая, она уже приходила мне в голову.
Выборки правда станут хитрее, но БД хоть не будет напрягаться. Она, правда, и
сейчас не очень-то напрягается, так что это решение можно реализовывать не
спеша.

105, кстати, надетые на персонажа шмотки экспортируются ежедневно, и эту
информацию я тоже бережно храню ))))

работает)значит нада пытаться и через ник смареть и через id)

106 структуру таблиц мона глянуть? если оч постараццо, то 50мб в день получится,
но откуда 26гб за 111 дней - непонятно

108, именно
109, вам в какой форме показать?

И я бы расширил блок адсенса – когда там выводятся не только категории, а
конкретные объявления, кликов будет больше.

111, вообще, когда я вешал адсенс, я надеялся не на грубую статистику из серии
"500 человек придет, один кликнет - и слава богам", а на сознательность
посетителей. Практика показала, что я глубоко заблуждался.

+112, но вообще эту тему не хотелось бы тут обсуждать )))

любой) лучше SHOW CREATE TABLE tbl или её аналог, если не mysql

112 На это не стоит рассчитывать. К тому же за такие клики в помощь ресурсу,
когда открывшуюся страницу тут же закрывают, гугл легко может забанить.

101: по своему опыту могу подсказать, что значительную часть данных можно
скинуть в файлы (по месту на жестком диске ведь анлимит?), а в sql хранить
только самые ценные данные, по которым делается выборка. может быть так
получится уменьшить объем хранимых в mysql данных?..

Опасаюсь, что если Вы возьмете vds или сервер в аренду, то рано или поздно mysql
просто упадет под таким объемом данных :) Даже здесь в sql не хранятся такие
объемы. :)

116, ну такой план и был, собственно. Скидывать куда-то (или просто дропать
совсем) старые данные, накопив некий архив. Выборка делается довольно тупо -
берется игрок и по нему JOIN'ом данные из той самой большой таблицы. Ну, иногда
не JOIN'ом, в общем, в таблице с данными есть колонка player_id, и дальше все
понятно. Структуру в данный момент разбирает Raiser )))

P.S. Зовут меня Коля, на Вы совсем не обязательно, а то, что MySQL упадет под
таким объемом мне кажется маловероятным, потому как ну не считаю я 28 гигабайт
большой БД. С таким приростом, который есть сейчас, и который было сразу видно -
порядков терабайта эта хрень не достигнет все равно еще какое-то время. Базу
перестраивать надо, я согласен. Однако, если внедрить, например, эту идею с
нехранением неизменившихся данных в ежедневный скрипт, этот скрипт сразу
перестанет выполнять свою функцию - потому что на каждого игрока ему надо будет
делать селект по той самой таблице, с целью сравнения. Сейчас он фигачит инсерты
по 1000 записей за итерацию, и в целом вся утренняя работа занимает у него по
полтора часа. Я повторюсь, я в отчаянии ))

ни черта не понимаю в програмировании, но и мне понятно, что если параметр не
изменился его записывать заново в таблицу не надо. Таким образом данных будет
поступать на 90% меньше)

118, да мне это тоже и без программирования понятно. Просто если я так буду
делать, импорт суточных данных будет заканчиваться к утру следующего дня, когда
они не просто устареют, как сейчас (за полтора часа) а безнадежно устареют )))

+119, там идея в том у меня, чтобы сделать тупо, но как можно быстрей.