Очень хороший пример ситуации. Предложите потенциальным сотрудниками быть не только наемными сотрудниками, но и совладельцами. Т.е. долю в проекте. Если вы имеете авторитет в своей области разрабатываемого проекта — то сотрудников точно найдете. Мне кажется, именно это и хотел сказать автор статьи.
Вкратце, чтобы все работало необходимо, чтобы менталитет достаточности был, если и не у всех, но у подавляющего большинства. При другом раскладе такие люди рискуют оказаться в большом проигрыше.
Мне кажется, это типовой уровень распидолбайства. Как пример — подключение к одному очень известному московскому провайдеру удалось только с 4 попытки, поскольку предыдущие 3 раза «не смогли взять ключи от чердака в ЖЭКе, но в следующий раз такое точно не повторится». Как правило, подобное лечится только пизвездулями от начальства.
Тут спорный момент. Если игра кроссплатформенная, а внутриигровая валюта привязана к игровому аккаунту (который может использоваться на любой платформе) — то в этом случае полностью аналогично доступу к платной услуге.
> Я думаю, вас не затруднит прямо сейчас посмотреть и написать сюда?
Затруднит. Вы явно не представляете highload проекты.
Проводить бенчмарки и эксперименты на рабочей БД и рабочей нагрузке никто не даст. Есть только общая статистика, по которой было уменьшение среднего времени выполнения. Возвращать все назад, что бы посмотреть а сколько же было до этого было время выполнения — никто не будет. А смотреть время исполнения на пустой или девелоперской БД — бесполезно, цифры будут совсем другие.
> 10 мс — это миллисекунд, я понимаю? 1 десятая секунды?
Сотая вообще-то :-)
Но тут речь не о величине — может 10мс, может 1мс, может всего 100мкс экономим. Важно, что на таких нагрузках ни одна оптимизация не оказывается лишней.
> Беда в том, что вы никак не определитесь, какие именно идеи :)
Ок. Перечисляю «идеи»:
1) Хранить пользователя в мемкеше (или аналогичном in-memory storage)
2) В SQL БД за пользователем обращаться *только* при отсутствии данных о нем в мемкеше
Думаю тут понятно без комментариев.
А вот необходимость хранить связь login -> id в key-value storage следует из:
1) Получить id из key-value storage быстрее, чем из SQL, даже по индексу
2) В случае присутствия пользователя в мемкеше мы обойдемся вообще без SQL-запросов
> И не можете ответить на простой вопрос — зачем держать в кэше инфу, которая понадобится раз в сутки.
Все вышеперечисленное актуально для highload проектов. Для «сайта Васи Пупкина» все это, понятное дело, не нужно. А в целом — простая арифметика — экономя 10мс на каждом хите мы экономим дофига времени при миллиардах хитов в сутки. И ничего не экономим при 100 хитах в сутки — там на простой больше времени тратится. :-)
> сдается мне, вы просто не поняли те безумные идеи, которые вдруг зачем-то ударились защищать :)
Нет. Просто я, как и kapitansky, работаю на highload'е (средняя нагрузка — 1.5 млрд. хитов в сутки). И там подобные, как вы выразились «идеи» — естественная и проверенная временем практика.
> общими усилиями получилось „Дублируем юзеринфу в мемкеше потому что запрос по индексу недостаточно быстрый“
Не перевирайте. Мемкеш не потому, что запрос по индексу быстрый, а потому, что SQL сам по себе недостаточно быстрый. Кстати, даю подсказку: на highload'е последовательные запросы одного и того же пользователя могут быть обработаны совершенно разными серверами, так-что хранить данные в сессия (или как в PHP это называется?) — не вариант. Каждый раз получать юзера из SQL БД — тоже.
Так писали же выше — из key-value storage. Выигрыш тут не только за счет увеличения скорости выборки по id юзера, по сравнению с выборкой по логину, но и за счет того, что юзер уже может быть в мемкеше (и ключом в MC выступает все-таки id, а не логин) — на highload'е мемкеш может быть ОЧЕНЬ большим. Да и схема эта в общем-то типовая.
> Разгрузить немного СУБД ценой большей нагрузки на приложение и теоретически меньшей безопасностью (искомый хэш так будет попадать в приложение, а не находиться только внутри СУБД — три варианта (из базы, из приложения, из канала между базой и приложением) утечки вместо одного)?
Опять же, все зависит от… Но для безопасности, если аккаунты настолько ценны, то авторизацию вообще стоит делать отдельно от самого проекта, и не хранить данные в общей БД.
Нет. Это означает лишь то, что для целей отладки perl (точнее DBI) сохраняет исходный текст подготовленного выражения, а при выполнении выводит его в STDERR с подставленными значениями плейсхолдеров.
Проверить легко: $dbh->prepare с синтаксически неверным запросом. Ошибку в данном случае вернет именно сервер БД.
ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%BB%D0%B5%D0%BC%D0%BC%D0%B0_%D0%B7%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D1%91%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE
Вкратце, чтобы все работало необходимо, чтобы менталитет достаточности был, если и не у всех, но у подавляющего большинства. При другом раскладе такие люди рискуют оказаться в большом проигрыше.
Просто вспомнилось: «Запрещается превращать модератора в лягушку»
</offtopic>
пидолбайства. Как пример — подключение к одному очень известному московскому провайдеру удалось только с 4 попытки, поскольку предыдущие 3 раза «не смогли взять ключи от чердака в ЖЭКе, но в следующий раз такое точно не повторится». Как правило, подобное лечится толькопизвездулями от начальства.По-моему в этом пункте однозначно сказано — можно. Поскольку десктоп версия и есть «outside of the application».
Гуляйте дальше. В таком ключе дискуссию с вами я продолжать не буду.
Выбор по логину (разные логины, точно не в кеше БД):
> select * from user where username='...';
1 row in set (0.04 sec)
1 row in set (0.01 sec)
1 row in set (0.02 sec)
Выбор по id (разные id, точно не в кеше):
> select * from user where id=...;
1 row in set (0.00 sec)
1 row in set (0.00 sec)
1 row in set (0.00 sec)
И?
Затруднит. Вы явно не представляете highload проекты.
Проводить бенчмарки и эксперименты на рабочей БД и рабочей нагрузке никто не даст. Есть только общая статистика, по которой было уменьшение среднего времени выполнения. Возвращать все назад, что бы посмотреть а сколько же было до этого было время выполнения — никто не будет. А смотреть время исполнения на пустой или девелоперской БД — бесполезно, цифры будут совсем другие.
Сотая вообще-то :-)
Но тут речь не о величине — может 10мс, может 1мс, может всего 100мкс экономим. Важно, что на таких нагрузках ни одна оптимизация не оказывается лишней.
Ок. Перечисляю «идеи»:
1) Хранить пользователя в мемкеше (или аналогичном in-memory storage)
2) В SQL БД за пользователем обращаться *только* при отсутствии данных о нем в мемкеше
Думаю тут понятно без комментариев.
А вот необходимость хранить связь login -> id в key-value storage следует из:
1) Получить id из key-value storage быстрее, чем из SQL, даже по индексу
2) В случае присутствия пользователя в мемкеше мы обойдемся вообще без SQL-запросов
> И не можете ответить на простой вопрос — зачем держать в кэше инфу, которая понадобится раз в сутки.
Все вышеперечисленное актуально для highload проектов. Для «сайта Васи Пупкина» все это, понятное дело, не нужно. А в целом — простая арифметика — экономя 10мс на каждом хите мы экономим дофига времени при миллиардах хитов в сутки. И ничего не экономим при 100 хитах в сутки — там на простой больше времени тратится. :-)
Нет. Просто я, как и kapitansky, работаю на highload'е (средняя нагрузка — 1.5 млрд. хитов в сутки). И там подобные, как вы выразились «идеи» — естественная и проверенная временем практика.
Не перевирайте. Мемкеш не потому, что запрос по индексу быстрый, а потому, что SQL сам по себе недостаточно быстрый. Кстати, даю подсказку: на highload'е последовательные запросы одного и того же пользователя могут быть обработаны совершенно разными серверами, так-что хранить данные в сессия (или как в PHP это называется?) — не вариант. Каждый раз получать юзера из SQL БД — тоже.
Так писали же выше — из key-value storage. Выигрыш тут не только за счет увеличения скорости выборки по id юзера, по сравнению с выборкой по логину, но и за счет того, что юзер уже может быть в мемкеше (и ключом в MC выступает все-таки id, а не логин) — на highload'е мемкеш может быть ОЧЕНЬ большим. Да и схема эта в общем-то типовая.
> Разгрузить немного СУБД ценой большей нагрузки на приложение и теоретически меньшей безопасностью (искомый хэш так будет попадать в приложение, а не находиться только внутри СУБД — три варианта (из базы, из приложения, из канала между базой и приложением) утечки вместо одного)?
Опять же, все зависит от… Но для безопасности, если аккаунты настолько ценны, то авторизацию вообще стоит делать отдельно от самого проекта, и не хранить данные в общей БД.
Проверить легко: $dbh->prepare с синтаксически неверным запросом. Ошибку в данном случае вернет именно сервер БД.