![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva(эта запись может быть интересна только программистам)
Наткнулся на любопытный проект: RAMCloud. Это дистрибутивный key-value store, держащий данные в памяти и расширяющийся на сотни/тысяч серверов, т.е. подобен в этом таким проектам, как memcached или redis. Но в отличие от них, претендует на:
- сохранение данных на диске без опасности потери в случае падения сервера;
- очень быстрое восстановление сервера после падения (1-2 сек.)
- исключительно низкое время задержки (latency чтения ~5 МИКРОсекунд, записи ~15 - это примерно в тысячу раз быстрее, чем читать/писать на локальный диск)
Это как бы с одной стороны академический проект, его полностью выполняет группа Джона Устерхута в Стэнфордском университете (Устерхут известен как изобретатель Tcl/Tk помимо других заслуг), и они опубликовали полтора десятка академических статей и диссертаций на его основе. Неплохой обзор всего проекта есть также в блоге The Morning Paper за 2016 год - этот блог даже несколько раз писал о разных статьях этого проекта (кстати, блог один из лучших в мире, если вы не знаете, ознакомьтесь).
Я почитал некоторые из их статей, там довольно интересный подход к работе с памятью, например. Если вы пишете key-value store на основе памяти, одна из основных проблем, которые нужно решить - это фрагментация; из-за бесперспективно использовать просто стандартную кучу с malloc - куча фрагментируется и все становится очень медленным. В memcached например решили эту проблему с помощью slab allocator, специального выделения памяти фиксированными кусками, которое дает стабильность, но платит за это значительной долью памяти. В RAMCloud решили использовать систему, аналогичную log-based filesystems - новые данные пишутся все время в конце постоянно растущего лога, который обрубается каждые 8 мегабайт; параллельно обычной работе происходит периодическая компактификация старых логов. Еще они много работали над снижением задержек, связанных с сетью; скажем, они обходят ядро и напрямую читают данные из сетевой карты.
С другой стороны, это претендует на то, чтобы быть готовым для использования в реальном мире прямо сейчас проектом. Скорость доступа к данным настолько впечатляет (всего на порядок медленнее RAM, в несколько раз быстрее флеша), что по идее должна открывать путь к очень крутым возможностям с точки зрения дизайна веб-приложений, например - с такой скоростью доступа не проблема прочитать тысячу ключей последовательно один за другим во время исполнения веб-запроса, скажем. Но несмотря на то, что проект существует уже лет семь (первые статьи появляются в 2011-м, первая версия публично выпущена в 2014-м), я вообще не могу найти никаких свидетельств того, что где-то это массово используется. Статьи пишутся (некоторые из них получают призы за лучшую статью конференции!), диссертации защищаются, код - вот он лежит готовый, с кучей пояснений и документации, но я на этот проект наткнулся совершенно случайно (по ссылке из этого блогпоста о книге Устерхута по философии дизайна программ) и никто - не могу быть уверен, конечно, но в первом приближании никто - им, кажется, не пользуется. Есть тут определенная загадка:
- то ли амбициозная задача, которую этот проект решает, на самом деле не так уж нужна людям
- то ли он слишком себя перехваливает и в реальном использовании добиться таких чисел тяжело (скажем, задержка в 5/15 микросекунд предполагает использование технологиии Infiniband, а также какой-то способ заставить сервера сбрасывать буферы на диск, даже если выключается питание всего датацентра; такие способы существуют, например, с отдельной backup-батареей для каждого сервера, но отнюдь не являются стандартными). Это объяснение мне кажется наиболее верным.
- то ли реально это сырой проект, полный багов, люди пытаются им пользоваться и быстро бросают
- то ли все отлично и это вообще революционное достижение, но никто не знает. Не очень в это верю.
В общем, любопытно это происходит с академическими проектами, не в первый раз такое. Параллельный мир, выглядит круто, статьи-призы, и даже специально все заточено под индустрию, а индустрии все равно не нужно.
Наткнулся на любопытный проект: RAMCloud. Это дистрибутивный key-value store, держащий данные в памяти и расширяющийся на сотни/тысяч серверов, т.е. подобен в этом таким проектам, как memcached или redis. Но в отличие от них, претендует на:
- сохранение данных на диске без опасности потери в случае падения сервера;
- очень быстрое восстановление сервера после падения (1-2 сек.)
- исключительно низкое время задержки (latency чтения ~5 МИКРОсекунд, записи ~15 - это примерно в тысячу раз быстрее, чем читать/писать на локальный диск)
Это как бы с одной стороны академический проект, его полностью выполняет группа Джона Устерхута в Стэнфордском университете (Устерхут известен как изобретатель Tcl/Tk помимо других заслуг), и они опубликовали полтора десятка академических статей и диссертаций на его основе. Неплохой обзор всего проекта есть также в блоге The Morning Paper за 2016 год - этот блог даже несколько раз писал о разных статьях этого проекта (кстати, блог один из лучших в мире, если вы не знаете, ознакомьтесь).
Я почитал некоторые из их статей, там довольно интересный подход к работе с памятью, например. Если вы пишете key-value store на основе памяти, одна из основных проблем, которые нужно решить - это фрагментация; из-за бесперспективно использовать просто стандартную кучу с malloc - куча фрагментируется и все становится очень медленным. В memcached например решили эту проблему с помощью slab allocator, специального выделения памяти фиксированными кусками, которое дает стабильность, но платит за это значительной долью памяти. В RAMCloud решили использовать систему, аналогичную log-based filesystems - новые данные пишутся все время в конце постоянно растущего лога, который обрубается каждые 8 мегабайт; параллельно обычной работе происходит периодическая компактификация старых логов. Еще они много работали над снижением задержек, связанных с сетью; скажем, они обходят ядро и напрямую читают данные из сетевой карты.
С другой стороны, это претендует на то, чтобы быть готовым для использования в реальном мире прямо сейчас проектом. Скорость доступа к данным настолько впечатляет (всего на порядок медленнее RAM, в несколько раз быстрее флеша), что по идее должна открывать путь к очень крутым возможностям с точки зрения дизайна веб-приложений, например - с такой скоростью доступа не проблема прочитать тысячу ключей последовательно один за другим во время исполнения веб-запроса, скажем. Но несмотря на то, что проект существует уже лет семь (первые статьи появляются в 2011-м, первая версия публично выпущена в 2014-м), я вообще не могу найти никаких свидетельств того, что где-то это массово используется. Статьи пишутся (некоторые из них получают призы за лучшую статью конференции!), диссертации защищаются, код - вот он лежит готовый, с кучей пояснений и документации, но я на этот проект наткнулся совершенно случайно (по ссылке из этого блогпоста о книге Устерхута по философии дизайна программ) и никто - не могу быть уверен, конечно, но в первом приближании никто - им, кажется, не пользуется. Есть тут определенная загадка:
- то ли амбициозная задача, которую этот проект решает, на самом деле не так уж нужна людям
- то ли он слишком себя перехваливает и в реальном использовании добиться таких чисел тяжело (скажем, задержка в 5/15 микросекунд предполагает использование технологиии Infiniband, а также какой-то способ заставить сервера сбрасывать буферы на диск, даже если выключается питание всего датацентра; такие способы существуют, например, с отдельной backup-батареей для каждого сервера, но отнюдь не являются стандартными). Это объяснение мне кажется наиболее верным.
- то ли реально это сырой проект, полный багов, люди пытаются им пользоваться и быстро бросают
- то ли все отлично и это вообще революционное достижение, но никто не знает. Не очень в это верю.
В общем, любопытно это происходит с академическими проектами, не в первый раз такое. Параллельный мир, выглядит круто, статьи-призы, и даже специально все заточено под индустрию, а индустрии все равно не нужно.
