| |
| 2.22, IRASoldier_registered (ok), 17:16, 09/03/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Уже 15 лет как в продакшене дофига где. То что ты про это ничего не слышал раньше - ну, вот подумай теперь, у кого на самом деле "молодёжно".
| | |
| |
| 3.25, Аноним (25), 09:25, 10/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну так может тому дедушке уже 80 лет и он до сих пор еще сопровождает задачи на досовском паскале - голые массивы и указатели вертит, а про интернет только вчера узнал.
| | |
| 3.27, Аноним (27), 13:47, 10/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Тот что 15 лет в продакшне - к этой поделке пейсбука уже никакого отношения не имеет.
А тут, действительно, стильно-модно, с подворотиками. А что изначальные идеи давно похоронены и разлагаются - пейсбука не беспокоит.
| | |
| 3.32, НамаНама (?), 19:23, 11/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну и что? Дельфин тоже дофига используется. От этого лучше он не становится. Глупые выбирают то, что плавает на поверхности. Увы, это аксиома.
| | |
|
|
| 1.6, gogo (?), 14:28, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А файл, используемый для extstore тоже кешируется в ОЗУ... ))
Жаль, что не свопится )
| | |
| |
| 2.23, Аноним (23), 21:03, 09/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
это если на сервере есть свободная память (а обычно её нет, т.к. она вся отдана memcached).
| | |
|
| 1.10, Аноним (10), 16:48, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>объекты больше 1024 байт
Это 1 кибибайт, страница памяти 4 и более. Размер сектора на современных hdd больше 4к, раньше сектор был 512 байт, например. Меньше записать нельзя, и фс накладывает дополнительные ограничения (запись блоками в 64к вполне обычное дело). Физически это всё выглядит ещё более странно (особенно на SMR моделях). На ссд размер блока, который записывается разом что-то там порядка 32 миллионов.
Так вот, сабж как-то упаковывает данные, или нет? Кто-нибудь это вообще делает? Может ведь быть и сотня байт, но таких сущностей при этом миллионы. Очень часто вижу ситуации, что метаинформация объектов занимает едва ли не больше, нежели сами данные.
| | |
| |
| 2.24, Аноним (24), 04:59, 10/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Не знаю, что там у Фейсбука, но каноничный memcached выделяет память не поэлементно, а крупными блоками (slab-ами), slab-ы разного "класса" соответствуют объектам размера 2^n (с округлением вверх) с целью избежания фрагментации.
Могу предположить, что фейсбуковские патчи банально используют SSD как хранилище slab-ом "больших" классов.
| | |
|
| 1.30, НамаНама (?), 19:16, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Типичный путь неофита: сначала нужно взять что-то попроще, а потом, когда привыкнешь, это "попроще" превратить в уродливую монстрятину.
"Сон разума рождает... мемкэши и ноусиквелы"
| | |
| |
| 2.33, Аноним (33), 20:49, 11/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Фейсбук делает для личных нужд форк мемкеша, который по непонятным причинам называется официальной версией.
Оригинальный мемкеш в доработках не нуждается, поскольку идеален.
| | |
| |
| 3.37, пох. (?), 10:22, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
ну хоть один в теме, а не "на официальном сайте абаутов" начитался.
Не, не идеален - это ты поймешь сразу же, как тебе понадобится failover или sharding - т.е. ты перестанешь помещаться в одну машину.
И либо придется строить миллионы костылей и подпорок, либо плюнуть на O(1) и вообще предсказуемость и валить на redis.
Пейсбука эти проблемы, предсказуемо, не колышут, он десять лет назад себе это уже накостылил, а теперь решает проблемы костылями для этих костылей, уродуя не идеальный, но простой и надежный код.
| | |
| |
| 4.42, Аноним (24), 18:37, 14/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Нормально все делается на application level. Ketama hash и вариации на тему.
Я, конечно, понимаю, что современным хипстерам сложно реализовать алгоритм, и для них шардинг - это волшебство и магия.
| | |
| |
| 5.43, пох. (?), 17:55, 16/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
ну и чего ж "нормального" в том что ты логику работы с шардингом и фэйловер вынужден выносить в "application level", вместо того чтобы предоставить базе заниматься всем этим как может и как умеет (возможно, что-то и соптимизировав, тебе недоступное, поскольку она лучше знает что у нее в данный момент где хранится), зато архинужное "сохранение принципиально неперсистентных данных на ssd" - впиндюрено ей в код (хотя ему как раз место именно в application, только она знает - что имеет смысл хранить таким образом, а что совершенно незачем)
Ты, часом, не в фейсбуке работаешь? У них там так принято, ага.
| | |
|
|
|
|
| 1.31, НамаНама (?), 19:18, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А зачем это? Все массвовые серверные ОС и сами умеют кэшировать. Экземпляры всех современных РСУБД работают тоже исключительно через кэш. Балансировщики и прокси имеют свои кэши. Зачем ещё вот это?
| | |
| |
| 2.35, Аноним (33), 14:16, 12/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Подсказка вторая: в MySQL такой кэш, что лучше бы его не было
| | |
| |
| 3.36, НамаНама (?), 19:55, 12/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Только болваны используют MySQL. Хотя, только болваны и мемкэш используют. Всё же самый ценный работник "технологической компании" это PR.
| | |
| 3.38, пох. (?), 10:27, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
вот не надо - там механика взаимодействия с хранилищем такая, что если бы и такого не было - вообще бы ничего и ни у кого не работало.
Ты легко можешь это проверить, уменьшив все кэши до минимумов.
Ну а чо, еще, штоль, кто-то есть?
Моооожет, ты хочешь немнооожечко mongo? Признайся - хочешь ведь?
Стой, стой, пошутил я!
| | |
| |
| 4.39, Аноним (24), 15:36, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
я про query cache с глобальным локом. Внутренние кэши innodb ок, конечно.
Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов. Как френдлента в ЖЖ (вроде ради нее memcached и придумали).
| | |
| |
| 5.44, пох. (?), 18:02, 16/03/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> я про query cache с глобальным локом
ну вот без него - еще хуже, если, конечно, все запросы не исключительно where id=....
Можешь легко проверить ;-)
> Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов.
а зачем оно такое нужно? У этих серверов вполне есть свои кэши. Обычно он нужен для кэширования (децентрализованного, чтоб не все рухнуло, когда один сервер сдохнет) того, что слишком медленно запрашивать каждый раз.
Но мы вот вынуждены были сбежать на редис, потому что ТАКОЙ фэйловер нам нафиг не упал.
Но у нас, к счастью, там интранет, он подождет.
| | |
|
| 4.40, Аноним (24), 15:41, 13/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Да, Монгу не хочу, спасибо. если нужно schemaless, постгрес с таблицами вида (serial, jsonb) намного шустрее и фичастее (инвертированные индексы на json зачастую куда уместнее btree), а шардинг я и сам делать умею :)
| | |
|
|
|
|
