| |
| 2.34, Аноним (-), 09:29, 22/12/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Иногда главное вовремя остановиться! Memcached отличный, полностью завершенный продукт, а фичеразвитие для него - это скорее плохо, чем хорошо!
| | |
|
| 1.2, Crazy Alex (ok), 23:09, 21/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Не пойму, а какая религия им помешала сделать персистентность? На тех же условиях, что и сейчас - без гарантий, если вам не повезло - то кэш умер, как всегда с мемкешом и было? По идее, для этого же вообще ничего не нужно?
| | |
| |
| 2.3, Аноним (-), 23:19, 21/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Лишние несколько байт на сохранение ключа вместе с данными на постоянном носителе конечно не жалко, но для синхронизации состояния, какие ключи актуальны, а какие нет, пришлось бы заметно усложнить всю архитектуру. Сейчас вся логика в ОЗУ, а на Flash только голые данные без информации об их актуальности.
| | |
| |
| 3.4, Аноним (-), 23:26, 21/12/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Но я бы всё же сделал, что-то типа CoW - кроме ключа сохранял бы время записи, а при запуске предусмотрел бы режим восстановления, оставляя самые свежие ключи при наличии дубликатов остающихся после перезаписи значений ключа.
| | |
| |
| |
| |
| 6.26, ыы (?), 08:53, 22/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Чтобы кэш тёплым после перезапуска оставался.
После перезапуска с какой целью и с каким временем простоя?
| | |
| |
| 7.36, Аноним (-), 09:56, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> После перезапуска с какой целью и с каким временем простоя?
Например, могут динамически генерироваться картинки/видео/звук. При полном сбросе кэша будет огромный провал в производительности и повышенная нагрузка пока кэш не наполнится. По поводу простоя, если будет сохранено время создания, то при загрузке можно отсеивать по времени жизни элемента кэша. Redis для такой задачи не подходит, так как он весь кэш в памяти держит, а другие NoSQL или избыточны (БД, а не кэш) или по производительности не дотягивают.
| | |
| |
| |
| 9.43, J.L. (?), 15:15, 22/12/2017 [^] [^^] [^^^] [ответить] | +/– |  я правильно понимаю что мемкешед можно держать на двух нодах с разным содержимым... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.18, KonstantinB (ok), 02:31, 22/12/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Вопрос в том, как реализовать дамп без блокировок.
В архитектуре мемкеша нет никаких блокировок, кроме глобальной (окей, когда в фейсбуке добавляли мульттредовость, еще сделали локи бакетов - но это непринципиально, бакеты все равно огромные).
В такой ситуации единственный способ сдампиться - поступить так же, как делает Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется в очень высоконагруженных системах с огромным размером кэша - часто это выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и в результате задолго до того, как мы успеем все скинуть на диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет.
| | |
| |
| 3.24, Аноним (-), 08:19, 22/12/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
приличная хранилка имеет скорость 10-15 Gbyte/s сервак с 256G-512G - запишет свою память менее чем за минуту.
| | |
| |
| 4.25, ыы (?), 08:30, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
>10-15 Gbyte/s
>запишет свою память
вы имеете в виду скорость записи на диск?
| | |
|
| 3.30, Роман (??), 09:07, 22/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вопрос в том, как реализовать дамп без блокировок.
Тарантул делает дамп без блокировок и без форка.
> В архитектуре мемкеша нет никаких блокировок, кроме глобальной (окей, когда в фейсбуке
> добавляли мульттредовость, еще сделали локи бакетов - но это непринципиально, бакеты
> все равно огромные).
> В такой ситуации единственный способ сдампиться - поступить так же, как делает
Не единственный, можно mvcc в памяти сделать.
> Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется
> в очень высоконагруженных системах с огромным размером кэша - часто это
> выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока
> все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к
> мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и
> в результате задолго до того, как мы успеем все скинуть на
> диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет. | | |
| |
| 4.46, Аноним (-), 04:04, 24/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Ну, сравнили. Тарантул - это хоть и специфичная, но вполне полноценная субд-версионник. А в мемкеше главная ценность именно в том, что он настолько прост, что все операции имеют сложность О(1).
Тарантул и мемкеш не конкуренты, у них разное назначение.
| | |
|
|
|
| 1.9, Аноним (-), 00:38, 22/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
вот и началась стираться граница между озу и диском.
интересно, когда на компах ползунком в гуи или параметром в конфиге можно будет задавать - сколько отвести под память, а сколько под перманент сторадж?
| | |
| |
| 2.11, VINRARUS (ok), 00:47, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Вообще то это началось с добавлением кэша диска в неиспользуюмую оперативку под управлением Linux.
| | |
| 2.13, Аноним (-), 00:49, 22/12/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Надеюсь никогда, ибо ненужно. Для для машины с быстрой энергонезависимой памятью можно будет отказаться от этих двух абстракций и существенно упростить архитектуру ОС. Концепты уже давно существуют.
| | |
| 2.15, Avator (ok), 01:11, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 ИМХО я думаю что придёт просто к тому что диск по скорости догонит или почти догонит ОЗУ и просто понятие ОЗУ постепенно отомрёт на обычных ПК.
Останется только на серверах для использования штук типа Memcached.
Это как замена ДВС на электромотор. Всё станет проще и это круто.
| | |
| |
| 3.16, VINRARUS (ok), 02:26, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
И вот после этого надобность в дисках хранения отпадет, по крайней мере на многих серверах (ну кроме бекапов).
| | |
| |
| 4.19, KonstantinB (ok), 02:40, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если появится энергонезависимая ОЗУ по цене накопителей, то надобность отпадет очень во многом. Например, в файловой системе. :-) Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPC - но писать файлы уже не надо - зачем, если можно просто держать в памяти все в естественном виде внутренних структур?
| | |
| |
| 5.22, letsmac (ok), 03:18, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > можно просто держать в памяти все в естественном виде внутренних структур?
Ага а резервные копии идиоты придумали. Интересно как в таком идеальном хранилище будет обрабатываться разименование указателя?
| | |
| 5.27, ыы (?), 08:56, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPC
а через IPC нельзя передать просто бинарные данные?
| | |
|
| 4.21, letsmac (ok), 03:17, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
> И вот после этого надобность в дисках хранения отпадет, по крайней мере
> на многих серверах (ну кроме бекапов).
В 80-х Smalltalk таки работал в полностью сохраняющей состояние машине. Но тогда и программисты не на PHP/javascript писали.
| | |
| |
| 5.28, ыы (?), 09:00, 22/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Иными словами - технология доказала свою неэффективность еще 20+ лет назад
| | |
| |
| 6.29, ыы (?), 09:06, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
А вот например Ерланг, тоже кстати не молодой, построенный на прямо противоположной идее - что состояние машины сохранять ненадо а надо ее почаще перезапускать - жив.
| | |
| 6.45, Аноним (-), 18:10, 23/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Не успела доказать — упёрлась в технические ограничения в виде слишком медленных ПЗУ.
| | |
|
|
|
| 3.41, Аноним (-), 11:09, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Физику в школу учить, диск физически не может, т.к. скорость света в нашу вселенную слишком маленькую завезли...
Как думаете почему планки памяти вокруг проца ставят ? :)
| | |
|
|
| 1.31, Роман (??), 09:09, 22/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
.
> Суть нового метода заключается в том, что ключи и метаданные, как и
> раньше, хранится только в оперативной памяти. Если связанные с ключом данные
> небольшого размера, то Memcached работает как обычно, держит данные в памяти
> и не обращается к внешнему хранилищу. Но если данные больше определённого
> значения, они сохраняются во внешнее хранилище, а в ОЗУ остаётся только
> указатель. Если свободной памяти много, то наиболее востребованные данные дополнительно
> могут полностью находиться в кэше в оперативной памяти (например можно указать,
> чтобы на Flash сбрасывались только объекты больше 1024 байт, к которым
> не было обращений 3600 секунд").
Не понятно зачем нужна данная фича, если тот же Тарантул уже лет восемь как умеет хранить данные в памяти, но при этом они персистетны на диске. Таким образом, решается проблема старта с холодном кешом. К тому же, тарантул - это СУБД и имеет таблицы, транзакции, репликацию и прочее, тогда как мешкеш тупо 'кеш."
| | |
| |
| 2.32, ыы (?), 09:18, 22/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Не понятно зачем нужен Тарантул , ведь есть Oracle который покруче Тарантула, и тоже умеет хранить данные в памяти.
| | |
| 2.33, ыы (?), 09:23, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Таким образом, решается проблема старта с холодном кешом.
Вы бы не могли более подробно рассказать об этой проблеме в контексте веб-приложения... Очень любопытно..
Что именно видит на экране юзер, пока вы.. эээ "стартуете с горячим кэшом"?
| | |
| 2.42, Аноним (-), 14:36, 22/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Вашими же словами:
> мешкеш тупо 'кеш."
> Не понятно зачем нужна данная фича
перечитайте новость. когда хранить хочется "чуточку больше", чем есть денег на оперативку.
| | |
|
|
