Вернуться   Форум SAPE.RU > Общие вопросы > Разработка и сопровождение сайтов

-->
Ответ
 
Опции темы
Старый 01.08.2009, 14:27   #11
Мне повезёт!
 
Аватар для Alexey
 
Регистрация: 05.05.2007
Сообщений: 1,076
Вес репутации: 214
Alexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущее
По умолчанию

Последний Герой, пожалуй да. У вас, в общем-то, грамотно описано, я лишь хочу сказать, что можно сделать идеологически то же самое, но проще:

Из мануала:
Цитата:
Транзакция - это группа последовательно выполняемых операторов SQL, которые либо должны быть выполнены все, либо не должен быть выполнен ни один из них. Главная задача транзакций - обеспечить целостность данных в случаях, когда несколько SQL-операторов выполняют зависящие друг от друга изменения данных. Классический пример, приводимый, наверно, во всех учебниках по базам данных - перевод денег с одного счета на другой:

UPDATE accounts SET AccSum = AccSum - 1000 WHERE AccNumber = 12345;
UPDATE accounts SET AccSum = AccSum + 1000 WHERE AccNumber = 67890;
Но нам не надо последовательно ничего вычислять. Нам достаточно, чтобы "прошел" оператор
Код:
UPDATE `table` SET
              `handler`=<идентификатор текущего процесса>
WHERE 
              `handler` is NULL AND
              `is_processed` = 0
LIMIT 1
который и без транзакций атомарен, и потому конфликтов не будет, даже на MyISAM.

А если нет разницы, то зачем платить больше! ;-)
__________________
Everything will be great in the end.
If it's not great, it's not the end.
Alexey вне форума   Ответить с цитированием
Старый 01.08.2009, 14:42   #12
Магистр
 
Аватар для Йода
 
Регистрация: 04.12.2007
Сообщений: 3,674
Вес репутации: 354
Йода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Последний Герой Посмотреть сообщение
2) как только какой то поток хочет обратиться к строкам, он записывает в столбец свой айди, с условием, что столбец равен нулю (примерно так UPDATE SET столбец=айди WHERE столбец=0)
3) далее он считывает столбец, если блокировку удалось установить, то в столбце написан его айди (иначе там либо 0 либой айди другого процесса)
4) если блокировки нет, то возвращаемся к шагу 2
5) если блокировка есть, то можно считать, что строки заблокированы и выполнять с ней любые махинации
6) снимаем блокировку, записывая в столбец 0
Не прокатит. Пока первый ставил и считывал второй мог паралельно переставить, ибо тоже думал что она пустая. Подумай еще раз. Или я не прав?
__________________
С уважением, Йода
Йода вне форума   Ответить с цитированием
Старый 01.08.2009, 14:47   #13
Bannеd
 
Регистрация: 17.09.2008
Сообщений: 6,447
Вес репутации: 307
Последний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Йода Посмотреть сообщение
Или я не прав?
не прав. как только один поставил, второй уже не может поставить, ибо
Цитата:
Сообщение от Йода Посмотреть сообщение
UPDATE SET столбец=айди WHERE столбец=0
но тут вопрос, какому из них удалось поставить. ответ:
Цитата:
Сообщение от Йода Посмотреть сообщение
3) далее он считывает столбец, если блокировку удалось установить, то в столбце написан его айди (иначе там либо 0 либой айди другого процесса)
Последний Герой вне форума   Ответить с цитированием
Старый 01.08.2009, 14:48   #14
Магистр
 
Аватар для Йода
 
Регистрация: 04.12.2007
Сообщений: 3,674
Вес репутации: 354
Йода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Alexey Посмотреть сообщение
Для оптимизации можно резервировать по 10-30 записей за раз, тогда будет меньше накладных расходов на обращение к БД.

Для легкого добавления обработчика сделайте это поле, например, строковым и пишите туда не число, а типа `mycomputer-1` и т.д. В общем, неймспейсы
Насчет группового резерва- да, мысль. Спасибо.
Насчет строкового поля- не-не-не. Таблица- миллион строк. тяжелых. Я буду писать туда текст и еще потом искать по нему? Не. Смерть..


Последний Герой, InnoDB не катит, ибо у транзакционных тейблов производительность на порядок ниже MyISAMовских.

Вариант с тем, чтоп лочить всю тейблу - тоже вариант, но только до тех пор пока обработчиков мало. А станет много- начнется сплошная битва. Матрица, блин

Склоняюсь к идее со схемой предиктор-корректор- когда добавлятор добавляет строки в тейблу с же прописанным признаком обработчика, а обработчик будет давать обратную связь о скорости своей работы- тада добавлятор будет равномерно раскидывать строки в зависимости от скоростей обработчиков. Типа идеально. Однако, как и обработчиков, добавляторов - несколько. И они равноправны. Отсюда рождается диспетчер.
Типа никак не получается создать саморегулирующуюся децентрализованную структуру
__________________
С уважением, Йода
Йода вне форума   Ответить с цитированием
Старый 01.08.2009, 14:52   #15
Bannеd
 
Регистрация: 17.09.2008
Сообщений: 6,447
Вес репутации: 307
Последний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Йода Посмотреть сообщение
ибо у транзакционных тейблов производительность на порядок ниже MyISAMовских.
на чтение ниже, на запись выше
то что я предложил снизит производительность и для майисама
Последний Герой вне форума   Ответить с цитированием
Старый 01.08.2009, 14:54   #16
Магистр
 
Аватар для Йода
 
Регистрация: 04.12.2007
Сообщений: 3,674
Вес репутации: 354
Йода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Последний Герой Посмотреть сообщение
не прав. как только один поставил, второй уже не может поставить, ибо
Цитата:
Сообщение от Йода Посмотреть сообщение
UPDATE SET столбец=айди WHERE столбец=0
Вот сматри:
есть два обработчика О1 и О2. Оба нашли свободную строчку- и ломятся ее сначала зарезервировать (тоесть как раз UPDATE SET столбец=айди WHERE столбец=0 ) а потом сделать контрольный Селект, так?
Может получится, что О1 и О2 делают апдейт. Естессно- ктото успевает первым (пусть О1). Второй апдейт ждет. О1 сделал апдейт и делает селект (селект не ждет) - считывает свое только что установленное значение и свято верит что строчка им залочена. После этого доходит очередь до апдейта О2 и последующего егоже селекта. В результате оба верят что строчка залочена именно им.

Тут играет роль приоритетность селекта и апдейта. В принципе это в mysql настраивается, но все равно выглядит это както хлипко..

Добавлено через 1 минуту
Цитата:
Сообщение от Последний Герой Посмотреть сообщение
на чтение ниже, на запись выше
то что я предложил снизит производительность и для майисама
угу.. ну это естессн..
__________________
С уважением, Йода

Последний раз редактировалось Йода; 01.08.2009 в 14:54. Причина: Добавлено сообщение
Йода вне форума   Ответить с цитированием
Старый 01.08.2009, 15:03   #17
Bannеd
 
Регистрация: 17.09.2008
Сообщений: 6,447
Вес репутации: 307
Последний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущееПоследний Герой - прекрасное будущее
По умолчанию

Цитата:
Сообщение от Йода Посмотреть сообщение
после этого доходит очередь до апдейта О2
он не может сделать апдейт, ибо в условии стоит WHERE столбец=0, а там уже вместо 0 число айди стоит. запрос UPDATE ... WHERE ... всегда выполняется монопольно.
Цитата:
Сообщение от Йода Посмотреть сообщение
считывает свое только что установленное значение
ну да, раз оно установлено, оно не изменится, пока он его сам не обнулит
Последний Герой вне форума   Ответить с цитированием
Старый 01.08.2009, 15:09   #18
Магистр
 
Аватар для Йода
 
Регистрация: 04.12.2007
Сообщений: 3,674
Вес репутации: 354
Йода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущееЙода - прекрасное будущее
По умолчанию

Последний Герой, звучит здраво. Надо будет примерить.. Сыпасибо!
__________________
С уважением, Йода
Йода вне форума   Ответить с цитированием
Старый 01.08.2009, 16:38   #19
Мне повезёт!
 
Аватар для Alexey
 
Регистрация: 05.05.2007
Сообщений: 1,076
Вес репутации: 214
Alexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущееAlexey - прекрасное будущее
По умолчанию

Йода, хорошо, развиваем мысль.

Значит задача - сделать децентрализованную систему. И, желательно, простую (да, люблю я простоту. Считаю что все гениальное - просто).

Делаем MEMORY таблицу с одним единственным AUTO_INCREMENT полем (хранится в памяти, на 1 запись тратится длина, равная sizeof(int), выборки и вставки ультра быстрые).

Обработчик при своем запуске делает в нее INSERT, и забирает свой идентификатор через LAST_INSERT_ID(). Таким образом, мы получаем уникальные непересекающиеся числовые идентификаторы для каждого процесса, которые не будут сохраняться на диск.

В памяти это будет занимать намного меньше места, чем любой диспетчер, ибо диспетчеру все равно надо хранить список обработчиков.
__________________
Everything will be great in the end.
If it's not great, it's not the end.
Alexey вне форума   Ответить с цитированием
Старый 01.08.2009, 17:31   #20
Новичок
 
Регистрация: 29.01.2009
Сообщений: 83
Вес репутации: 126
Vile7xD - весьма и весьма положительная личностьVile7xD - весьма и весьма положительная личность
По умолчанию

Быстрее будет так-то один обработчик и кормить его пачкой строк, если конечно это не удаленно делается, хотя с этим тоже можно справиться.
Vile7xD вне форума   Ответить с цитированием
Ответ

Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Помогите решить проблему . Jenya Курилка 7 04.01.2009 11:27
Помогите решить проблему с MSN Chervechok Курилка 2 12.12.2008 02:26
Помогите решить проблему! yan21 Яндекс 3 20.11.2008 13:08
помогите решить проблему ncx Курилка 24 04.08.2008 20:01
Помогите решить проблемы ara Вопросы по работе системы 5 30.04.2007 22:45


Часовой пояс GMT +3, время: 14:51.