Очередной вопрос о выборе скрипта

Xrenoder писал:

Да в общем это все ничего принципиально не меняет. Изначально модель "мускль + внешние вычисления" проигрывает модели "специализированая база + интегрированые в нее вычисления" по любому параметру, кроме "простоты модернизации" (причины я выше изложил, и это только первостепенные), поэтому шареная память и юзание крона ситуацию не спасут.

Ты опять прав конечно, но замечу, что проблемы загруза при правильной организации алгоритмов и данных я не вижу. Я как то наблюдал рабочую систему, выполняющую 800 MySQL запросов в секунду. Это не сидж был, вообще не адалт. И ничего не тормозило. У меня просто нет такого трафика. Максимум что я вижу - 20 запросов в секунду.

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

была с авторой такая же ситуация ...
Советую Протон от Kildoozerа ;) 2 недели пока стоит и отношение создателей к своему софту радует ;)

Phoenix66 писал:

Ты опять прав конечно, но замечу, что проблемы загруза при правильной организации алгоритмов и данных я не вижу. Я как то наблюдал рабочую систему, выполняющую 800 MySQL запросов в секунду. Это не сидж был, вообще не адалт. И ничего не тормозило. У меня просто нет такого трафика. Максимум что я вижу - 20 запросов в секунду. Проблему я вижу в нахождении правильного алгоритма трейда. Причем, что хуже всего, заметил я такое дело, что один и тот же алгоритм может трейдить хорошо, а может плохо, в зависимости от того, что за алгоритм используют трейдеры. И вот как с этим бороться - не знаю.

Ага, мускуль главное с умом юзать. У меня в среднем 200 запросов в секунду сейчас на мускуле - вообще ничего не тормозит. При тех же скриптах, думаю и 2000 запросов легко вытянет. Просто действительно используется shared память с умом для реалтайм операций. Ведь сейчас главное в производительности - это система ввода-вывода, то бишь жесткие диски. А процессоры уже настолько развиты, что такие замедляющие вещи как парсинг mysql сервером sql запроса выполняется настолько быстро и без проблем для современных процессоров, что это можно не учитывать, говоря о производительности. С быстрым процессором даже мой скрипт на мускуле, имхо, больше трафа вытянет, чем скрипт типа ucj, который использует исключительно файловую базу, так как этот скрипт быстрее упрется в производительность жеских дисков, так и не использовав в полной мере производительность процессора.
Кстати, сейчас дописывается мой CJ скрипт, который называется Fast Traffic Trader и в котором все реалтайм операции исключительно в памяти. Кроме того, там расчет ведется по крону и тем не менее он абсолютно точный ( не переливает мелким трейдерам). Несколько алгоритмов, огромное количество фич и т.д. Стараюсь сделать его лучшим среди всех платных скриптов. Он будет платным, но через пару недель нужны будут бета-тестеры, которые могут получить скрипт по очень низкой цене, так что если топикстартер может подождать - это будет лучшим выбором для него, имхо Там, к тому же, специальная заточка под использование на нескольких сиджах этого скрипта - они будут обмениваться данными о сюрферах.

Запрос запросу рознь.
Поиск данных - это одно. Изменение данных - это совсем другое.
Запрос в пределах одной таблицы и объединение таблиц - тоже немножко разное по ресурсам занятие.
И главное, что тормозит базы - это блокировки данных, защита от одновременного доступа.
Тормозят блокировки.
Мускль не знает, какие данные когда могут меняться, поэтому вынужден делать полную блокировку в любом случае. А это значит, что конкурентные запросы будут выстраиваться в очередь, если запрос сложный. А очередь на блокировке сама по себе сильно ресурсы жрет, поскольку системе надо следить за тем, чтобы как можно быстрее ее раскидать.
И чем сложнее структура данных, тем блокировок больше плюс время работы с данными больше (причем не в разы, а на порядки).
Вот так и получается, что при фантастической мощности процессора и скорости обмена данными, мы со своими смехотворными задачами можем загрузить сервер по самое небалуйся.
Так что фраза "а мой мускль держит тыщу запросов" - абсолютно ничего не значит, потому что непонятно, что это за запросы.
Отсюда еще один плюс специализированой базы - поскольку заранее известен регламент работы с данными, то блокировки все можно оптимизировать до предела, во многих случаях вообще обойтись без них на тех участках, где конкурентный доступ не планируется, в каких-то местах делать короткую блокировку с копированием данных ну и т.д.

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

SeRsH: добро пожаловать в клуб разработчиков лучших на свете сиджей Ты ф сотне и нийбет

Phoenix66 писал:

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

В феврале уж три года (или 4), как я этот проклятый "правильный алгоритм" ищу

Xrenoder писал:

Запрос запросу рознь. Поиск данных - это одно. Изменение данных - это совсем другое. Запрос в пределах одной таблицы и объединение таблиц - тоже немножко разное по ресурсам занятие. И главное, что тормозит базы - это блокировки данных, защита от одновременного доступа. Тормозят блокировки. Мускль не знает, какие данные когда могут меняться, поэтому вынужден делать полную блокировку в любом случае. А это значит, что конкурентные запросы будут выстраиваться в очередь, если запрос сложный. А очередь на блокировке сама по себе сильно ресурсы жрет, поскольку системе надо следить за тем, чтобы как можно быстрее ее раскидать. И чем сложнее структура данных, тем блокировок больше плюс время работы с данными больше (причем не в разы, а на порядки). Вот так и получается, что при фантастической мощности процессора и скорости обмена данными, мы со своими смехотворными задачами можем загрузить сервер по самое небалуйся.

Ну так в том-то и дело, что нужно проектировать так базу, чтобы реалтайм операции были быстрыми и чтобы конкурентные запросы не ждали своего часа. Ну что может затормозить, скажем, такую операцию как insert в оперативную память?

Цитата:

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

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

Цитата:

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

Непонятно, в чем же тут плюс. Регламент работы с данными на мускуле тоже известен. Там тоже можно все оптимизировать. Я, например, в скрипте крона данные из одной heap таблицы (куда пишутся данные в реалтайм) копирую в другую временную heap таблицу, удаляю данные из первой таблицы и это идет как одна транзакция ( то есть таблицу блокирую на время операции чтения и удаления данных, чтобы была точная статистика). Копирование из памяти в память вообще очень быстрая операция. А дальше уже удут "сложные" запросы в кроне ко вновь соданной временной таблице для расчета трейда.
А еще - индексы - очень приятная вещь в мускуле, если правильно пользоваться. Они же все в памяти находятся, да еще и оптимизированы в виде B-tree. Поиск того же ip адреса в базе произойдет на порядок быстрее в мускуле, чем в базе собственного производства без индексов. Мускуль фактически при правильном использовании - это самый оптимальный daemon, который ты, Xrenoder, зачем-то написал сам для своего сиджа, изобретя велосипед.

Цитата:

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

Ага, про heap таблицы мы не слышали?

Цитата:

SeRsH: добро пожаловать в клуб разработчиков лучших на свете сиджей Ты ф сотне и нийбет

Спасибо!

Кстати, еще насчет блокировок - видимо многие не знают, но мускуль позволяет производить несколько SELECT запросов и один INSERT над одной таблицей одновременно! Куда уж еще оптимизировать блокировки?
Кроме того, там есть еще INSERT DELAYED.
Видимо, просто многие не знают всех возможностей мускуля и начинают изобретать велосипеды.

SeRsH, ну ты прям обижаешь меня. Ну кто ж тебе сказал, что я не знаю про heap-таблицы и что у меня данные в демоне не индексированы?
Ты еще скажи, что я их пузырьковым методом сортирую. Давай, оскорбляй меня, сеть все стерпит.
Один инсерт в таблицу в момент времени - это конечно круто
Вот это я и называю "неоптимизироваными блокировками"

Извини, если обидел!
Про то, что у тебя данные в демоне не индексированы я не говорил. Просто про heap таблицы как вариант уже готового решения использования shared memory без всяких memory leaks ты почему-то даже не заикнулся.

А сколько инсертов должно быть в момент времени?

SeRsH писал:

Извини, если обидел! Про то, что у тебя данные в демоне не индексированы я не говорил. Просто про heap таблицы как вариант уже готового решения использования shared memory без всяких memory leaks ты почему-то даже не заикнулся. А сколько инсертов должно быть в момент времени?

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

Насчет инсертов - ошибся в горячке боя. Инсерт, конечно один в момент времени. Я имел в виду изменение содержания таблицы.
Вот их при "оптимизированой блокировке" может быть в момент времени ровно столько, сколько в таблице записей.
Количество же запросов поиска одновременных вообще может быть неограниченым - максимум, что может случиться, что запрос придется выполнить повторно, если по ходу его был выполнен инсерт. Зная, что инсерт в базе сиджа есть явление достаточно редкое, это вполне допустимый компромисс, который сильно разгружает базу.

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

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

Xrenoder писал:

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

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

Цитата:

Насчет инсертов - ошибся в горячке боя. Инсерт, конечно один в момент времени. Я имел в виду изменение содержания таблицы. Вот их при "оптимизированой блокировке" может быть в момент времени ровно столько, сколько в таблице записей. Количество же запросов поиска одновременных вообще может быть неограниченым - максимум, что может случиться, что запрос придется выполнить повторно, если по ходу его был выполнен инсерт. Зная, что инсерт в базе сиджа есть явление достаточно редкое, это вполне допустимый компромисс, который сильно разгружает базу. Опять же в специализированом демоне можно банально сократить число необходимых запросов за счет того что вычисления можно производить по ходу выполнения запроса, не разделяя эти два процесса. Елки, ну как будто не известно, что в общем случае специализированый инструмент выполняет свою задачу лучше, чем универсальный

Ну само собой! Вопрос в том, насколько это оправдано

SeRsH писал:

Ага, но при использовании heap таблиц, ошибка должна быть в mysql сервере для утечки. А какова вероятность, что в стабильной версии mysql, которая активно юзается на тысячах серверов есть такая ошибка, при том, что пользователи не сообщают о таковой? Ну само собой! Вопрос в том, насколько это оправдано

Да не, речь не про утечку в мускле, а про утечку в shared памяти, если рассматривать вариант с ее использованием, который Stek предложил.
Это вроде как альтернатива мусклю обсуждалось тоже.
Т.е. данные лежат там, каждая пхп-сессия, блокируя участки семафорами, туда пишет-оттуда читает, все щасливы, никаких демонов.
Либо я идею не понял?

Ааа, это значит я не понял

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

если серьёзно то всем ответившим спасибо, решил остановиться на протоне. всех высказавшихся по теме оценил.

вставлю свой каммент =)

ттт - фришный - держал 130к , без глюкоф - правда трейдил криво =)
изи сидж - платный, но я достал на халяву за пять кнопок =) - держал 380к , трейдил карашо ...

Fet я думаю будет оптимальный вариант, все понятно, админка удобная, траф держит нормально
http://fetcj.com/ru/