В этом решении запрос компилируется в машинный код налету, освобождая процессор от условных джампов и, как следствие, от сброса конвейера процессора.
А какие открытые решения имеют подобные оптимизации? Ну чтоб не со сфинксом сравнивать?
Москва — крупный мегаполис — здесь машина лишняя. Здесь, как и во всех крупных городах, надо пользоваться метро. Да я за 1к сниму квартиру в 10 минутах ходьбы от метро.
Фитнес центров в Москве реально много. У меня есть и рядом с работой и рядом с домом.
С площадью, да — косяк. Практически нет стандартных однушек больше 40-50 метров, но лично мне и в 38 нормально живется. Да дом — это хорошо, но надо понимать, что в мегаполисе — дом -крайняя роскошь
Я сравнил цены Москвы и Кремневой долины, потому что и в москве и в кремниевой долине самые высокие зарплаты, большинство крупных работодателей сидят и самый большой рынок работы. Этим они и похожы — самые крупные по стране.
Те девелопером можно работать и не в москве и не в долине, но они, как я уже писал, самые крупные, вот и подходят для сравнения.
PS. по иронии, все то, что на рублевке «можно сравнивать» находится за МКАД — те не в Москве.
По моему это миф. Знакомые, ездившие туда говорят, что еда не сколько дешевле, сколько качественнее за те же деньги. Это по сравнению с мск.
А вот жилье сильно дороже. больше 2к$ — вот тут писали habrahabr.ru/post/125395/
В мск можно за 1к$ снять квартиру
я делаю апдейты в рандомные старницы памяти. соответственно они должны быть синкануты на диск. Хорошо что ядро может их отсортировать в нужном порядке. но апдейты мускула идут в разные страницы, а апдейты редиса в одну. одну страницу синкать явно сильно быстрее чем разные.
я так понимаю, что редис надо использовать на малой нагрузке на запись чтоб не вылести в своп из-за copy-on-write? те в качестве кеша?
1.конкурентные апдейты — ну вы же согласны, что надо за ними очень тщательно следить и, на мой взгляд, лучше вообще отказаться от MMR в пользу шардинга — как-то спокойнее.
2. Ну согласитесь же, что настройка автоинкреимента на автоинкремент 2+1 выглядит каким-то костылем. И что вы будете делать, когда у вас появится 3я площадка?
3. про время операций: я тестировал hs на mysql 5.5. естественно мне было интересно, какой же прирост по сравнению с native mysql — прирост был примерно в 20% Это объясняется даже в статье автора плагина (той самой, про 750к запросов), что в mysql 5.1 было куча локов еще до innodb, которые они, чтением напрямую из innodb обошли. В 5.5 их очень много выпили, поэтому разница сильно сократилась. Согласитель же, что парсинг запроса и проверка авторизации это не тотальные по быстродействию операции. и не могут они занимать 90% времени запроса. Вы сами говорите, их же 10 лет разрабатывают.
4. про запись на диск. Частично согласен, но модель Редиса — переодические снапшоты + лог апдейтов мне кажется более быстрым чем синк страниц мускула в рандомном порядке
Про перебор ключей — это я имел в виду эмуляцию селекта с like на nosql про который вы упомянули.
например kyoto cabinet умеет искать по префиксам ключей — так можно вынуть весь список нобходимых ключей.
Да noSql начинает тормозить когда упирается в диск. но использование hs никак от этого не уберегает: он так же встанет на большом колличестве одновременных запросов. Дело то не в типе бд, а в том что много одновременных запросов не пролезет через диск — только память. ваши 600к запросов то не с диска же все-таки?
В вашем случае MMR скорее всего применима, но в общем случае — MMR в Mysql нельзя использовать в нагруженном сервисе: помимо специфики автоинкремента есть еще не решаемые проблемы конкурентных апдейтов одних и тех же записей.
Еще цифры в тестах очень большие: у нас на серваке трехлетней давности общее время запроса (коннект/индекс/запрос) — 0.6ms те в 10 раз меньше. причем это еще далеко не предел — есть куда крутить настройки.
на нашей базе в 12 миллионов записей и 3к запросов в секунду все 3 операции занимали примерно однинаковое время — по 0.2ms — так что у вас еще и косяк где-то на коннекте происходит. не может коннект выполнятся дольше всех остальных операций
Из любого NoSql тоже можно сделать любые выборки, перебрав все имеющиеся ключи(при вашем like ведь произойдет то же самое). А скорость работы в режиме key/value(те в основном режиме) будет выше на порядок. Конечно это не так удобно, но за то в бою работает быстрее.
Но самое главное — непонятно, зачем вам одна база данных с настройками, когда эти настройки легко раскладываются по шардам юзеров. Из статьи не очень понятно, для чего конкретно нужна единая таблица.
Ок, скрипт работает. Я думаю, что это скорее хорошо. Хостер вам дает мого возможностей.
Вы же хотели найти уязвимость, при которой произошел бы отказ в обслуживании не только вас, но и других пользователей рядом. Как вы поняли, что всь сервер недоступен, а не только ваши ресурсы?
Одно дело, когда когда сосед Вася запустил ваш прекрасный скрипт, и у вас ничего не работает. Другое дело, когда вы запустили скрипт, у вас все лимиты кончились, сервер больше на запросы, исполняемые от вашего юзера не отвечает. А соседу Васе все равно — у него все работает.
если просто шифровать пароль перед передачей каким-нибудь асинхронным алгоритмом, то я не вижу в этом никакого смысла — плейн пароль превращается в «плейн хеш» — всеравно с помощью чего получать доступ к чужому аккаунту. те хеш превращается в пароль.
если придумать систему с парой ключей для шифрования — то ее уже придумали — она называется ssl )
И да, я тоже против велосипедов и за https
Да, я написал, что проще всего зафильтровать, и это самая первая мысль, которая может придти в голову при борьбе с XSS. И написал, почему она может придти в голову, но при кажущейся простоте и изящности — она неправильная. Юзеру плевать на наши проблемы фильтраций XSS
А как вставить 1024 раза по мегу? Если, например, у юзера есть имя (предположем varchar 50)
те 1024 раза можно создать юзера, но для этого надо уже использовать бота и с другой стороны баррикад буду средства противостояния ботам.
Потом при проектировании бд нужно провести анализ того, что будет в ней хранится, как сделать так, чтоб даже если в бд будут миллионы записей, она бы нормально работала.
Вообще, саме лучшее решение — активное использование мозга.
гигабайты — не смогут конечно, nginx отвалится по post size limit`у
а вообще размеры не плохо бы задавать прямо в базе: varchar даст вставить только сколько нужно. Типы данных, они для этого и нужны :)
Потому что проще один раз зафильтровать при вводе, чем искать все места, где нужно фильтровать при выводе.
Один разработчик написал интерфейс получения данных из базы. Он данные не фильтрует, потому как мало ли где они будут нужны. Другой разработчик написал универсальный html контейнер, который выводит данные и думает, что все пришедшие к нему данные уже отфильтрованы. теоритически надо писать фильтр прослойку между ними, но третий разработчик видит два компонента и соединяет, потому что один получает данные, а другой выводит. И таких мест может быть очень много. Вот поэтому и появляется соблазн писать в базу уже фильтрованные значения
А какие открытые решения имеют подобные оптимизации? Ну чтоб не со сфинксом сравнивать?
Фитнес центров в Москве реально много. У меня есть и рядом с работой и рядом с домом.
С площадью, да — косяк. Практически нет стандартных однушек больше 40-50 метров, но лично мне и в 38 нормально живется. Да дом — это хорошо, но надо понимать, что в мегаполисе — дом -крайняя роскошь
Те девелопером можно работать и не в москве и не в долине, но они, как я уже писал, самые крупные, вот и подходят для сравнения.
PS. по иронии, все то, что на рублевке «можно сравнивать» находится за МКАД — те не в Москве.
А вот жилье сильно дороже. больше 2к$ — вот тут писали habrahabr.ru/post/125395/
В мск можно за 1к$ снять квартиру
я так понимаю, что редис надо использовать на малой нагрузке на запись чтоб не вылести в своп из-за copy-on-write? те в качестве кеша?
2. Ну согласитесь же, что настройка автоинкреимента на автоинкремент 2+1 выглядит каким-то костылем. И что вы будете делать, когда у вас появится 3я площадка?
3. про время операций: я тестировал hs на mysql 5.5. естественно мне было интересно, какой же прирост по сравнению с native mysql — прирост был примерно в 20% Это объясняется даже в статье автора плагина (той самой, про 750к запросов), что в mysql 5.1 было куча локов еще до innodb, которые они, чтением напрямую из innodb обошли. В 5.5 их очень много выпили, поэтому разница сильно сократилась. Согласитель же, что парсинг запроса и проверка авторизации это не тотальные по быстродействию операции. и не могут они занимать 90% времени запроса. Вы сами говорите, их же 10 лет разрабатывают.
4. про запись на диск. Частично согласен, но модель Редиса — переодические снапшоты + лог апдейтов мне кажется более быстрым чем синк страниц мускула в рандомном порядке
например kyoto cabinet умеет искать по префиксам ключей — так можно вынуть весь список нобходимых ключей.
Да noSql начинает тормозить когда упирается в диск. но использование hs никак от этого не уберегает: он так же встанет на большом колличестве одновременных запросов. Дело то не в типе бд, а в том что много одновременных запросов не пролезет через диск — только память. ваши 600к запросов то не с диска же все-таки?
Еще цифры в тестах очень большие: у нас на серваке трехлетней давности общее время запроса (коннект/индекс/запрос) — 0.6ms те в 10 раз меньше. причем это еще далеко не предел — есть куда крутить настройки.
на нашей базе в 12 миллионов записей и 3к запросов в секунду все 3 операции занимали примерно однинаковое время — по 0.2ms — так что у вас еще и косяк где-то на коннекте происходит. не может коннект выполнятся дольше всех остальных операций
Но самое главное — непонятно, зачем вам одна база данных с настройками, когда эти настройки легко раскладываются по шардам юзеров. Из статьи не очень понятно, для чего конкретно нужна единая таблица.
Вы же хотели найти уязвимость, при которой произошел бы отказ в обслуживании не только вас, но и других пользователей рядом. Как вы поняли, что всь сервер недоступен, а не только ваши ресурсы?
Одно дело, когда когда сосед Вася запустил ваш прекрасный скрипт, и у вас ничего не работает. Другое дело, когда вы запустили скрипт, у вас все лимиты кончились, сервер больше на запросы, исполняемые от вашего юзера не отвечает. А соседу Васе все равно — у него все работает.
если придумать систему с парой ключей для шифрования — то ее уже придумали — она называется ssl )
И да, я тоже против велосипедов и за https
те 1024 раза можно создать юзера, но для этого надо уже использовать бота и с другой стороны баррикад буду средства противостояния ботам.
Потом при проектировании бд нужно провести анализ того, что будет в ней хранится, как сделать так, чтоб даже если в бд будут миллионы записей, она бы нормально работала.
Вообще, саме лучшее решение — активное использование мозга.
а вообще размеры не плохо бы задавать прямо в базе: varchar даст вставить только сколько нужно. Типы данных, они для этого и нужны :)
Один разработчик написал интерфейс получения данных из базы. Он данные не фильтрует, потому как мало ли где они будут нужны. Другой разработчик написал универсальный html контейнер, который выводит данные и думает, что все пришедшие к нему данные уже отфильтрованы. теоритически надо писать фильтр прослойку между ними, но третий разработчик видит два компонента и соединяет, потому что один получает данные, а другой выводит. И таких мест может быть очень много. Вот поэтому и появляется соблазн писать в базу уже фильтрованные значения