Состоялся значительный релиз системы кэширования данных в оперативной памяти Memcached 1.6.0, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52507
Стильно, модно, молодежно!
Уже 15 лет как в продакшене дофига где. То что ты про это ничего не слышал раньше - ну, вот подумай теперь, у кого на самом деле "молодёжно".
Ну так может тому дедушке уже 80 лет и он до сих пор еще сопровождает задачи на досовском паскале - голые массивы и указатели вертит, а про интернет только вчера узнал.
На Фортране, на ЕС 1010, а вместо Интернета фельдъегеря перфоленту доставляют в шарашку.
Тот что 15 лет в продакшне - к этой поделке пейсбука уже никакого отношения не имеет.
А тут, действительно, стильно-модно, с подворотиками. А что изначальные идеи давно похоронены и разлагаются - пейсбука не беспокоит.
Зайди на офсайт memcached, вдумчиво почитай эбауты и узбагойся.
Ну и что? Дельфин тоже дофига используется. От этого лучше он не становится. Глупые выбирают то, что плавает на поверхности. Увы, это аксиома.
Ну давай, расскажи нам об альтернативах, которые использует умная элита типа тебя.
Memcrashed
Факты
А файл, используемый для extstore тоже кешируется в ОЗУ... ))
Жаль, что не свопится )
это если на сервере есть свободная память (а обычно её нет, т.к. она вся отдана memcached).
>объекты больше 1024 байтЭто 1 кибибайт, страница памяти 4 и более. Размер сектора на современных hdd больше 4к, раньше сектор был 512 байт, например. Меньше записать нельзя, и фс накладывает дополнительные ограничения (запись блоками в 64к вполне обычное дело). Физически это всё выглядит ещё более странно (особенно на SMR моделях). На ссд размер блока, который записывается разом что-то там порядка 32 миллионов.
Так вот, сабж как-то упаковывает данные, или нет? Кто-нибудь это вообще делает? Может ведь быть и сотня байт, но таких сущностей при этом миллионы. Очень часто вижу ситуации, что метаинформация объектов занимает едва ли не больше, нежели сами данные.
Не знаю, что там у Фейсбука, но каноничный memcached выделяет память не поэлементно, а крупными блоками (slab-ами), slab-ы разного "класса" соответствуют объектам размера 2^n (с округлением вверх) с целью избежания фрагментации.Могу предположить, что фейсбуковские патчи банально используют SSD как хранилище slab-ом "больших" классов.
Типичный путь неофита: сначала нужно взять что-то попроще, а потом, когда привыкнешь, это "попроще" превратить в уродливую монстрятину.
"Сон разума рождает... мемкэши и ноусиквелы"
Фейсбук делает для личных нужд форк мемкеша, который по непонятным причинам называется официальной версией.Оригинальный мемкеш в доработках не нуждается, поскольку идеален.
ну хоть один в теме, а не "на официальном сайте абаутов" начитался.Не, не идеален - это ты поймешь сразу же, как тебе понадобится failover или sharding - т.е. ты перестанешь помещаться в одну машину.
И либо придется строить миллионы костылей и подпорок, либо плюнуть на O(1) и вообще предсказуемость и валить на redis.
Пейсбука эти проблемы, предсказуемо, не колышут, он десять лет назад себе это уже накостылил, а теперь решает проблемы костылями для этих костылей, уродуя не идеальный, но простой и надежный код.
Нормально все делается на application level. Ketama hash и вариации на тему.Я, конечно, понимаю, что современным хипстерам сложно реализовать алгоритм, и для них шардинг - это волшебство и магия.
ну и чего ж "нормального" в том что ты логику работы с шардингом и фэйловер вынужден выносить в "application level", вместо того чтобы предоставить базе заниматься всем этим как может и как умеет (возможно, что-то и соптимизировав, тебе недоступное, поскольку она лучше знает что у нее в данный момент где хранится), зато архинужное "сохранение принципиально неперсистентных данных на ssd" - впиндюрено ей в код (хотя ему как раз место именно в application, только она знает - что имеет смысл хранить таким образом, а что совершенно незачем)Ты, часом, не в фейсбуке работаешь? У них там так принято, ага.
А зачем это? Все массвовые серверные ОС и сами умеют кэшировать. Экземпляры всех современных РСУБД работают тоже исключительно через кэш. Балансировщики и прокси имеют свои кэши. Зачем ещё вот это?
Подсказка: Фейсбук работает более чем на одном сервере.
Подсказка вторая: в MySQL такой кэш, что лучше бы его не было
Только болваны используют MySQL. Хотя, только болваны и мемкэш используют. Всё же самый ценный работник "технологической компании" это PR.
вот не надо - там механика взаимодействия с хранилищем такая, что если бы и такого не было - вообще бы ничего и ни у кого не работало.
Ты легко можешь это проверить, уменьшив все кэши до минимумов.Ну а чо, еще, штоль, кто-то есть?
Моооожет, ты хочешь немнооожечко mongo? Признайся - хочешь ведь?
Стой, стой, пошутил я!
я про query cache с глобальным локом. Внутренние кэши innodb ок, конечно.Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов. Как френдлента в ЖЖ (вроде ради нее memcached и придумали).
> я про query cache с глобальным локомну вот без него - еще хуже, если, конечно, все запросы не исключительно where id=....
Можешь легко проверить ;-)> Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов.
а зачем оно такое нужно? У этих серверов вполне есть свои кэши. Обычно он нужен для кэширования (децентрализованного, чтоб не все рухнуло, когда один сервер сдохнет) того, что слишком медленно запрашивать каждый раз.
Но мы вот вынуждены были сбежать на редис, потому что ТАКОЙ фэйловер нам нафиг не упал.
Но у нас, к счастью, там интранет, он подождет.
Да, Монгу не хочу, спасибо. если нужно schemaless, постгрес с таблицами вида (serial, jsonb) намного шустрее и фичастее (инвертированные индексы на json зачастую куда уместнее btree), а шардинг я и сам делать умею :)