прошу совета по работе с базой данных

[phpNovicee]

прошу совета по работе с базой данных

Есть база, в ней таблица, содержащая довольно большое кол-во рекордов с 10ю полями.

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

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

И вот тут я прошу совета, как бы вы решили данную задачу?

На ум приходят следующие варианты ответа:
- тупо удалить все рекорды и создать новые с нужными полями
- запросить рекорды из базы. отсутствующие в инфе с клиента - удалить, отсутствующие в базе - создать, по остальным - сделать цикл с проверкой на то, какие конкретно поля изменились и сделать апдейт.

 

[grigori]

как ты делаешь сейчас и что тебя беспокоит?

-~{}~ 17.06.09 12:47:

>как бы вы решили данную задачу
если для результата разницы нет - самым простым (быстрым в написании) способом
правда, в "цикле с проверкой на то, какие конкретно поля изменились" толку мало, проще replace

 

[phpNovicee]

если для результата разницы нет

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

 

[baev]

http://yandex.ru/yandsearch?text=контроль+версий&stpar2=/h1/tm816/s3&stpar4=/s3&stpar1=/u1&stpar3=/m1/tc15/nc1

 

[phpNovicee]

Автор оригинала: baev
http://yandex.ru/yandsearch?text=контроль+версий&stpar2=/h1/tm816/s3&stpar4=/s3&stpar1=/u1&stpar3=/m1/tc15/nc1

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

 

[al_mt]

Если каждая запись - массив с заранее неизвестным числом полей, то логично сохранять их в поле типа LONGTEXT в сериализованном виде.
Это действие мгновенное, структуру таблицы на ходу перекорёживать не надо.
Единственный минус - организовывать поиск в такой таблице неудобно, значит если потом потребуется быстрый поиск, то нужно будет делать индексные таблицы с рассортированными данными.

 

[phpNovicee]

Автор оригинала: al_mt
Если каждая запись - массив с заранее неизвестным числом полей, то логично сохранять их в поле типа LONGTEXT в сериализованном виде.
Это действие мгновенное, структуру таблицы на ходу перекорёживать не надо.
Единственный минус - организовывать поиск в такой таблице неудобно, значит если потом потребуется быстрый поиск, то нужно будет делать индексные таблицы с рассортированными данными.

спасибо. по-моему, это здраво )) а над индексом для поиска пусть трудится отдельный процесс.

 

[partizan]

А отправлять с клиета только измененные данные никак?

 

[phpNovicee]

Автор оригинала: partizan
А отправлять с клиета только измененные данные никак?

ну тут уже стоит вопрос, что если таких действий в минуту производится МНОГО (скажем раз в 3-4 секунды выполняется отдельное действие, о котором надо сообщить на сервер), то сервер ляжет гораздо быстрее, чем если мы будем сохранять результаты действий раз в минуту.

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

 

[prolis]

Re: прошу совета по работе с базой данных

Автор оригинала: phpNovicee
каждую минуту приходит массив с актуальными данными

Ага, раз в минуту перелопатить весь массив сервер не ляжет, а по одному запросу раз в 4 секунды - ляжет.
Не мудрите, раз назвали динамическим интерфейсом - делайте его динамическим. AJAX.

 

[phpNovicee]

Re: Re: прошу совета по работе с базой данных

Автор оригинала: prolis
Ага, раз в минуту перелопатить весь массив сервер не ляжет, а по одному запросу раз в 4 секунды - ляжет.
Не мудрите, раз назвали динамическим интерфейсом - делайте его динамическим. AJAX.

ну как тут уже сказали -- проапдейтить лонгтекст в базе действие почти мгновенное. не сильно медленнее апдейта одного поля... тут же ещё надо учесть накладные расходы на само соединение. 15-20 запросов в минуту сильно дороже одного.

 

[Yuriy_S]

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

 

[phpNovicee]

Автор оригинала: Yuriy_S
15-20 запросов в минуту - это ерунда..
у меня сервак терпит тысячи запросов в секунду, и ничего.. справляется, все нормально работает.

это запросы на чтение или на запись? разные вещи... к тому же респонзы на чтение можно очень эффективно кэшировать.

понятно, что 15-20 запросов в минуту ерунда, но по тз у меня стоит пик в 1000 конкурентных пользователей -- сервак должен держать. т.е. 1000 пользователей должны суметь одновременно работать с интерфейсом.

 

[Yuriy_S]

у меня запросы select, update, insert, delete - работает поисковый робот, индексация новых ресурсов и обновление базы..

Если у тебя планируется пик в 1000 пользователей, то судя по твоим словам, будет выполняться порядке 15000-20000 запросов в минуту.. в секунду в среднем от 300 до 350 запросов, при идеальных условиях и равномерной нагрузке.
Здесь конечно же, необходимо использовать транзации (движок Innodb), т.к. при апдейтах и инсертах они работают в разы быстрее, чем тот же MyISAM и обычной очередью запросов.
Если сервак с mysql очень мощный, то потянет.
А вообще, в таких случаях стоит пересмотреть архитектуру проекта, структуру базы.

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

 

[zerkms]

но по тз у меня стоит пик в 1000 конкурентных пользователей

epic fail

 

[phpNovicee]

Автор оригинала: zerkms
epic fail

поясните. в чём тут прокол?

 

[zerkms]

phpNovicee
ты задаёшь слишком глупые вопросы, чтобы быть способным написать приложение, выдерживающее 1000h/s

 

[phpNovicee]

Автор оригинала: zerkms
phpNovicee
ты задаёшь слишком глупые вопросы, чтобы быть способным написать приложение, выдерживающее 1000h/s

А ты слишком глуп, чтобы быть способным отличить работу 1000 пользователей от 1000 запросов в секунду. Я только начинаю изучать программирование и это не скрываю, а ты мнишь себя гуру и не можешь дать советы по "глупым" вопросам? Epic fail.

 

[Yuriy_S]

phpNovicee
zerkms знает, о чем говорит, уж поверь.

а в данном случае, ты вместо того, что бы слушать и внимать - пишешь какие-то свои доводы и выводы, ни на чем не основанные

Я только начинаю изучать программирование и это не скрываю

поэтому, лучше опиши свою задачу более четко, иначе тебе никто не сможет тут помочь

-~{}~ 18.06.09 13:57:

phpNovicee
при 1000h/s запросов будет больше тысячи в секунду.. даже намного больше.. если, конечно, вся страница не кешируется.

 

[phpNovicee]

приношу извинения zerkms, я был слишком резок. задачу опишу попозже.