А спроить по поводу огромнейшего опыта и знаний у ребят, работающих в ВК, я даже смысла не вижу. Если у вас есть желание порассуждайте хотя бы отталкиваясь от опыта) если с логикой дружны, то у вас всё получится)
Всегда, когда читаю комменты в таком стиле, мне хочется спросить: «а вы то, сами кто?»
Не хочу никого обидеть, но уж давайте на чистоту.
Я уже 4-ый год занимаюсь созданием крупных (DAU > 1 млн.) highload проектов на php. И уж сколько за это время я повидал таких коммерсантов, которые пишут и на PHP, и на Java, и на C, и на Erlang, и с Node.js работают, и на дуде с балалайками играют… А уж сколько знатоков различных баз данных встретил уууу… Знаете в чём прикол? 99% из них — «ни о чём. три раза.». Причём, как ни странно, «ни о чём» во всех перечисленных областях знаний…
Вы, наверное, думаете: «Я не такой. Я не такой. Я не такой. Они все такие. Они все такие. Они все такие, а Я не такой.».
Ну-ну, подумаем мы все…
Ну а теперь по делу:
На мой взгляд Highload, сам по себе, прост как и всё гениальное =)
Всё искусство заключается в знании как эффективно работать с огромными наборами данных, как быстро обрабатывать сотни тысяч и миллионы хитов в минуту, понимании того, что может привести к задержкам в обработке и падению. Надо уметь принимать правильные, эффективные решения, быстро распознавать и признавать ошибки и просчёты, учиться на своих и чужих ошибках, принимать меры по их сокращению =)
Если честно, не хочется разводить тут холиваров насчёт php и его ограниченнрости. Он хорош для быстрого решения узкого круга задач.
По поводу простоты — да, простой. Это плохо? А вы знаете сложный ЯП? =)
Скажу пару слов в поддержку ВК, хотя я как и Вы достаточно сильно убеждён в том, что для каждой задачи есть наиболее оптимальный набор инструментов, которые позволяют её решать.
Вы все наверняка неоднократно слышали фразы вроде этой:
«Пишите на том, на чём умеете. Когда упрётесь в производительность у вас будут в распоряжении уже совсем другие ресурсы. А если не упрётесь или ресурсов не будет, то это признак того, что вы что-то делаете не так.»
или этой:
«Решайте проблемы по мере их поступления».
И вы знаете, я НЕ рискну спорить ни с одним из этих убеждений (если выбранный инструментарий не на грани абсурда или возможная проблема крайне очевидна и близка).
Более того, сам по себе PHP со многих сторон весьма не плох, если вы умеете его правильно готовить, а тех, кто умеет не так много (впрочем, как и везде). А вот тех, кто возомнил о себе (из-за низкого порога входа), что он умеет, в разы больше. Но сейчас не об этом.
ВК всегда придерживался позиции того, что если им что-то нужно — они это делают сами. Это их право, тем более, что теперь у них на это есть необходимые силы и ресурсы. Кроме того мы не видели ни одного тотального фейла из-за того, что они придерживаются этой позиции.
Почему не Java, C# или Go? Ответ на поверхности — в ВК, пожалуй, одни из лучших и опытнейших С/C++ и PHP разработчиков в Рунете (если не лучшие, ИМХО). Есть ли ВК специалисты по Java и C#? Да, по крайней мере разработчики мобильных аппов (например, Григорий Клюшников). Но сколько их? Человека 2-3 (могу ошибаться =) ). И навряд ли они обладают такими глубокими знаниями как ДОСТОПОЧТЕНЫЕ TheShade, Walrus, Филипп Дельгядо и другие гуру Java. Думаю, тут всё очевидно.
Лично для меня остался неразрешённым один вопрос — почему компилятор, а не VM? Ведь у неё, как мне кажется, гораздо более широкий набор возможностей для дальнейших оптимизаций. С другой стороны разработка VM, наверняка гораздо более трудоёмкая задача. Возможно сейчас, когда они уже экономят благодаря KPHP, ребята позволят себе разработку kotVM =)
З.Ы. ИМХО: Павел, воистину сумел создать сильнейшую команду, как по техническим знаниям, так и по сплочённости и целеустремлённости. Это заслуживает уважения.
Я уже говорил, что по приведённым графикам судить о приросте производительности очень сложно. Видно, что он есть, но какой конкретно — неизвестно, тк мы не знаем что и в каком соотношении лопало время.
Бегло прикинул прирост отталкиваясь от предположения, что php у них кушал 70-75% времени:
0,25 — 100%
0,1875 — 75% // PHP
Исходя из этих примитивных расчётов можно сделать предположение о приблизительно 70% приросте производительности со стороны php (то, что раньше делал php сейчас делается на 70% быстрее).
Я вас умоляю, какие tor/vpn/proxy, если автор на хабре заявляет: «На днях я решил заново взяться за базу примари на mail.ru и побрутить ящики по секретным вопросам»? Тем более использование перечисленных технологий не освобождает от ответственности.
Утомили всякие смутные личности пытающиеся по PR-иться за счёт попыток втоптать в грязь mail.ru. Лучше бы о чём-то полезном написали.
Скорость чтения одной и той же строки будет одинаковой в пределах допустимой погрешности. Но если мы считаем, что системы находятся в одинаковом состоянии на тот момент когда они знают адрес и смещение, то скорость доступа будет одинаковой (тк системы находятся в одинаковом исходном состоянии и выполняют одну и ту же операцию).
Кроме того в нормальной системе табличка уже будет находиться в оперативке, а не на диске.
Уж про тупость бы помолчал уж тем более если ты не в состоянии прочитать, осмыслить и понять.
Я > Не справедливо ли считать, что после определения адреса строки при помощи индекса, для доступа к данным нам потребуется одинаковое количество времени (вне зависимости от того по строковому индексу мы искали или же по числовому)? Это же очевидно :-)
Вы > select INT from table where VARCHAR;
Вы > select VARCHAR from table where INT;
Вы > Потребуется одинаковое время на получение с диска INT и VARCHAR?
Я уже ответил на ваш вопрос выше. Скорость чтения с диска можно считать одинаковой, если вам это не понятно — могу пояснить) А вот скорость поиска по индексу будет различной, поскольку будет сравниваться различное число байт (опять же смотри предыдущий пост).
Надеюсь твой высокоодарённый мозг с сотой попытки сможет это понять.
> Индексы лежат полностью в памяти. А данные необходимо читать.
> В первом случае я читал те самые 4 байта. Во втором случае 255 байт.
Так что же быстрее прочитать 4 байта или 255? :-D я уж молчу о том, что далеко не всегда там будет 255 байт — 255 * кол-во символов необходимых для кодирования одной буквы :-D
> Выборка — это не только найти позицию в индексе, но и прочитать конкретные данные.
Не справедливо ли считать, что после определения адреса строки при помощи индекса, для доступа к данным нам потребуется одинаковое количество времени (вне зависимости от того по строковому индексу мы искали или же по числовому)? Это же очевидно :-)
> Индексы УЖЕ лежат в оперативке.
СУБД по возможности (!) пытается кэшировать индексы в оперативке, но они далеко не всегда будут находиться в оперативной памяти.
> Печально. Очень печально сейчас у таких как вы с образованием.
Повторяетесь. Видимо я задел больную тему об образовании. Простите, не хотел вас обидеть.
вы сами себе противоречите) вы хотите сказать, что PK не является индексом? и поэтому его приходится читать с диска, в то время как индекс по строке (по велению каких-то неведомых сил :-D ) будет в оперативке? вы меня простите, но это ПОЛНЕЙШИЙ БРЕД)
кроме того индексы далеко не обязательно лежать в оперативке. но когда вы начинаете работать с таблицей, то вся инфа по ней по возможности туда подгружается (в случае если её там ещё небыло)
а ваши тесты из двух запросов и тестами то назвать нельзя — так происки школоло =)
Ты меня смешишь) и доказывать тебе мне ничего не надо)
и не надо мне тут чесать про прикладную статистику и теорию измерений). те 2 с половиной измерения, которое ты соизволил произвести (тем более на продашкен базе под нагрузкой) вообще ни о чём не говорит в силу всем известных причин!!! и уж тем более те 2 с половиной измерения ни в коем случае не имеют отношения к статистике и первому приближению))) уж не позорился бы…
хочешь верить свои измерения с половиной замера, которые ты произвёл — верь) бей себя лопатой в грудь и вопи, что все настолько глупы и не видят очевидных вещей :-D
Ты бы хоть сам вдумался бы то, что ты утверждаешь) Ты уверяешь нас в том, что с индексом по строке переменной длинны в 255 символов искать быстрее чем по целочисленному PK (uint 4 байта) =) так глупо)))
> Специально для доцента Аваса, я указал и объем таблиц и объем БД и даже число запросов обрабатываемых БД.
Вы, что реально не понимаете почему эти тесты — ни о чём не говорят? О_о Видимо намёк про снятие измерений на лабораторных работах был вам не понятен, намекну яснее — ваша методика снятия замеров — полнейшее фуфло.
> Без разбивки по таблицам, но делать разбивку мне лень. Поскольку это реальная рабочая система, а не стенд.
Что за фигню вы тут лечите? Вы утверждаете, что в системе в которой MySQL обрабатывает 50к запросов в секунду вы знаете только общую сумму запросов к БД и не знаете ни какие запросы там исполняются, ни сколько строк модифаится и селектится, ни количество медленных запросов?
>Хайлоад — это нагрузка в первую очередь. И образоваться может он и на таблице в 1000 записей и на таблице в 1млрд записей. Но вам-то это не понятно, ибо знаний нет, есть лишь распальцовка.
именно по-этому я и спрашивал про объём таблицы и нагрузку, а «распальцовкой» тут занимаетесь вы с господином FanatPHP. И повторюсь — то, что вы привели выше — говнотест — такие тесты составляют школьники, которые вообще не понимают что они измеряют, поэтому держите свои выебоны при себе.
Если у меня будет свободное время, то приведу здесь результаты нормального тестирования.
Всегда, когда читаю комменты в таком стиле, мне хочется спросить: «а вы то, сами кто?»
Не хочу никого обидеть, но уж давайте на чистоту.
Я уже 4-ый год занимаюсь созданием крупных (DAU > 1 млн.) highload проектов на php. И уж сколько за это время я повидал таких коммерсантов, которые пишут и на PHP, и на Java, и на C, и на Erlang, и с Node.js работают, и на дуде с балалайками играют… А уж сколько знатоков различных баз данных встретил уууу… Знаете в чём прикол? 99% из них — «ни о чём. три раза.». Причём, как ни странно, «ни о чём» во всех перечисленных областях знаний…
Вы, наверное, думаете: «Я не такой. Я не такой. Я не такой. Они все такие. Они все такие. Они все такие, а Я не такой.».
Ну-ну, подумаем мы все…
Ну а теперь по делу:
На мой взгляд Highload, сам по себе, прост как и всё гениальное =)
Всё искусство заключается в знании как эффективно работать с огромными наборами данных, как быстро обрабатывать сотни тысяч и миллионы хитов в минуту, понимании того, что может привести к задержкам в обработке и падению. Надо уметь принимать правильные, эффективные решения, быстро распознавать и признавать ошибки и просчёты, учиться на своих и чужих ошибках, принимать меры по их сокращению =)
Если честно, не хочется разводить тут холиваров насчёт php и его ограниченнрости. Он хорош для быстрого решения узкого круга задач.
По поводу простоты — да, простой. Это плохо? А вы знаете сложный ЯП? =)
Вы все наверняка неоднократно слышали фразы вроде этой:
«Пишите на том, на чём умеете. Когда упрётесь в производительность у вас будут в распоряжении уже совсем другие ресурсы. А если не упрётесь или ресурсов не будет, то это признак того, что вы что-то делаете не так.»
или этой:
«Решайте проблемы по мере их поступления».
И вы знаете, я НЕ рискну спорить ни с одним из этих убеждений (если выбранный инструментарий не на грани абсурда или возможная проблема крайне очевидна и близка).
Более того, сам по себе PHP со многих сторон весьма не плох, если вы умеете его правильно готовить, а тех, кто умеет не так много (впрочем, как и везде). А вот тех, кто возомнил о себе (из-за низкого порога входа), что он умеет, в разы больше. Но сейчас не об этом.
ВК всегда придерживался позиции того, что если им что-то нужно — они это делают сами. Это их право, тем более, что теперь у них на это есть необходимые силы и ресурсы. Кроме того мы не видели ни одного тотального фейла из-за того, что они придерживаются этой позиции.
Почему не Java, C# или Go? Ответ на поверхности — в ВК, пожалуй, одни из лучших и опытнейших С/C++ и PHP разработчиков в Рунете (если не лучшие, ИМХО). Есть ли ВК специалисты по Java и C#? Да, по крайней мере разработчики мобильных аппов (например, Григорий Клюшников). Но сколько их? Человека 2-3 (могу ошибаться =) ). И навряд ли они обладают такими глубокими знаниями как ДОСТОПОЧТЕНЫЕ TheShade, Walrus, Филипп Дельгядо и другие гуру Java. Думаю, тут всё очевидно.
Лично для меня остался неразрешённым один вопрос — почему компилятор, а не VM? Ведь у неё, как мне кажется, гораздо более широкий набор возможностей для дальнейших оптимизаций. С другой стороны разработка VM, наверняка гораздо более трудоёмкая задача. Возможно сейчас, когда они уже экономят благодаря KPHP, ребята позволят себе разработку kotVM =)
З.Ы. ИМХО: Павел, воистину сумел создать сильнейшую команду, как по техническим знаниям, так и по сплочённости и целеустремлённости. Это заслуживает уважения.
Я под debian 6 зимой HHVM настраивал) Главное было MySQL 5.5 завести на нём. Было стрёмно (ибо прод и я не гуру админ), но всё получилось)
Я уже говорил, что по приведённым графикам судить о приросте производительности очень сложно. Видно, что он есть, но какой конкретно — неизвестно, тк мы не знаем что и в каком соотношении лопало время.
Бегло прикинул прирост отталкиваясь от предположения, что php у них кушал 70-75% времени:
0,25 — 100%
0,1875 — 75% // PHP
другие расходы: 0,0625
С KPHP:
0,12 — 100%
0,12 — 0,0625 = 0,0575
0,0575 — 30% // KPHP
Исходя из этих примитивных расчётов можно сделать предположение о приблизительно 70% приросте производительности со стороны php (то, что раньше делал php сейчас делается на 70% быстрее).
Утомили всякие смутные личности пытающиеся по PR-иться за счёт попыток втоптать в грязь mail.ru. Лучше бы о чём-то полезном написали.
очередной PR-щик фигов…
Кроме того в нормальной системе табличка уже будет находиться в оперативке, а не на диске.
Я > Не справедливо ли считать, что после определения адреса строки при помощи индекса, для доступа к данным нам потребуется одинаковое количество времени (вне зависимости от того по строковому индексу мы искали или же по числовому)? Это же очевидно :-)
Вы > select INT from table where VARCHAR;
Вы > select VARCHAR from table where INT;
Вы > Потребуется одинаковое время на получение с диска INT и VARCHAR?
Я уже ответил на ваш вопрос выше. Скорость чтения с диска можно считать одинаковой, если вам это не понятно — могу пояснить) А вот скорость поиска по индексу будет различной, поскольку будет сравниваться различное число байт (опять же смотри предыдущий пост).
Надеюсь твой высокоодарённый мозг с сотой попытки сможет это понять.
> Индексы лежат полностью в памяти. А данные необходимо читать.
> В первом случае я читал те самые 4 байта. Во втором случае 255 байт.
Так что же быстрее прочитать 4 байта или 255? :-D я уж молчу о том, что далеко не всегда там будет 255 байт — 255 * кол-во символов необходимых для кодирования одной буквы :-D
> Выборка — это не только найти позицию в индексе, но и прочитать конкретные данные.
Не справедливо ли считать, что после определения адреса строки при помощи индекса, для доступа к данным нам потребуется одинаковое количество времени (вне зависимости от того по строковому индексу мы искали или же по числовому)? Это же очевидно :-)
> Индексы УЖЕ лежат в оперативке.
СУБД по возможности (!) пытается кэшировать индексы в оперативке, но они далеко не всегда будут находиться в оперативной памяти.
> Печально. Очень печально сейчас у таких как вы с образованием.
Повторяетесь. Видимо я задел больную тему об образовании. Простите, не хотел вас обидеть.
кроме того индексы далеко не обязательно лежать в оперативке. но когда вы начинаете работать с таблицей, то вся инфа по ней по возможности туда подгружается (в случае если её там ещё небыло)
а ваши тесты из двух запросов и тестами то назвать нельзя — так происки школоло =)
и не надо мне тут чесать про прикладную статистику и теорию измерений). те 2 с половиной измерения, которое ты соизволил произвести (тем более на продашкен базе под нагрузкой) вообще ни о чём не говорит в силу всем известных причин!!! и уж тем более те 2 с половиной измерения ни в коем случае не имеют отношения к статистике и первому приближению))) уж не позорился бы…
хочешь верить свои измерения с половиной замера, которые ты произвёл — верь) бей себя лопатой в грудь и вопи, что все настолько глупы и не видят очевидных вещей :-D
Ты бы хоть сам вдумался бы то, что ты утверждаешь) Ты уверяешь нас в том, что с индексом по строке переменной длинны в 255 символов искать быстрее чем по целочисленному PK (uint 4 байта) =) так глупо)))
Вы, что реально не понимаете почему эти тесты — ни о чём не говорят? О_о Видимо намёк про снятие измерений на лабораторных работах был вам не понятен, намекну яснее — ваша методика снятия замеров — полнейшее фуфло.
> Без разбивки по таблицам, но делать разбивку мне лень. Поскольку это реальная рабочая система, а не стенд.
Что за фигню вы тут лечите? Вы утверждаете, что в системе в которой MySQL обрабатывает 50к запросов в секунду вы знаете только общую сумму запросов к БД и не знаете ни какие запросы там исполняются, ни сколько строк модифаится и селектится, ни количество медленных запросов?
именно по-этому я и спрашивал про объём таблицы и нагрузку, а «распальцовкой» тут занимаетесь вы с господином FanatPHP. И повторюсь — то, что вы привели выше — говнотест — такие тесты составляют школьники, которые вообще не понимают что они измеряют, поэтому держите свои выебоны при себе.
Если у меня будет свободное время, то приведу здесь результаты нормального тестирования.