| |
| 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 кодировке".
| | |
|
|
| |
| 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.
А для "неконтролируемых внешних веб-сервисов", если они вам вообще нужны, как раз полезна база типа монги, с записью вполне себе на диск - потому что сервис может и упасть, и часто тухлые данные лучше пустого места.
| | |
| 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 + нормализация" мешают. Страдайте, фанатики РСУБД.
А в носклях это в порядке вещей, повторный запрос практически мгновенный.
| | |
| |
| 3.20, Аноним (2), 14:20, 09/07/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
В MySQL есть 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 и будем попивать мохито глядя на твои оптимизации.
| | |
|
|
|
|
|
| |
| 2.11, Crazy Alex (ok), 11:19, 09/07/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
А что тут сравнивать? Нужны более-менее сложные операции - коллекции те же, или нужна персистентность - берёшь редис и удаляешь неактуальное руками, не надо - мемкеш быстрее и проще.
| | |
|
| 1.17, Аноним (17), 13:44, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
подскажите плиз распределенный кеш в виде кучи копий ключа на куче шардов.
ну типа как redis в режиме master-slave только удобней. хранить нужно тупо key-value но чтобы это читать с кучи мест можно было (распределить нагрузку на чтение)
| | |
| |
| |
| 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
| | |
| |
| |
| |
| 7.57, Аноним (30), 11:00, 12/07/2018 [^] [^^] [^^^] [ответить]
| +/– |
Lua за счет jit дает достаточно хорошую скорость выполнения и потребления ресурсов. И то что он используется в nginx, как один из встроенных скриптовых языков, обеспечивая высокую производительность кода обработки на нем, о чем то да говорит... или связка nginx+Lua тоже мусор?
| | |
|
|
|
| 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 - еще и сразу норовит слушать все доступные интерфейсы без авторизации, настраиваемой, как положено жабьим порождениям, совершенно неочевидным и неудобным образом?)
| | |
|
|
|
|
| 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-стораджами.
| | |
|
|
|
