forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Bullet Cache - высокопроизводительная система кэширования да..., opennews (??), 18-Окт-11, (0) [смотреть все]

Очень хорошо И то что нужно Библиотек теперь бы по больше Где можно почитать пр, Аноним (-), 13:08 , 18-Окт-11, (1)
Миллион tps - это просто отличный результат , Erley (ok), 13:13 , 18-Окт-11, (2) //

Отличный от чего В какую сторону С чем сравнивалось , Аноним (-), 13:21 , 18-Окт-11, (6) //

Попробуйте сами сделать что-то подобное Я такое делал, скажу вам что это challe, Erley (ok), 13:39 , 18-Окт-11, (7)

Человек оринетируется на скорость и тащит текстовый SQL-подобный протокол Приме, Crazy Alex (ok), 13:13 , 18-Окт-11, (3) //

MySQL такой медленный потому что использует SQL-синтаксис Внезапно , Аноним (-), 13:15 , 18-Окт-11, (4) +5 //

Внезапно, при выборке по первичному ключу аналог key-value у японцев получалос, Crazy Alex (ok), 13:19 , 18-Окт-11, (5) –2 //

Что-то мне подсказывает, что производительность упиралась вовсе даже не в разбор, Аноним (-), 13:40 , 18-Окт-11, (8)

Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде Идём , Crazy Alex (??), 14:11 , 18-Окт-11, (10) –1

А я не спорю, что MySQL может тормозить на разборе SQL, но в MySQL парсер не эта, Аноним (-), 14:17 , 18-Окт-11, (11)

Не знаю, насколько он там не эталонный, но мой опыт подтверждает то, что лукап п, Crazy Alex (ok), 14:47 , 18-Окт-11, (15)

Тут речь идет о миллионе транзакций в секунду Если у mysql что то во что то упир, Аноним (-), 15:10 , 18-Окт-11, (19)

Prepare Statement ВНЕЗАПНО , опроро (?), 14:34 , 18-Окт-11, (12)

Может, прочтёте о чём вообще речь А речь о том, что в шустром кеше делать SQL-п, Crazy Alex (ok), 14:43 , 18-Окт-11, (13)

facepalm Ещё раз Распарсить много мегабайт чьего-бы то ни было синтаксиса - пл, Аноним (-), 15:30 , 18-Окт-11, (20)

Плёвое дело по сравнению с чем В запросом к диску - да сколько угодно С генера, Crazy Alex (??), 15:52 , 18-Окт-11, (24)

Объясни как ты себе представляешь работу MySQL На примере PHP я представляю при, Аноним (-), 16:12 , 18-Окт-11, (26) +2

Если там есть хоть какие-то сложные запросы - нет, конечно См японцев с Handle, Crazy Alex (??), 16:16 , 18-Окт-11, (29)

До тебя никак не дойдёт, что скорость поиска зависит от реализации Неужели ты д, Аноним (-), 16:30 , 18-Окт-11, (30)
Я уже глянул в исходниках - нет там текстового синтаксиса, это дурной перевод Е, Crazy Alex (ok), 17:11 , 18-Окт-11, (33)
Ок Но вообще говоря, лишний memcpy вполне сойдёт Сколько их происходит при сло, Аноним (-), 17:28 , 18-Окт-11, (35)
О memcpy я речь вёл в контексте именно кэша, там вообще работы с диском нет, как, Crazy Alex (ok), 17:47 , 18-Окт-11, (36)
Нужно ещё понимание работы RDMS , Грустный Анон (?), 16:54 , 18-Окт-11, (32) +2

люди реально думают что базы данных данных настолько тупые насколько они умные , опроро (?), 15:31 , 18-Окт-11, (21)

Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache нет - им, Crazy Alex (??), 16:12 , 18-Окт-11, (27) +1

Просто в новости перевод кривой , Crazy Alex (??), 16:13 , 18-Окт-11, (28)

ну я ответил по поводу HandlerSocketкак я понял там жаловались на медленный парс, опроро (?), 20:11 , 18-Окт-11, (39)

http msdn microsoft com en-us library aa260835 aspx -- см там раздел The so, Аноним (-), 20:04 , 18-Окт-11, (37)

Речь идёт о том что вы не умеете читать, и там нет никакого SQL , Аноним (-), 22:57 , 18-Окт-11, (42)

Оставь Нельзя сложно программиста php убедить в том что ассемблер суммирует б, Аноним (-), 14:44 , 18-Окт-11, (14)

Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный , Crazy Alex (ok), 14:49 , 18-Окт-11, (16)

Вряд ли Напиши новость что в Debian что-угодно внедрили инновацию и каждую кома, Аноним (-), 14:52 , 18-Окт-11, (17)

Так на одного крикуна тысяча тех, кто молчит и читает , Crazy Alex (??), 15:43 , 18-Окт-11, (23) +3

Я не могу говорить конкретно за MySQL, однако, мне приходилось работать тестиров, Школьник (ok), 22:16 , 18-Окт-11, (40)

А что уж сразу не британские ученые Тут же прямо сказано SQL подобный синтакисис, Аноним (-), 15:07 , 18-Окт-11, (18)

Ну и откуда сие недоверие Методика тестов, патчи, результаты - у них всё открыт, Crazy Alex (??), 15:42 , 18-Окт-11, (22)

Классический пример слышал звон, да не знаю где он - основная нагрузка, за иск, Грустный Анон (?), 16:48 , 18-Окт-11, (31) +2

Смеётесь Нет там никакой нагрузки на планировщик при выборке по первичному ключ, Crazy Alex (ok), 17:13 , 18-Окт-11, (34)

Тьфу, зря только ругался с неграмотными людьми Скачал исходники, глянул - никак, Crazy Alex (??), 16:03 , 18-Окт-11, (25) +3 //

Да Да Только все сразу поняли о чем речь а вы нет , Аноним (-), 20:10 , 18-Окт-11, (38) –3 //

Вы первоначальный текст новости не застали , Crazy Alex (ok), 01:48 , 20-Окт-11, (43)

Библиотеки под Python пока нет http mdcached svn sourceforge net viewvc mdcach, Аноним (-), 23:06 , 20-Окт-11, (44)

Сообщения [Сортировка по времени | RSS]

5. "Bullet Cache - высокопроизводительная система кэширования да..." –2 +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 13:19

Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).

Ответить | Правка | Наверх | Cообщить модератору

8. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 13:40

> Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).
Что-то мне подсказывает, что производительность упиралась вовсе даже не в разбор SQL. Куда более сложный многомегабайтный PHP-код с кучей инклудов парсится (только парсится, без выполнения) быстрее в разы сотни-другой байт SQL-запроса, который при выполнении так нагружает базу.

Ответить | Правка | Наверх | Cообщить модератору

10. "Bullet Cache - высокопроизводительная система кэширования да..." –1 +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 14:11

Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.

Ответить | Правка | Наверх | Cообщить модератору

11. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 14:17

> Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.
А я не спорю, что MySQL может тормозить на разборе SQL, но в MySQL парсер не эталонный и пример с ним ничего не говорит о скорости работы парсера в сабже.

Ответить | Правка | Наверх | Cообщить модератору

15. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 14:47

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

Ответить | Правка | Наверх | Cообщить модератору

19. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 15:10

> Не знаю, насколько он там не эталонный, но мой опыт подтверждает то,
> что лукап по хорошо оптимизированной струтуре данных по времени сравним с
> примитивным разбором строки из 10-15 байт, если блокировки не влезут.
Тут речь идет о миллионе транзакций в секунду!
Если у mysql что то во что то упирается (на нагрузке на пару парядков меньше) то это его проблемы и вообще offtop!

Ответить | Правка | Наверх | Cообщить модератору

12. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от опроро (?), 18-Окт-11, 14:34

Prepare Statement
ВНЕЗАПНО!

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

13. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 14:43

Может, прочтёте о чём вообще речь? А речь о том, что в шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы и там prepare реализовывать предложите?

Ответить | Правка | Наверх | Cообщить модератору

20. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 15:30

:facepalm:
Ещё раз. Распарсить много мегабайт чьего-бы то ни было синтаксиса - плёвое дело. Посмотри как быстро PHP парсит свои исходники. Ну ладно, не нравится PHP, возьми Python. Если в MySQL парсер такой кривой, то это исключительно его проблемы, а не проблемы синтаксиса. Ну замени ты SELECT UNIX_TIMESTAMP() на echo time(), по-твоему первый вариант дольше в десять раз будет парситься только потому что он в SQL-синтаксисе записан?

Ответить | Правка | Наверх | Cообщить модератору

24. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 15:52

Плёвое дело по сравнению с чем? В запросом к диску - да сколько угодно. С генерацией страницы с кучей исполняемого кода и, возможно, теми же SQL-запросами - тем более. Но НЕ по сравнению с поиском в прилично оптимизированном хэше. Ну есть у меня этот опыт, так что знаю о чем говорю. В таких случаях надо использовать бинарные сериализованные форматы, которые парсить не надо вообще - тупо выгребать строки заранее известных размеров по заранее известным смещениям.
Впрочем, если будет время - потестирую, что даёт избавление от парсинга в данном случае. Но процентов 10 скорости как минимум должно прибавиться (а скорее - около 30%).

Ответить | Правка | Наверх | Cообщить модератору

26. "Bullet Cache - высокопроизводительная система кэширования да..." +2 +/–

Сообщение от Аноним (-), 18-Окт-11, 16:12

Объясни как ты себе представляешь работу MySQL? На примере PHP я представляю примерно так:
1. PHP -> 2. SQL-строка посылается в MySQL -> 3. парсинг строки в понятную MySQL команду -> 4. выполнение команды (поиск по базе) -> ...
По твоей логике 3-й пункт должен выполняться ну очень долго и являться основным тормозом. Я правильно понимаю?

Ответить | Правка | Наверх | Cообщить модератору

29. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 16:16

Если там есть хоть какие-то сложные запросы - нет, конечно. См. японцев с HandlerSocket - проблема проявляется на простых запросах вида "SELECT name FROM table WHERE primaryKey=1" и подобных - то есть когда сам запрос выполняется мгновенно. Вот там уже парсинг SQL и обработка эскейпов чувствуется.
Я вот чего не пойму: чего со мной-то спорить? Есть код, есть результаты тестирования - и не только автора кода, есть описание условий тестирования... что ещё нужно?

Ответить | Правка | Наверх | Cообщить модератору

30. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 16:30

До тебя никак не дойдёт, что скорость поиска зависит от реализации. Неужели ты думаешь, что в эту крошечную библиотеку встроен полноценный SQL-парсер с поддержкой всех SQL-стандартов? Да тут по сути конечный автомат с максимум 10-20 состояниями, распарсить строку в 100 байт и понять, что хотят найти в кэше на нём можно за 0,000001 сек., если не меньше.
Не смотрел на тестирования автора, я высказался касательно твоего утверждения, что SQL-подобные синтаксисы тормозные в принципе.

Ответить | Правка | Наверх | Cообщить модератору

33. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 17:11

Я уже глянул в исходниках - нет там текстового синтаксиса, это дурной перевод. Есть нормальный бинарный формат и API-функции.
И не надо приписывать мне то, что я не говорил.
Я НЕ ГОВОРИЛ, ЧТО SQL-ПОДОБНЫЕ СИНТАКСИСЫ ТОРМОЗНЫЕ В ПРИНЦИПЕ.
Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота.

Ответить | Правка | Наверх | Cообщить модератору

35. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 17:28

> Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота.
Ок. Но вообще говоря, лишний memcpy вполне сойдёт. Сколько их происходит при сложных выборках уже после собственно парсинга запроса... При тех же Using filesort. Капля в океане, я бы сказал.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

36. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 17:47

О memcpy я речь вёл в контексте именно кэша, там вообще работы с диском нет, как и сложных запросов.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

32. "Bullet Cache - высокопроизводительная система кэширования да..." +2 +/–

Сообщение от Грустный Анон (?), 18-Окт-11, 16:54

Нужно ещё понимание работы RDMS.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

21. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от опроро (?), 18-Окт-11, 15:31

люди реально думают что базы данных данных настолько тупые насколько они умные )
весь мир живёт с медленным sql и не знает насколько он тормозной )
а где тесты с Prepared Statements ?
ps http://www.theserverside.com/news/1365244/Why-Prepared-State...

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

27. "Bullet Cache - высокопроизводительная система кэширования да..." +1 +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 16:12

Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache нет - именно по причине тормозности, на что и указывает автор в исходниках.

Ответить | Правка | Наверх | Cообщить модератору

28. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 16:13

> Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache
> нет - именно по причине тормозности, на что и указывает автор
> в исходниках.
Просто в новости перевод кривой.

Ответить | Правка | Наверх | Cообщить модератору

39. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от опроро (?), 18-Окт-11, 20:11

ну я ответил по поводу HandlerSocket
как я понял там жаловались на медленный парсинг в mysql
ну как раз для таких задач есть Prepared Statement (хотя тож есть недостатки)
и походу те парни ни слова не сказали про это (хотя я да же не читал оригинал)

Ответить | Правка | Наверх | Cообщить модератору

37. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 20:04

http://msdn.microsoft.com/en-us/library/aa260835.aspx -- см. там раздел "The (so-called) Prepared property".

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

42. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 22:57

> Может, прочтёте о чём вообще речь? А речь о том, что в
> шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы
> и там prepare реализовывать предложите?
Речь идёт о том что вы не умеете читать, и там нет никакого SQL.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

14. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 14:44

Оставь. Нельзя (сложно) программиста php убедить в том что ассемблер суммирует быстрее, если он не знает что такое ассемблер. Большинство посетителей, как я понимаю, не сильны в реализации технологий, а видят лишь обложку. И по цвету обложки делают вывод о содержании.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

16. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 14:49

Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...

Ответить | Правка | Наверх | Cообщить модератору

17. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 14:52

> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки, и в результате получили ускорение - и получишь сотни восторженных отзывов что Debian/что-угодно лучшее, они давно сидят и рады что он лучше всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество идиотов не может ошибаться.

Ответить | Правка | Наверх | Cообщить модератору

23. "Bullet Cache - высокопроизводительная система кэширования да..." +3 +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 15:43

>> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
> Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду
> исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки,
> и в результате получили ускорение - и получишь сотни восторженных отзывов
> что Debian/что-угодно лучшее, они давно сидят и рады что он лучше
> всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество
> идиотов не может ошибаться.
Так на одного крикуна тысяча тех, кто молчит и читает.

Ответить | Правка | Наверх | Cообщить модератору

40. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Школьник (ok), 18-Окт-11, 22:16

Я не могу говорить конкретно за MySQL, однако, мне приходилось работать тестировщиком другой RDBMS(проприетарной). В общем, исходя из того, что я узнал, я сделал такие выводы: производительность падает не только (и, возможно, не столько) на разборе SQL, сколько при таких дальнейших операциях как загрузка метаданных(хотя они часто кэшируются), проверка существования указанных в запросе таблиц, колонок, проверка типов данных, приведение типов данных, составление плана запроса, его оптимизация, преобразование плана в специальное внутреннее представление и т.д. Собственно разбор SQL (синтаксический разбор) тоже играет роль, но явно не первую.
При этом полностью согласен с тем, что использование любого текстового протокола при работе с кэшем абсолютно бессмысленно, ибо в случае с кэшем, а не сложной RDBMS, накладные расходы на разбор текста будут относительно велики.
Прочитал я про HandlerSocket (кстати, спасибо за упоминание о нем). Стало несколько непонятно следующее: для чего в MySQL, который еще с 5ой версии поддерживает prepared statements, это нужно? Особенно учитывая то, что протокол HandlerSocket по сути текстовый (хотя и весьма компактный и простой). Может, кто-то объяснит?

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

18. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Аноним (-), 18-Окт-11, 15:07

А что уж сразу не британские ученые?
Тут же прямо сказано SQL подобный синтакисис! теги к ключам очень полезная штука. А те кто не хочет могут юзать свои регекспы.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

22. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (??), 18-Окт-11, 15:42

Ну и откуда сие недоверие? Методика тестов, патчи, результаты - у них всё открыто. Можно проверить, что и сделала куча народу. А для этого чуда я, пожалуй, побалуюсь на досуге с аналогичным патчем - поглядим, что получится.
Теги к ключам - полезная штука. А генерация SQL-подобного синтаксиса а потом его разбор - вредная. И больше шансов ошибку пропустить, которую иначе компилятор в нормальном языке поймал бы, и дурацкий код генерации запроса, и серверу работы больше, и для инъекций шансы могут появиться, если синтаксис достаточно богатый.
А не верите японцам вы зря - всё открыто и уже опробовано массой народу.

Ответить | Правка | Наверх | Cообщить модератору

31. "Bullet Cache - высокопроизводительная система кэширования да..." +2 +/–

Сообщение от Грустный Анон (?), 18-Окт-11, 16:48

Классический пример "слышал звон, да не знаю где он" - основная нагрузка, за исключением выборки данных, приходится на query optimizer & planner, а не на разбор запроса, sql синтаксис тут совершенно не при чём.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

34. "Bullet Cache - высокопроизводительная система кэширования да..." +/–

Сообщение от Crazy Alex (ok), 18-Окт-11, 17:13

Смеётесь? Нет там никакой нагрузки на планировщик при выборке по первичному ключу.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	5. "Bullet Cache - высокопроизводительная система кэширования да..."	–2 +/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 13:19
	Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 13:40
	> Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket). Что-то мне подсказывает, что производительность упиралась вовсе даже не в разбор SQL. Куда более сложный многомегабайтный PHP-код с кучей инклудов парсится (только парсится, без выполнения) быстрее в разы сотни-другой байт SQL-запроса, который при выполнении так нагружает базу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Bullet Cache - высокопроизводительная система кэширования да..."	–1 +/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 14:11
	Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 14:17
	> Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL. А я не спорю, что MySQL может тормозить на разборе SQL, но в MySQL парсер не эталонный и пример с ним ничего не говорит о скорости работы парсера в сабже.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 14:47
	Не знаю, насколько он там не эталонный, но мой опыт подтверждает то, что лукап по хорошо оптимизированной струтуре данных по времени сравним с примитивным разбором строки из 10-15 байт, если блокировки не влезут.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 15:10
	> Не знаю, насколько он там не эталонный, но мой опыт подтверждает то, > что лукап по хорошо оптимизированной струтуре данных по времени сравним с > примитивным разбором строки из 10-15 байт, если блокировки не влезут. Тут речь идет о миллионе транзакций в секунду! Если у mysql что то во что то упирается (на нагрузке на пару парядков меньше) то это его проблемы и вообще offtop!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от опроро (?), 18-Окт-11, 14:34
	Prepare Statement ВНЕЗАПНО!
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	13. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 14:43
	Может, прочтёте о чём вообще речь? А речь о том, что в шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы и там prepare реализовывать предложите?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 15:30
	:facepalm: Ещё раз. Распарсить много мегабайт чьего-бы то ни было синтаксиса - плёвое дело. Посмотри как быстро PHP парсит свои исходники. Ну ладно, не нравится PHP, возьми Python. Если в MySQL парсер такой кривой, то это исключительно его проблемы, а не проблемы синтаксиса. Ну замени ты SELECT UNIX_TIMESTAMP() на echo time(), по-твоему первый вариант дольше в десять раз будет парситься только потому что он в SQL-синтаксисе записан?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 15:52
	Плёвое дело по сравнению с чем? В запросом к диску - да сколько угодно. С генерацией страницы с кучей исполняемого кода и, возможно, теми же SQL-запросами - тем более. Но НЕ по сравнению с поиском в прилично оптимизированном хэше. Ну есть у меня этот опыт, так что знаю о чем говорю. В таких случаях надо использовать бинарные сериализованные форматы, которые парсить не надо вообще - тупо выгребать строки заранее известных размеров по заранее известным смещениям. Впрочем, если будет время - потестирую, что даёт избавление от парсинга в данном случае. Но процентов 10 скорости как минимум должно прибавиться (а скорее - около 30%).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Bullet Cache - высокопроизводительная система кэширования да..."	+2 +/–
	Сообщение от Аноним (-), 18-Окт-11, 16:12
	Объясни как ты себе представляешь работу MySQL? На примере PHP я представляю примерно так: 1. PHP -> 2. SQL-строка посылается в MySQL -> 3. парсинг строки в понятную MySQL команду -> 4. выполнение команды (поиск по базе) -> ... По твоей логике 3-й пункт должен выполняться ну очень долго и являться основным тормозом. Я правильно понимаю?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 16:16
	Если там есть хоть какие-то сложные запросы - нет, конечно. См. японцев с HandlerSocket - проблема проявляется на простых запросах вида "SELECT name FROM table WHERE primaryKey=1" и подобных - то есть когда сам запрос выполняется мгновенно. Вот там уже парсинг SQL и обработка эскейпов чувствуется. Я вот чего не пойму: чего со мной-то спорить? Есть код, есть результаты тестирования - и не только автора кода, есть описание условий тестирования... что ещё нужно?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 16:30
	До тебя никак не дойдёт, что скорость поиска зависит от реализации. Неужели ты думаешь, что в эту крошечную библиотеку встроен полноценный SQL-парсер с поддержкой всех SQL-стандартов? Да тут по сути конечный автомат с максимум 10-20 состояниями, распарсить строку в 100 байт и понять, что хотят найти в кэше на нём можно за 0,000001 сек., если не меньше. Не смотрел на тестирования автора, я высказался касательно твоего утверждения, что SQL-подобные синтаксисы тормозные в принципе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 17:11
	Я уже глянул в исходниках - нет там текстового синтаксиса, это дурной перевод. Есть нормальный бинарный формат и API-функции. И не надо приписывать мне то, что я не говорил. Я НЕ ГОВОРИЛ, ЧТО SQL-ПОДОБНЫЕ СИНТАКСИСЫ ТОРМОЗНЫЕ В ПРИНЦИПЕ. Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 17:28
	> Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота. Ок. Но вообще говоря, лишний memcpy вполне сойдёт. Сколько их происходит при сложных выборках уже после собственно парсинга запроса... При тех же Using filesort. Капля в океане, я бы сказал.
	Ответить \| Правка \| К родителю #33 \| Наверх \| Cообщить модератору


	36. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 17:47
	О memcpy я речь вёл в контексте именно кэша, там вообще работы с диском нет, как и сложных запросов.
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	32. "Bullet Cache - высокопроизводительная система кэширования да..."	+2 +/–
	Сообщение от Грустный Анон (?), 18-Окт-11, 16:54
	Нужно ещё понимание работы RDMS.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	21. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от опроро (?), 18-Окт-11, 15:31
	люди реально думают что базы данных данных настолько тупые насколько они умные ) весь мир живёт с медленным sql и не знает насколько он тормозной ) а где тесты с Prepared Statements ? ps http://www.theserverside.com/news/1365244/Why-Prepared-State...
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	27. "Bullet Cache - высокопроизводительная система кэширования да..."	+1 +/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 16:12
	Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache нет - именно по причине тормозности, на что и указывает автор в исходниках.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 16:13
	> Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache > нет - именно по причине тормозности, на что и указывает автор > в исходниках. Просто в новости перевод кривой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от опроро (?), 18-Окт-11, 20:11
	ну я ответил по поводу HandlerSocket как я понял там жаловались на медленный парсинг в mysql ну как раз для таких задач есть Prepared Statement (хотя тож есть недостатки) и походу те парни ни слова не сказали про это (хотя я да же не читал оригинал)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 20:04
	http://msdn.microsoft.com/en-us/library/aa260835.aspx -- см. там раздел "The (so-called) Prepared property".
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	42. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 22:57
	> Может, прочтёте о чём вообще речь? А речь о том, что в > шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы > и там prepare реализовывать предложите? Речь идёт о том что вы не умеете читать, и там нет никакого SQL.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	14. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 14:44
	Оставь. Нельзя (сложно) программиста php убедить в том что ассемблер суммирует быстрее, если он не знает что такое ассемблер. Большинство посетителей, как я понимаю, не сильны в реализации технологий, а видят лишь обложку. И по цвету обложки делают вывод о содержании.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	16. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (ok), 18-Окт-11, 14:49
	Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 14:52
	> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный... Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки, и в результате получили ускорение - и получишь сотни восторженных отзывов что Debian/что-угодно лучшее, они давно сидят и рады что он лучше всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество идиотов не может ошибаться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Bullet Cache - высокопроизводительная система кэширования да..."	+3 +/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 15:43
	>> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный... > Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду > исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки, > и в результате получили ускорение - и получишь сотни восторженных отзывов > что Debian/что-угодно лучшее, они давно сидят и рады что он лучше > всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество > идиотов не может ошибаться. Так на одного крикуна тысяча тех, кто молчит и читает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Школьник (ok), 18-Окт-11, 22:16
	Я не могу говорить конкретно за MySQL, однако, мне приходилось работать тестировщиком другой RDBMS(проприетарной). В общем, исходя из того, что я узнал, я сделал такие выводы: производительность падает не только (и, возможно, не столько) на разборе SQL, сколько при таких дальнейших операциях как загрузка метаданных(хотя они часто кэшируются), проверка существования указанных в запросе таблиц, колонок, проверка типов данных, приведение типов данных, составление плана запроса, его оптимизация, преобразование плана в специальное внутреннее представление и т.д. Собственно разбор SQL (синтаксический разбор) тоже играет роль, но явно не первую. При этом полностью согласен с тем, что использование любого текстового протокола при работе с кэшем абсолютно бессмысленно, ибо в случае с кэшем, а не сложной RDBMS, накладные расходы на разбор текста будут относительно велики. Прочитал я про HandlerSocket (кстати, спасибо за упоминание о нем). Стало несколько непонятно следующее: для чего в MySQL, который еще с 5ой версии поддерживает prepared statements, это нужно? Особенно учитывая то, что протокол HandlerSocket по сути текстовый (хотя и весьма компактный и простой). Может, кто-то объяснит?
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	18. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Аноним (-), 18-Окт-11, 15:07
	А что уж сразу не британские ученые? Тут же прямо сказано SQL подобный синтакисис! теги к ключам очень полезная штука. А те кто не хочет могут юзать свои регекспы.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	22. "Bullet Cache - высокопроизводительная система кэширования да..."	+/–
	Сообщение от Crazy Alex (??), 18-Окт-11, 15:42
	Ну и откуда сие недоверие? Методика тестов, патчи, результаты - у них всё открыто. Можно проверить, что и сделала куча народу. А для этого чуда я, пожалуй, побалуюсь на досуге с аналогичным патчем - поглядим, что получится. Теги к ключам - полезная штука. А генерация SQL-подобного синтаксиса а потом его разбор - вредная. И больше шансов ошибку пропустить, которую иначе компилятор в нормальном языке поймал бы, и дурацкий код генерации запроса, и серверу работы больше, и для инъекций шансы могут появиться, если синтаксис достаточно богатый. А не верите японцам вы зря - всё открыто и уже опробовано массой народу.
	Ответить \| Правка \| Наверх \| Cообщить модератору