The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз Memcached 1.5.9

09.07.2018 09:08

Опубликован релиз системы кеширования данных в оперативной памяти Memcached 1.5.9, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD.

В новом выпуске добавлена опция "-L", включающая использование на платформе Linux больших страниц памяти (transparent hugepages), позволяющих снизить число используемых TLB-блоков (Translation Lookaside Buffer). В разряд экспериментальных переведена изоляция системных вызовов при помощи механизма seccomp (--enable-seccomp), а также отключен по умолчанию режим сброса привилегий из-за поступления жалоб о возникновении проблем (для включения следует явно указывать опцию "-o drop_privileges"). Также исправлена ошибка, которая могла привести к краху процесса при манипуляции большими элементами в условиях нехватки памяти в системе в случае использования текстового протокола.

  1. Главная ссылка к новости (https://github.com/memcached/m...)
  2. OpenNews: Зафиксировано использование Memcached в качестве усилителя трафика для DDoS-атак
  3. OpenNews: Релиз Memcached 1.5.4 с поддержкой кэша на SSD-накопителях
  4. OpenNews: Критические уязвимости в Memcached
  5. OpenNews: Выпуск СУБД Couchbase Server 4.0, сочетающей возможности CouchDB, memcached и Membase
  6. OpenNews: Проекту memcached исполнилось 10 лет
Лицензия: CC-BY
Тип: Программы
Ключевые слова: memcached
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 09:33, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >в случае использования протокола ASCII

    Это ещё что за протокол такой?

     
     
  • 2.3, Аноним (3), 09:39, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это который с зеленым ядерным консолем видать.
     
  • 2.6, Аноним (6), 10:26, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Memcached supports two main protocols; the classic ASCII, and the newer binary.
     
     
  • 3.8, A.Stahl (ok), 10:51, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так это называется "текстовый протокол, с командами в ASCII кодировке".
     

  • 1.2, Аноним (2), 09:37, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Эх, костылик... База должна такими вещами заниматься.
     
     
  • 2.4, A.Stahl (ok), 09:40, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне кажется база всё-таки для постоянного хранения важных данных. А временное барахло можно хранить и иными способами.
     
     
  • 3.7, _hide_ (ok), 10:50, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вы, видимо, не знаете о чем говорите -- когда-нибудь с проблемами инвалидации такого кэша сталкивались для высоконагруженного динамического набора данных? Ну вот -- все становится непредсказуемо, особенно, если кто-то отчет выгружает за годик другой.
    Ну а тем, кто считает что раз "данные редко меняются", то их лучше "закешировать"... Можно только посочувствовать (или порадоваться) тем, кто умудрился "прикрутить memcashed", но поленился разобраться, как работает его собственная база данных и как она кеширует запросы.
    ЗЫ Всегда думал, кто memcashed -- это инструмент для кеширования запросов к внешним (т.е. не контролируемым) источникам данных (к примеру, WEB-сервисам), но эта новость мне помогла прозреть :-)
     
     
  • 4.9, . (?), 11:14, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > когда-нибудь с проблемами инвалидации такого кэша сталкивались

    не сталкивались, у нас нет проблемы его сбросить, если мы полезли в базу с update...
    И да, этот update - вполне предсказуем.

    > Можно только посочувствовать (или порадоваться) тем, кто умудрился "прикрутить memcashed", но
    > поленился разобраться, как работает его собственная база данных и как она кеширует запросы.

    плохо она их кэширует - потому что не знает, что мы дальше с результатом делаем.
    Потому что у нее дорогое открытие сессии.
    Потому что база выбиралась не для key:value, 1:1, и мы не хотим еще одну только для них (да и нет их уже живых, немодно оно нонеча).

    Можно только порадоваться за незамутненных персонажей, которые думают, что в чем-то там разобрались, и очень этим гордятся, ничего не зная о мире за пределами их localhost.

    А для "неконтролируемых внешних веб-сервисов", если они вам вообще нужны, как раз полезна база типа монги, с записью вполне себе на диск - потому что сервис может и упасть, и часто тухлые данные лучше пустого места.

     
     
  • 5.16, анонсим (?), 12:59, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    для записи на диск монга не нужна
     
  • 4.10, Crazy Alex (ok), 11:17, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Классика использования мемкеша - это хранение пользовательской сессии, туда же удобно пихать персонализированный контент. ну и внешние фиды всякие, само собой. В разумных пределах там вообще плевать на некорректную инвалидацию - ну прилетит пользователю что-то слегка устаревшее - если достаточно редко, то и ок.  При этом обычно кеш делается на разных уровнях - "сырые" сериализованные данные плюс собранные из них куски HTML разной степени готовности.

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

     
  • 4.15, анонсим (?), 12:56, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > memcashed -- это инструмент

    для запоминания количества денег в кошельке

     
  • 4.18, Всем Анонимам Аноним (?), 14:11, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вы, видимо, не знаете о чем говорите

    ...
    >  эта новость мне помогла прозреть

    Вы только что "прозрели" и сразу говорите, что все остальные в мире ничего не понимают?

    Кэширование - по-определению и есть кэширование по сравнению с хранением. Есть разница. Я бы попытался "прозреть" почитав как кэш работает в разных местах, например в процессорах. Еще можно подумать о возможности кэширования не исходных данных, а результатов какой-то обработки, которая требует много данных/вычислений и т.п.

     
  • 3.19, Аноним (2), 14:18, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    База должна хранить не важные данные, а любые данные. И должна гибко настраиваться под любые требования к хранению данных. Но итог такой - один проект и куча баз. Каждая со своим протоколом и своими прибабахами.
     
     
  • 4.31, нах (?), 16:34, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    к сожалению, libastral не входит в поставку.

    приходится пользоваться базами, разработанными и оптимизированными под какие-то конкретные применения - для сложной аналитики и развесистых структур - ораклом, для плюнуть key:value на случай "вдруг сейчас опять понадобится" и автоматически забыть его через заданный интервал - вполне годится memcache.

    berkley db вот сдохла, видимо, этот use case полностью покрыт другими проектами (ей, правда, изо всех сил помогали умереть). Зато мильен nosql'ей на все вкусы и виды, некоторыми, наверное, даже можно иногда пользоваться.

     
  • 2.12, лютый охохоня... (?), 11:23, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >Эх, костылик... База должна такими вещами заниматься.

    Могучие и в 99% случаев ненужные "MVCC + нормализация" мешают. Страдайте, фанатики РСУБД.

    А в носклях это в порядке вещей, повторный запрос практически мгновенный.

     
  • 2.13, Аноним (13), 12:24, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.
     
     
  • 3.20, Аноним (2), 14:20, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В MySQL есть MEMORY хранилище. Но нет, его использовать неправильно. Давайте поднимем отдельную базу!
     
     
  • 4.21, Аноним (2), 14:21, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не просто отдельную, а со своим интерфейсом и идеологией.
     
  • 4.23, Гость (??), 14:38, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в MEMORY таблица полностью блокируется при записи!
     
     
  • 5.27, Аноним (2), 15:54, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже технические тонкости. Ничего не мешает сделать её неблокируемой. Просто никому это не нужно. Всем подавай зоопарк баз данных, по штуке на каждую задачу в проекте.
     
  • 4.25, Vitaliy Blats (?), 15:01, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В MySQL есть MEMORY хранилище. Но нет, его использовать неправильно. Давайте поднимем отдельную базу!

    Давайте.

    select * from sessions where date < шота and date > шота limit два_миллиона;

    Когда у вас на сайте будет хотя бы 10 активных юзеров одновременно - mysqld будет потреблять 400% CPU и каждый запрос будет выполняться секунд по 20.

    Подобный запрос в memcached займет процентов 5 от силы и выполнится за одну-две секунды.

    В некоторых случаях реляционность излишня и есть смысл использовать если не memcached, то noSQL точно.

     
     
  • 5.28, Аноним (2), 16:00, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "MySQL не тянет... А нафига нам унификация??? Давайте напишем отдельную базу! И не будем оптимизировать MySQL! А для хранения данных в памяти, которые необходимо скидывать на жесткий диск, - напишем ещё одну отдельную базу! И пускай у всех этих баз будут разные идеологии и интерфейс!"
    "Теперь наш проект использует 3 базы! Мы круты!"
     
     
  • 6.32, нах (?), 16:39, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    именно так. Не надо оптимизировать хорошую простую rdbms под совершенно перпендикулярное применение (а потом плакать, что в новой оптимизированной и старое стало из-за этого работать хуже, и новое - все еще не совсем готово для)
    overengineering никого еще до добра не довел.

    > Теперь наш проект использует 3 базы

    каждую по своему назначению, и ничего ужасного в этом - нет. В отличие от попыток натянуть г-дон на глобус, когда и глобус заляпали, и резинка лопнула.


     
     
  • 7.33, t (??), 17:04, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прошу прощения за оффтопик.

    > натянуть г-дон на глобус, когда и глобус заляпали, и резинка лопнула.

    Какой замечательный афоризм! Раньше встречал его в несколько иной форме - с натягиванием его же, но уже на кактус и с упоминанием болезненности и бессмысленности сего мероприятия. Добавил вашу вариацию в копилку изречений на случай важный переговоров, спасибо! (Не сочтите за сарказм, я на совершенно серьёзных щах)

     
  • 6.38, Vitaliy Blats (?), 18:42, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > "MySQL не тянет... А нафига нам унификация??? Давайте напишем отдельную базу! И
    > не будем оптимизировать MySQL! А для хранения данных в памяти, которые
    > необходимо скидывать на жесткий диск, - напишем ещё одну отдельную базу!
    > И пускай у всех этих баз будут разные идеологии и интерфейс!"
    > "Теперь наш проект использует 3 базы! Мы круты!"

    Оптимизация как раз и подразумевает использование наиболее эффективного инструмента для разного круга задач, а унификация в твоем контексте - это приклеивание ручки к микроскопу, чтобы им было легче забивать гвозди.

    MySQL для многих операций избыточен. Если ты повешаешь на него и сложную и простую логику - ты получишь всего лишь тормоза везде. Ты ведь не думаешь что MySQL быстренько отдаст тебе 10 миллионов key->value пока чебурашит сложный запрос с JOIN и SORT?))

    А когда ты начнешь оптимизировать MySQL так глубоко, чтобы он все таки смог обрабатывать такие запросы с приемлемой скоростью - мы уже давно установим memcached и будем попивать мохито глядя на твои оптимизации.

     
  • 4.26, Аноним (26), 15:38, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    memcached нормально масштабируется в отличие от
     
     
  • 5.29, Аноним (2), 16:05, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что в этом "в отличие от" нашли фатальный недостаток.
     

  • 1.5, бедный буратино (ok), 10:20, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    vz rediz comparez pliz
     
     
  • 2.11, Crazy Alex (ok), 11:19, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А что тут сравнивать? Нужны более-менее сложные операции - коллекции те же, или нужна персистентность - берёшь редис и удаляешь неактуальное руками, не надо - мемкеш быстрее и проще.
     

  • 1.14, анонсим (?), 12:54, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > сайтов путём кэширование доступа к СУБД

    кешированиЯ, Шамана на вас нет

     
     
  • 2.34, Аноним (34), 18:11, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Возьми и исправь, умник.
     

  • 1.17, Аноним (17), 13:44, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    подскажите плиз распределенный кеш в виде кучи копий ключа на куче шардов.
    ну типа как redis в режиме master-slave только удобней. хранить нужно тупо key-value но чтобы это читать с кучи мест можно было (распределить нагрузку на чтение)
     
     
  • 2.22, Аноним (22), 14:34, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Redis, куда еще удобнее?
     
     
  • 3.24, Аноним (17), 15:00, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    с одной стороны redis избыточен со всеми своими командами. мне то нужен тупо key-value.
    с другой может есть что-то еще более четко заточенное под хранение в памяти множества копий ключей,  в идеале в их вытеснением по LRU. может и правда redis лучшее, но вдруг есть что-то еще более узко заточенное под такой кейс?
     
     
  • 4.30, Аноним (30), 16:11, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите в сторону tarantool. Это NoSQL заточеная на хранение/работу в памяти + персист на диск. Реплика мастер-мастер из коробки. + Процедуры на Lua в движке, с помощью которых можно будет сделать и LRU  
     
     
  • 5.35, Аноним (34), 18:12, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оно сильно завязано на mail.ru или не очень?
     
     
  • 6.36, Аноним (36), 18:27, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сильно завязано на Lau, очередной мусор.
     
     
  • 7.57, Аноним (30), 11:00, 12/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Lua за счет jit дает достаточно хорошую скорость выполнения и потребления ресурсов. И то что он используется в nginx, как один из встроенных скриптовых языков, обеспечивая высокую производительность кода обработки на нем, о чем то да говорит... или связка nginx+Lua тоже мусор?  
     
  • 6.42, KonstantinB (ok), 21:09, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Завязано, но не очень :-)
     
  • 4.37, Аноним (36), 18:30, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://m.habr.com/post/354034/
     
     
  • 5.52, funny.falcon (?), 10:47, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь reindexer не имеет репликации.
     
  • 4.51, funny.falcon (?), 10:46, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как ни странно, но в мире Java таких аж несколько. Самые известные: Hazelcast и Apache Ignite (Grid Gain).

    Оба обзавелись уже лёгкими протоколами, и их уже можно использовать не только из джавы.

    Ignite умеет и дисковый сторадж в дополнении к in-memory. (Не помню, что там у hazelcast).

    Ignite давно умеет транзакции. Hazelcast не давно.

    Ignite умеет SQL (про hazelcast не помню).

    Есть и ещё, менее известные.

     
     
  • 5.56, нах (?), 15:34, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Как ни странно, но в мире Java таких аж несколько.

    каждый требует терабайт оперативы и еще зачем-то - сто на диске?
    (а потом, как пресловутый hadoop - еще и сразу норовит слушать все доступные интерфейсы без авторизации, настраиваемой, как положено жабьим порождениям, совершенно неочевидным и неудобным образом?)

     
  • 2.41, KonstantinB (ok), 21:05, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    etcd? :-)
     

  • 1.39, Аноним (39), 19:51, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > отличающейся простотой использования

    Дадада, специально для тех, кто любит сервисы голым задом в открытый доступ выставлять.

     
     
  • 2.40, Аноним (40), 20:35, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты не поверишь, но он отличается простотой использования даже без открытого доступа.
     
  • 2.43, Vitaliy Blats (?), 21:21, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> отличающейся простотой использования
    > Дадада, специально для тех, кто любит сервисы голым задом в открытый доступ
    > выставлять.

    А что, такие еще существуют ?

    Мне кажется закрытие всех портов с последующим открытием лишь необходимых даже не паранойя, а просто правила хорошего тона.

     
  • 2.44, KonstantinB (ok), 21:51, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть два типа простоты - для идиотов, и для тех, кто пользуется головным мозгом по назначению.
    Вот в memcached - второй тип.
     
     
  • 3.46, konst55512 (?), 00:59, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Вот в memcached - второй тип.

    Готовность довериться левой проге (а не изобретать велосипед) - это 3-й тип.
    Нормальный человек - или начнет изобретать велосипед, или попытается разобраться в том же memcached (что весьма непросто). Или и то и другое будет делать одновременно, что по Вашей систематике = 1-й тип.
    PS. Всегда боюсь использовать что-то чужое. Свое - оно хоть и хуже вероятно будет, но ... свое. Чужих вирусов не привнесет.

     
     
  • 4.48, KonstantinB (ok), 01:24, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В мемкеше не особо сложно разобраться. Основная идея там проста и гениальна (2^N sized LRU slabs, все операции O(const)).

    Только делать это лучше на примере сорцов версии 1.2, до фейсбуковских патчей (они там навертели...)

     
     
  • 5.49, konst55512 (?), 01:52, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >В мемкеше не особо сложно разобраться
    >они там навертели...

    Я именно об этом говорил.
    Поэтому - велосипед надежнее.

     
     
  • 6.50, KonstantinB (??), 06:10, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да там принципиально архитектурно ничего не поменялось. Наворотили тредов, от которых все равно толк с подходом "один лок на все" начинатся где-то с 16 ядер, меньше - только зря воздух греет.

    Я вообще до сих пор 1.2 использую и мне ок.

     
  • 4.55, нах (?), 15:29, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Нормальный человек - или начнет изобретать велосипед

    подскажите, с чего лучше начинать - с c компилятора, или с ядра?

    в любом другом случае - вы "доверяетесь левой проге". Тысячам их.
    Возможно - предварительно потратив сколько-то времени на ее анализ, возможно использовав чужое экспертное мнение (например, скопипастив из вопроса на stackoverflow ;-) а возможно - полагаясь на свой прошлый опыт (вот в том числе подсказывающий держаться подальше от новых версий мемкэша, с "оптимизацией" и "безопастностью", покуда можно)

     

  • 1.45, konst55512 (?), 00:43, 10/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если есть БД и высоконагруженный Web-сервер, с набором стандартных тяжеловесных запросов (на 3-20 сек.; где select из многих таблиц + group by и проч.), то не правильнее ли сделать прослойку - отдельную БД/таблицу, куда раз в минуту (3 минуты)  сохранять нужные для запроса данные в легком для простого select виде.. И чтобы WEB обращался уже к этой прослойке.
    VK.com действует именно так (imho).
     
     
  • 2.53, funny.falcon (?), 10:51, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибаетесь: во ВКонтакте масса самописных стораджей на все случаи жизни.

    Тоже самое в Mail.Ru. Один из таких стороджей со временем сформировался в Tarantool.

     
     
  • 3.54, konst55512 (?), 15:18, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >самописных стораджей

    И я об этом. Я эти "стораджи" назвал прослойкой. Между основной БД и tmp-стораджами.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру