Опубликован (https://github.com/memcached/memcached/releases/tag/1.5.9) релиз системы кеширования данных в оперативной памяти Memcached 1.5.9 (http://memcached.org/), оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется (https://github.com/memcached/memcached) под лицензией BSD.
В новом выпуске добавлена опция "-L", включающая использование на платформе Linux больших страниц памяти (transparent hugepages), позволяющих снизить число используемых TLB-блоков (Translation Lookaside Buffer). В разряд экспериментальных переведена изоляция системных вызовов при помощи механизма seccomp (--enable-seccomp), а также отключен по умолчанию режим сброса привилегий из-за поступления жалоб о возникновении проблем (для включения следует явно указывать опцию "-o drop_privileges"). Также исправлена ошибка, которая могла привести к краху процесса при манипуляции большими элементами в условиях нехватки памяти в системе в случае использования протокола ASCII.
URL: https://github.com/memcached/memcached/releases/tag/1.5.9
Новость: https://www.opennet.dev/opennews/art.shtml?num=48928
>в случае использования протокола ASCIIЭто ещё что за протокол такой?
Это который с зеленым ядерным консолем видать.
Memcached supports two main protocols; the classic ASCII, and the newer binary.
Так это называется "текстовый протокол, с командами в ASCII кодировке".
Эх, костылик... База должна такими вещами заниматься.
Мне кажется база всё-таки для постоянного хранения важных данных. А временное барахло можно хранить и иными способами.
Вы, видимо, не знаете о чем говорите -- когда-нибудь с проблемами инвалидации такого кэша сталкивались для высоконагруженного динамического набора данных? Ну вот -- все становится непредсказуемо, особенно, если кто-то отчет выгружает за годик другой.
Ну а тем, кто считает что раз "данные редко меняются", то их лучше "закешировать"... Можно только посочувствовать (или порадоваться) тем, кто умудрился "прикрутить memcashed", но поленился разобраться, как работает его собственная база данных и как она кеширует запросы.
ЗЫ Всегда думал, кто memcashed -- это инструмент для кеширования запросов к внешним (т.е. не контролируемым) источникам данных (к примеру, WEB-сервисам), но эта новость мне помогла прозреть :-)
> когда-нибудь с проблемами инвалидации такого кэша сталкивалисьне сталкивались, у нас нет проблемы его сбросить, если мы полезли в базу с update...
И да, этот update - вполне предсказуем.> Можно только посочувствовать (или порадоваться) тем, кто умудрился "прикрутить memcashed", но
> поленился разобраться, как работает его собственная база данных и как она кеширует запросы.плохо она их кэширует - потому что не знает, что мы дальше с результатом делаем.
Потому что у нее дорогое открытие сессии.
Потому что база выбиралась не для key:value, 1:1, и мы не хотим еще одну только для них (да и нет их уже живых, немодно оно нонеча).Можно только порадоваться за незамутненных персонажей, которые думают, что в чем-то там разобрались, и очень этим гордятся, ничего не зная о мире за пределами их localhost.
А для "неконтролируемых внешних веб-сервисов", если они вам вообще нужны, как раз полезна база типа монги, с записью вполне себе на диск - потому что сервис может и упасть, и часто тухлые данные лучше пустого места.
для записи на диск монга не нужна
Классика использования мемкеша - это хранение пользовательской сессии, туда же удобно пихать персонализированный контент. ну и внешние фиды всякие, само собой. В разумных пределах там вообще плевать на некорректную инвалидацию - ну прилетит пользователю что-то слегка устаревшее - если достаточно редко, то и ок. При этом обычно кеш делается на разных уровнях - "сырые" сериализованные данные плюс собранные из них куски HTML разной степени готовности.Ну да, можно и в базу подобное пихать. Но надо будет обеспечивать ручное удаление устаревших данных, отломать все транзакции и подобное чтобы обеспечить хороший througput и так далее. При этом мемкеш по сравнению в базой куда дешевле в администрировании (точнее, не нуждается вообще), stateless (то есть совершенно беспроблемно разворачивается в контейнере, убивается, переносится и т.п.), совершенно тупо шардится и скорее всего даже при всех тюнингах базы будет быстрее. И да, прикручивается к уже готовому сервису без особого ковыряния в кишках, даже там, где изначально предусмотрен не был.
> memcashed -- это инструментдля запоминания количества денег в кошельке
> Вы, видимо, не знаете о чем говорите...
> эта новость мне помогла прозретьВы только что "прозрели" и сразу говорите, что все остальные в мире ничего не понимают?
Кэширование - по-определению и есть кэширование по сравнению с хранением. Есть разница. Я бы попытался "прозреть" почитав как кэш работает в разных местах, например в процессорах. Еще можно подумать о возможности кэширования не исходных данных, а результатов какой-то обработки, которая требует много данных/вычислений и т.п.
База должна хранить не важные данные, а любые данные. И должна гибко настраиваться под любые требования к хранению данных. Но итог такой - один проект и куча баз. Каждая со своим протоколом и своими прибабахами.
к сожалению, libastral не входит в поставку.приходится пользоваться базами, разработанными и оптимизированными под какие-то конкретные применения - для сложной аналитики и развесистых структур - ораклом, для плюнуть key:value на случай "вдруг сейчас опять понадобится" и автоматически забыть его через заданный интервал - вполне годится memcache.
berkley db вот сдохла, видимо, этот use case полностью покрыт другими проектами (ей, правда, изо всех сил помогали умереть). Зато мильен nosql'ей на все вкусы и виды, некоторыми, наверное, даже можно иногда пользоваться.
>Эх, костылик... База должна такими вещами заниматься.Могучие и в 99% случаев ненужные "MVCC + нормализация" мешают. Страдайте, фанатики РСУБД.
А в носклях это в порядке вещей, повторный запрос практически мгновенный.
Нет.
В MySQL есть MEMORY хранилище. Но нет, его использовать неправильно. Давайте поднимем отдельную базу!
Не просто отдельную, а со своим интерфейсом и идеологией.
в MEMORY таблица полностью блокируется при записи!
Это уже технические тонкости. Ничего не мешает сделать её неблокируемой. Просто никому это не нужно. Всем подавай зоопарк баз данных, по штуке на каждую задачу в проекте.
> В MySQL есть MEMORY хранилище. Но нет, его использовать неправильно. Давайте поднимем отдельную базу!Давайте.
select * from sessions where date < шота and date > шота limit два_миллиона;
Когда у вас на сайте будет хотя бы 10 активных юзеров одновременно - mysqld будет потреблять 400% CPU и каждый запрос будет выполняться секунд по 20.
Подобный запрос в memcached займет процентов 5 от силы и выполнится за одну-две секунды.
В некоторых случаях реляционность излишня и есть смысл использовать если не memcached, то noSQL точно.
"MySQL не тянет... А нафига нам унификация??? Давайте напишем отдельную базу! И не будем оптимизировать MySQL! А для хранения данных в памяти, которые необходимо скидывать на жесткий диск, - напишем ещё одну отдельную базу! И пускай у всех этих баз будут разные идеологии и интерфейс!"
"Теперь наш проект использует 3 базы! Мы круты!"
именно так. Не надо оптимизировать хорошую простую rdbms под совершенно перпендикулярное применение (а потом плакать, что в новой оптимизированной и старое стало из-за этого работать хуже, и новое - все еще не совсем готово для)
overengineering никого еще до добра не довел.> Теперь наш проект использует 3 базы
каждую по своему назначению, и ничего ужасного в этом - нет. В отличие от попыток натянуть г-дон на глобус, когда и глобус заляпали, и резинка лопнула.
Прошу прощения за оффтопик.> натянуть г-дон на глобус, когда и глобус заляпали, и резинка лопнула.
Какой замечательный афоризм! Раньше встречал его в несколько иной форме - с натягиванием его же, но уже на кактус и с упоминанием болезненности и бессмысленности сего мероприятия. Добавил вашу вариацию в копилку изречений на случай важный переговоров, спасибо! (Не сочтите за сарказм, я на совершенно серьёзных щах)
> "MySQL не тянет... А нафига нам унификация??? Давайте напишем отдельную базу! И
> не будем оптимизировать MySQL! А для хранения данных в памяти, которые
> необходимо скидывать на жесткий диск, - напишем ещё одну отдельную базу!
> И пускай у всех этих баз будут разные идеологии и интерфейс!"
> "Теперь наш проект использует 3 базы! Мы круты!"Оптимизация как раз и подразумевает использование наиболее эффективного инструмента для разного круга задач, а унификация в твоем контексте - это приклеивание ручки к микроскопу, чтобы им было легче забивать гвозди.
MySQL для многих операций избыточен. Если ты повешаешь на него и сложную и простую логику - ты получишь всего лишь тормоза везде. Ты ведь не думаешь что MySQL быстренько отдаст тебе 10 миллионов key->value пока чебурашит сложный запрос с JOIN и SORT?))
А когда ты начнешь оптимизировать MySQL так глубоко, чтобы он все таки смог обрабатывать такие запросы с приемлемой скоростью - мы уже давно установим memcached и будем попивать мохито глядя на твои оптимизации.
memcached нормально масштабируется в отличие от
Потому что в этом "в отличие от" нашли фатальный недостаток.
vz rediz comparez pliz
А что тут сравнивать? Нужны более-менее сложные операции - коллекции те же, или нужна персистентность - берёшь редис и удаляешь неактуальное руками, не надо - мемкеш быстрее и проще.
> сайтов путём кэширование доступа к СУБДкешированиЯ, Шамана на вас нет
Возьми и исправь, умник.
подскажите плиз распределенный кеш в виде кучи копий ключа на куче шардов.
ну типа как redis в режиме master-slave только удобней. хранить нужно тупо key-value но чтобы это читать с кучи мест можно было (распределить нагрузку на чтение)
Redis, куда еще удобнее?
с одной стороны redis избыточен со всеми своими командами. мне то нужен тупо key-value.
с другой может есть что-то еще более четко заточенное под хранение в памяти множества копий ключей, в идеале в их вытеснением по LRU. может и правда redis лучшее, но вдруг есть что-то еще более узко заточенное под такой кейс?
Посмотрите в сторону tarantool. Это NoSQL заточеная на хранение/работу в памяти + персист на диск. Реплика мастер-мастер из коробки. + Процедуры на Lua в движке, с помощью которых можно будет сделать и LRU
Оно сильно завязано на mail.ru или не очень?
Сильно завязано на Lau, очередной мусор.
Lua за счет jit дает достаточно хорошую скорость выполнения и потребления ресурсов. И то что он используется в nginx, как один из встроенных скриптовых языков, обеспечивая высокую производительность кода обработки на нем, о чем то да говорит... или связка nginx+Lua тоже мусор?
Завязано, но не очень :-)
https://m.habr.com/post/354034/
Но ведь reindexer не имеет репликации.
Как ни странно, но в мире Java таких аж несколько. Самые известные: Hazelcast и Apache Ignite (Grid Gain).Оба обзавелись уже лёгкими протоколами, и их уже можно использовать не только из джавы.
Ignite умеет и дисковый сторадж в дополнении к in-memory. (Не помню, что там у hazelcast).
Ignite давно умеет транзакции. Hazelcast не давно.
Ignite умеет SQL (про hazelcast не помню).
Есть и ещё, менее известные.
> Как ни странно, но в мире Java таких аж несколько.каждый требует терабайт оперативы и еще зачем-то - сто на диске?
(а потом, как пресловутый hadoop - еще и сразу норовит слушать все доступные интерфейсы без авторизации, настраиваемой, как положено жабьим порождениям, совершенно неочевидным и неудобным образом?)
etcd? :-)
> отличающейся простотой использованияДадада, специально для тех, кто любит сервисы голым задом в открытый доступ выставлять.
Ты не поверишь, но он отличается простотой использования даже без открытого доступа.
>> отличающейся простотой использования
> Дадада, специально для тех, кто любит сервисы голым задом в открытый доступ
> выставлять.А что, такие еще существуют ?
Мне кажется закрытие всех портов с последующим открытием лишь необходимых даже не паранойя, а просто правила хорошего тона.
Есть два типа простоты - для идиотов, и для тех, кто пользуется головным мозгом по назначению.
Вот в memcached - второй тип.
>Вот в memcached - второй тип.Готовность довериться левой проге (а не изобретать велосипед) - это 3-й тип.
Нормальный человек - или начнет изобретать велосипед, или попытается разобраться в том же memcached (что весьма непросто). Или и то и другое будет делать одновременно, что по Вашей систематике = 1-й тип.
PS. Всегда боюсь использовать что-то чужое. Свое - оно хоть и хуже вероятно будет, но ... свое. Чужих вирусов не привнесет.
В мемкеше не особо сложно разобраться. Основная идея там проста и гениальна (2^N sized LRU slabs, все операции O(const)).Только делать это лучше на примере сорцов версии 1.2, до фейсбуковских патчей (они там навертели...)
>В мемкеше не особо сложно разобраться
>они там навертели...Я именно об этом говорил.
Поэтому - велосипед надежнее.
Да там принципиально архитектурно ничего не поменялось. Наворотили тредов, от которых все равно толк с подходом "один лок на все" начинатся где-то с 16 ядер, меньше - только зря воздух греет.Я вообще до сих пор 1.2 использую и мне ок.
> Нормальный человек - или начнет изобретать велосипедподскажите, с чего лучше начинать - с c компилятора, или с ядра?
в любом другом случае - вы "доверяетесь левой проге". Тысячам их.
Возможно - предварительно потратив сколько-то времени на ее анализ, возможно использовав чужое экспертное мнение (например, скопипастив из вопроса на stackoverflow ;-) а возможно - полагаясь на свой прошлый опыт (вот в том числе подсказывающий держаться подальше от новых версий мемкэша, с "оптимизацией" и "безопастностью", покуда можно)
Если есть БД и высоконагруженный Web-сервер, с набором стандартных тяжеловесных запросов (на 3-20 сек.; где select из многих таблиц + group by и проч.), то не правильнее ли сделать прослойку - отдельную БД/таблицу, куда раз в минуту (3 минуты) сохранять нужные для запроса данные в легком для простого select виде.. И чтобы WEB обращался уже к этой прослойке.
VK.com действует именно так (imho).
Ошибаетесь: во ВКонтакте масса самописных стораджей на все случаи жизни.Тоже самое в Mail.Ru. Один из таких стороджей со временем сформировался в Tarantool.
>самописных стораджейИ я об этом. Я эти "стораджи" назвал прослойкой. Между основной БД и tmp-стораджами.