The OpenNET Project / Index page

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



"Релиз Memcached 1.6.0 с включением поддержки внешнего хранилища"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз Memcached 1.6.0 с включением поддержки внешнего хранилища"  +/
Сообщение от opennews (ok), 09-Мрт-20, 11:23 
Состоялся значительный релиз системы кэширования данных в оперативной памяти Memcached 1.6.0, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52507

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

4. Сообщение от Аноним (4), 09-Мрт-20, 13:07   –11 +/
Стильно, модно, молодежно!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

5. Сообщение от Аноним (5), 09-Мрт-20, 13:50   –5 +/
Memcrashed
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

6. Сообщение от gogo (?), 09-Мрт-20, 14:28   –1 +/
А файл, используемый для extstore тоже кешируется в ОЗУ... ))
Жаль, что не свопится )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

10. Сообщение от Аноним (10), 09-Мрт-20, 16:48   +/
>объекты больше 1024 байт

Это 1 кибибайт, страница памяти 4 и более. Размер сектора на современных hdd больше 4к, раньше сектор был 512 байт, например. Меньше записать нельзя, и фс накладывает дополнительные ограничения (запись блоками в 64к вполне обычное дело). Физически это всё выглядит ещё более странно (особенно на SMR моделях). На ссд размер блока, который записывается разом что-то там порядка 32 миллионов.

Так вот, сабж как-то упаковывает данные, или нет? Кто-нибудь это вообще делает? Может ведь быть и сотня байт, но таких сущностей при этом миллионы. Очень часто вижу ситуации, что метаинформация объектов занимает едва ли не больше, нежели сами данные.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от IRASoldier_registered (ok), 09-Мрт-20, 17:16   +5 +/
Уже 15 лет как в продакшене дофига где. То что ты про это ничего не слышал раньше - ну, вот подумай теперь, у кого на самом деле "молодёжно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #25, #27, #32

23. Сообщение от Аноним (23), 09-Мрт-20, 21:03   +/
это если на сервере есть свободная память (а обычно её нет, т.к. она вся отдана memcached).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

24. Сообщение от Аноним (24), 10-Мрт-20, 04:59   +/
Не знаю, что там у Фейсбука, но каноничный memcached выделяет память не поэлементно, а крупными блоками (slab-ами), slab-ы разного "класса" соответствуют объектам размера 2^n (с округлением вверх) с целью избежания фрагментации.

Могу предположить, что фейсбуковские патчи банально используют SSD как хранилище slab-ом "больших" классов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 10-Мрт-20, 09:25   +/
Ну так может тому дедушке уже 80 лет и он до сих пор еще сопровождает задачи на досовском паскале - голые массивы и указатели вертит, а про интернет только вчера узнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #26

26. Сообщение от IRASoldier_registered (ok), 10-Мрт-20, 12:36   +2 +/
На Фортране, на ЕС 1010, а вместо Интернета фельдъегеря перфоленту доставляют в шарашку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

27. Сообщение от Аноним (27), 10-Мрт-20, 13:47   +/
Тот что 15 лет в продакшне - к этой поделке пейсбука уже никакого отношения не имеет.
А тут, действительно, стильно-модно, с подворотиками. А что изначальные идеи давно похоронены и разлагаются - пейсбука не беспокоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29

28. Сообщение от Аноним (28), 10-Мрт-20, 14:55   +1 +/
Факты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

29. Сообщение от IRASoldier_registered (ok), 11-Мрт-20, 15:17   +/
Зайди на офсайт memcached, вдумчиво почитай эбауты и узбагойся.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

30. Сообщение от НамаНама (?), 11-Мрт-20, 19:16   +1 +/
Типичный путь неофита: сначала нужно взять что-то попроще, а потом, когда привыкнешь, это "попроще" превратить в уродливую монстрятину.
"Сон разума рождает... мемкэши и ноусиквелы"
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

31. Сообщение от НамаНама (?), 11-Мрт-20, 19:18   +/
А зачем это? Все массвовые серверные ОС и сами умеют кэшировать. Экземпляры всех современных РСУБД работают тоже исключительно через кэш. Балансировщики и прокси имеют свои кэши. Зачем ещё вот это?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #35

32. Сообщение от НамаНама (?), 11-Мрт-20, 19:23   +/
Ну и что? Дельфин тоже дофига используется. От этого лучше он не становится. Глупые выбирают то, что плавает на поверхности. Увы, это аксиома.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #41

33. Сообщение от Аноним (33), 11-Мрт-20, 20:49   +1 +/
Фейсбук делает для личных нужд форк мемкеша, который по непонятным причинам называется официальной версией.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #37

34. Сообщение от Аноним (33), 12-Мрт-20, 14:15   +/
Подсказка: Фейсбук работает более чем на одном сервере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

35. Сообщение от Аноним (33), 12-Мрт-20, 14:16   +1 +/
Подсказка вторая: в MySQL такой кэш, что лучше бы его не было
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #36, #38

36. Сообщение от НамаНама (?), 12-Мрт-20, 19:55   –2 +/
Только болваны используют MySQL. Хотя, только болваны и мемкэш используют. Всё же самый ценный работник "технологической компании" это PR.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

37. Сообщение от пох. (?), 13-Мрт-20, 10:22   +/
ну хоть один в теме, а не "на официальном сайте абаутов" начитался.

Не, не идеален - это ты поймешь сразу же, как тебе понадобится failover или sharding - т.е. ты перестанешь помещаться в одну машину.
И либо придется строить миллионы костылей и подпорок, либо плюнуть на O(1) и вообще предсказуемость и валить на redis.
Пейсбука эти проблемы, предсказуемо, не колышут, он десять лет назад себе это уже накостылил, а теперь решает проблемы костылями для этих костылей, уродуя не идеальный, но простой и надежный код.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #42

38. Сообщение от пох. (?), 13-Мрт-20, 10:27   +/
вот не надо - там механика взаимодействия с хранилищем такая, что если бы и такого не было - вообще бы ничего и ни у кого не работало.
Ты легко можешь это проверить, уменьшив все кэши до минимумов.

Ну а чо, еще, штоль, кто-то есть?

Моооожет, ты хочешь немнооожечко mongo? Признайся - хочешь ведь?
Стой, стой, пошутил я!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #39, #40

39. Сообщение от Аноним (24), 13-Мрт-20, 15:36   +/
я про query cache с глобальным локом. Внутренние кэши innodb ок, конечно.

Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов. Как френдлента в ЖЖ (вроде ради нее memcached и придумали).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #44

40. Сообщение от Аноним (24), 13-Мрт-20, 15:41   +/
Да, Монгу не хочу, спасибо. если нужно schemaless, постгрес с таблицами вида (serial, jsonb) намного шустрее и фичастее (инвертированные индексы на json зачастую куда уместнее btree), а шардинг я и сам делать умею :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

41. Сообщение от IRASoldier_registered (ok), 13-Мрт-20, 16:44   +/
Ну давай, расскажи нам об альтернативах, которые использует умная элита типа тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

42. Сообщение от Аноним (24), 14-Мрт-20, 18:37   +/
Нормально все делается на application level. Ketama hash и вариации на тему.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #43

43. Сообщение от пох. (?), 16-Мрт-20, 17:55   +/
ну и чего ж "нормального" в том что ты логику работы с шардингом и фэйловер вынужден выносить в "application level", вместо того чтобы предоставить базе заниматься всем этим как может и как умеет (возможно, что-то и соптимизировав, тебе недоступное, поскольку она лучше знает что у нее в данный момент где хранится), зато архинужное "сохранение принципиально неперсистентных данных на ssd" - впиндюрено ей в код (хотя ему как раз место именно в application, только она знает - что имеет смысл хранить таким образом, а что совершенно незачем)

Ты, часом, не в фейсбуке работаешь? У них там так принято, ага.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от пох. (?), 16-Мрт-20, 18:02   +/
> я про query cache с глобальным локом

ну вот без него - еще хуже, если, конечно, все запросы не исключительно where id=....
Можешь легко проверить ;-)

> Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов.

а зачем оно такое нужно? У этих серверов вполне есть свои кэши. Обычно он нужен для кэширования (децентрализованного, чтоб не все рухнуло, когда один сервер сдохнет) того, что слишком медленно запрашивать каждый раз.

Но мы вот вынуждены были сбежать на редис, потому что ТАКОЙ фэйловер нам нафиг не упал.
Но у нас, к счастью, там интранет, он подождет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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