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

нагрузка на мускул

Baranov_Dron

Новичок
нагрузка на мускул

пишу сайт. Одна из страниц сайта будет ложить свои в БД. Mysql. Выбор дефолтный...

Теперь вот в чём проблема.
Осуществляется два запроса. Первый поиск. Если ничего не нашёл, то осуществляется второй запрос. Запрос записи.

Казалось бы пустяк... НО! в минуту скрипт будет ложить по 1000 записей. И работать круглосуточно.

Теперь мои решения:
1)так и делать без дополнительных извращений
2)кидать в другую таблицу новые данные. и скрипт-демон уже будет кидать их в бд общую. Это для того чтобы сайт не ждал выполнения запросов...
3)тоже кидать в другую таблицу новые данные. и раз в час делать полный экспорт двух таблиц. стирать вторую таблицу. И дальше сравнивать файлы и не повторяющиеся строки заносить(я смогу сделать чтоб было так что одна строка была одна запись) в первую таблицу. Сравнение сделать средствами юникса.

Вот три мои идеи... Какую лучше применить?! или может у кого есть ещё лучшие идеи?!

Сервер у меня виртуальный для этой задачи, со следующей конфигурацией
CPU : 1000MHz
RAM : 256Mb
Disk: 25Gb
ОС : Fedora Core 5
 

dimagolov

Новичок
Определись все же с кол-вом записей которые в итоге получатся. Писать по 1000 записей в минуту это наверное в начале, когда все пусть, потом должно уже находить. Иначе это 43 млн. записей в месяц - не многовато ли?
 

Baranov_Dron

Новичок
спасиб, мне было лень подсчитать) ну 1000 это максиум! я специально исхожу из максиума...лучше пусть будет запас, чем нехватка ресурсов...

ну 43 да много, будет много отфильтрованных запросов позже. но думаю до 10 млн. записей дойдёт

-~{}~ 23.07.07 21:44:

Автор оригинала: MadGreen
не ложить а класть.
запрос запросу рознь
Нажмите для раскрытия...
хм) руссский подучить надо)
ну будет как я сказал первый запрос поиска. тоесть присутствует ли это данное уже. а потом в случае отрицательного результата. второй запрос. уже записи
 

MadGreen

meninweb
еще один любитель поразмышлять в форуме... опиши конкретную задачу, додумывать за тебя никто не будет.
и если тебе лень подсчитать то всем остальным будет лень думать
 

Baranov_Dron

Новичок
ну смысл таков:
после того как сайт будет написан, и запущен через месяц будет там 10 млн записей

и дальше будет добавление записей. очень много записей. максиум 1000 в минуту. записи добавляются по схеме
"первый запрос поиска. тоесть присутствует ли это данное уже. а потом в случае отрицательного результата. второй запрос. уже записи"
что создаст большую нагрузку на мускул!
и это нужно как то решить...
 

MadGreen

meninweb
ты можешь выделять элементарные сущности из своей глобальной задачи? что за сайт с количеством посетителей 1000 в минуту? или что будет туда долбится с такой частотой?
 

MadGreen

meninweb
24*60*1000=1 440 000 уникальных посетителей в сутки. я прав? если да - планы наполеоновские прямо скажем :)

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

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

dimagolov

Новичок
Автор оригинала: Baranov_Dron
онлайн игрушку пишу.
Нажмите для раскрытия...
уже теплее. это по идее будут данные об активных игроках.
во-первых их реально будет несколько сотен от силы, то есть INSERT-ы с переиндексацией проблемой не будут. SELECT-ы по такой таблице тоже не проблема, единственное что придется делать много это UPDATE, но они по неиндексированным полям тоже не должны быть проблемой.

ой. подумалось, что может захотеться делать SELECT ВСЕХ записей чтобы узнать где все, но так в лоб не получится скорее всего потому что трафика сильно много получится
 

dimagolov

Новичок
HraKK, может я и ошибаюсь, но если каждому игроку отдавать ежесекундно всю инфу про всех других то может получиться трафика больше, чем сервер сможет отдать, а клиент принять.
проблема даже не в абсолютном объёме в секунду, а в том, что он будет квадратично расти с ростом кол-ва клиентов, что быстро упрется в серверный канал.
нельзя забывать о том, что будет задержка и клиент физически чаще чем раз 2-3 секунды не сможет получать данные, обрабатывать их и отдавать свое новое положение обратно.
 
Beavis

Beavis

Banned
dimagolov
а зачем каждому посылать ПОЛНУЮ инфу о других персонажах?? это лишнее.. если грамотно выбрать кто о ком что должен знать - много трафика не получится
 

dimagolov

Новичок
Beavis, ну а я о чем:
~~~
ой. подумалось, что может захотеться делать SELECT ВСЕХ записей чтобы узнать где все, но так в лоб не получится скорее всего потому что трафика сильно много получится
 
zerkms

zerkms

TDD infected
Команда форума
dimagolov
т.е. ты у посетителей форума спрашиваешь - нужно ли тебе выбирать всё для всех или нет?
а в ТЗ заглянуть слабо?
 

neko

tеam neko
> Одна из страниц сайта будет ложить свои в БД.

лучше всех.
 

Zetruger

ivan.chistyakov.name
Baranov_Dron
подумай лучше как оптимизировать структуру БД
100% есть более выгодный вариант с точки зрения уменьшения INSERT/UPDATE запросов

опиши общий принцип будущей игры
это что типа вариация на тему БК?
 
Войдите или зарегистрируйтесь для ответа.
Сверху