Тёмная тема
- slava_mib
- Модератор
>Сначала 67781 логинов
Там было не 67781- даже не знаю каким местом ты читаешь. Я же писал:
>сделал всего миллион
>5млн
Так же чёрным по белому написано:
>где-то 10 млн записей
> Признавайся, где подтасовал результаты?
Jimnik, зачем оно мне? Весь код написан выше - ты можешь сам взять его и проверить, в чём проблема-то? Собственно, результат-то вполне ожидаемый. Ты же не думаешь, что известные СУБД писали такие дураки, что не сделали никаких оптимизаций?
Ну и, конечно, многое ещё зависит от структуры самой таблицы - если сделать просто в виде набора полей, то будет тупить дико даже на нескольких тысячах записей, если правильно поставить ключи - скорость выборки почти не будет зависеть от количества данных, будь их хоть десятки миллионов - для того ключи и придуманы, собственно.
> то проц выполняет всего то порядка 70000 операций сравнения
Jimnik, ты, помимо всего прочего, ещё и не знаешь как работают базы данных? Такая ситуация возможна только если одновременно два разработчика: разработчик СУБД и разработчик БД, были тупыми как пробка. В современных БД обычно идёт поиск по разного рода деревьям и бинарным ключам. Причём, ещё и возможностями хитрого связывания этих самых ключей - скажем, для того, что бы выборка по 5 ключам могла быть даже быстрее, чем выборка по 1 ключу.
>попахивая жульничеством.
Я Бы сказал, что это с твоей стороны скорее немного попахивает ламерством. Почитай немного о том, как работают современные базы данных, как они хранят эти данные, как индексируют, как работают, как хранятся ключи и как выполняется поиск по ним, в чём разница между поиском без ключей и поиском с ключами и т.д.
>100млн операций побайтового сравнения
Ну и ахиения ))) Порадовал, спасибо. Поеду теперь домой с хорошим настроением 
Jimnik
> как самарские провайдеры мешают качать с народ.ру.
никак, но скорость на нём ~0.01 кб/c и это факт.
slava_mib
> Там было не 67781- даже не знаю каким местом ты читаешь.
Миллион он просматривать при поске не будет, он дойдёт до искомой ID 67781, закончит поиск и выдаст результат.
> ты, помимо всего прочего, ещё и не знаешь как работают базы данных? ...
Если бы я не знал, как работают БД, то у меня не производился бы поиск для 30 млн регистраций быстрее 1мкс, за всего 25 операций сравнений строки.
Просто не могу понять, как получаются такие результы.
О СУБД я достаточно знаю, не могу понять, как работает конкретно у тебя.
Если даже ты и выставил ключи по IDу и логину, а СУБД сама создала в оперативке отсортированный по логинам массив указаелей на записи, то тогда почему так долго ищет.
Ну да ладно, хрен с ним, я хоть и потратил 3-4 часа на создание своего поиска, зато у меня ищет в сотни раз быстрее, неплохое дополнение защиты от DDoS атак, и лишним не будет - это точно.
Chipmunk
> это называется "индексация"
Ну, если только индексировать логины по возрастанию/убыванию, ну тогда другой вопрос, почему так долго ищет.
> он дойдёт до искомой ID 67781
Скорее всего он не "дойдёт" - поиск будет скорее всего по дереву, по первым двум символам сразу. Но это лишь предположение, врать не хочу.
> ну тогда другой вопрос, почему так долго ищет.
1. это не долго
2. это пхп
3. погрешность учёта времени - запуск от запуска результаты отличаются мин/макс чуть ли не вдвое
4. СУБД всё же ориентировано на общие случаи - оно не оптимизировано конкретно под данную задачу, просто многие моменты в ней предусмотрены, но это не значит оно должно работать со скоростью вручную прооптимизированного асма или плюсов.
В принципе, сделать реализацию на плюсах вопрос пяти минут (да-да, я в курсе, что это нереально и что на это надо минимум 2 дня). Если найдёшь как-нибудь эти 5 минут - можешь попробовать сделать реализацию через c-api и посмотреть на скорость - думаю, она будет заметно выше, но вряд ли в десятки раз. При этом, при разрастании БД/введении дополнительных полей и прочего, скорость сильно падать не будет. Но будет очень большое удобство в разработке/поддержке. Собственно, чем и хорошо использование СУБД.
slava_mib
> Скорее всего он не "дойдёт" - поиск будет скорее всего по дереву, по первым двум символам сразу. Но это лишь предположение, врать не хочу.
Какое дерево?
Какие первые два символа?
> Я Бы сказал, что это с твоей стороны скорее немного попахивает ламерством. Почитай немного о том, как работают современные базы данных,
Это тебе почитать бы про поиск в БД.
> 1. это не долго
20 с мелочью операций побайтового сравнения за 0.000448 секунды - это долго, хоть для пхп, хоть для чего.
> В принципе, сделать реализацию на плюсах вопрос пяти минут
> думаю, она будет заметно выше, но вряд ли в десятки раз.
Я уже писал, что сделал, потратил 3-4 часа, работает в сотни раз быстрее, если не в тысячи,
но у меня не в этом проблема, не в этом вопрос:
Я никак не могу понять, как у тебя поиск производится для миллиона регистраций - 0.000448 секунды, а для 10 миллионов за 0.001883/20=0.000094 секунды, т.е. в 0.000448/0.000094=4.766 (почти в 5) раз быстрее.
Видно там какой-то неизвестный мне алгоритм на "деревьях и бинарных ключах" это делает и мне это не дано понять.
> как у тебя поиск производится
Во-первых, это не у меня, а разработчиков mySQL.
Во-вторых, я могу лишь предполагать как. Например, могу сделать вот такое предположение: первый запрос долгий, т.к. вынуждает мускуль подтянуть ключи в память из файла, а дальше запросы работают быстрее, т.к. ключи для поиска уже в памяти. Но это не более чем тычок пальцем в небо.
> мне это не дано понять
Может быть так оно и есть, не знаю. Хотя вообще инфы о том, как в мускуле хранятся и работают ключи достаточно много. Правда, по большей части она относится к старым версиям - в 5ой версии, вроде как, многое переработано и доработано.
Ну а что касается самого поиска - в данном конкертном случае поиск по дереву кажется мне наиболее разумным. Если построить его по 1ому, 2ому и 3ему символу (а для логина они будут обязательны в любом случае). Три лукапа по такому дереву вполне можгут сократить поиск с 10кк записей до нескольких десятков, максимум сотен. Если кодировка символов 32битная, то вместо лукапа надо будет сделать бинарный поиск.
После поиска/лукапа сверяем длины записей. Те записи, длина которых совпадает с искомой, уже проверять по символам до первого несовпадения. В принципе, можно извращнуться и сделать ещё хеши для строк, проверяя сначала по ним, а потом уже непосредственно сравнивая.
В итоге вся процедура самого простого поиска должна вполне уложиться в 3-4 десятка строк на плюсах. Если вариант по сложнее - наверное, в 300-500. По крайней мере на вскидку мне кажется, что должно.
Ну и поиск, соответственно, в итоге должен получиться достаточно быстрым (хотя и скорость мускуля мне лично кажется боле, чем просто приемлемой).
Правда, стоит ожидать лагов в момент подтягивания самих записей с диска, потому что хранить их, наверное, стоит там + сделать кеширование. Но у тебя-то, я так понимаю, они в памяти лежат? Потому не актуально. По крайней мере если не проблема держать в памяти несколько ГИГАбайт инфы только ради одной лишь авторизации, то не актуально. Интересно, ты этот момент как-то обдумал? Какое решение в итоге нашёл?
Давайте вы будете о чем-то более интересном ругаться.
Так мы не ругаемся ) А обсуждать в этом топике больше, вроде, и нечего особо, кроме темы "как сделать миллиард авторизаций в секунду" )))
slava_mib
Ну, так может стоит тогда начать пользоваться одним из главных правил gamedev-а:
Если нечего писать (обсуждать), не пиши.
Ну мы же нашли тему, значит есть чего )
К тому же этот бессмысленный и беспощадный топик держим наверху - хоть бы спасибо сказал мне за это )
Это у тебя прямо оговорка по Фрейду.
Потому что бессмысленные и беспощадные (прямо в точку попал) - это как раз твои посты в этом топике, да и в двух других моих темах.
Правда, беспощадные они только с той стороны, с какой ты их создавал, т.к. с моей они выглядят, скорее, глупыми, ни чем не обснованными нападками.
Посмотрел последнюю демку. Съиграл в шахматы. Есть одно замечание, очень плохое освещение (в том смысле, что плохо видно фигуры и не ясно где какая).
Bishop
См. тему, не в одном месте написано, что графикой пока не занимался, пока делаю механику, графика будет в конце.
Сделана игра в Бридж (пока без сети).
Посмотрите!
Как вам Бридж?
Как вам медиа-плеер с рендерингом видео на заднем фоне?
Сделана игра в Покер (пока без сети).
Посмотрите!
Как вам Покер?
Надеюсь, Бридж и Покер не являются слишком сложными для gamedev-овцев играми.
Как всегда жду ваших любезных комментариев.
Jimnik
> Надеюсь, Бридж и Покер не являются слишком сложными для gamedev-овцев играми.
продолжай тешить своё ЧСВ.
Бридж в сингле вообще неинтересен, покер просто скучен, играть без сети никто не будет.
Тема в архиве.